Ticket #3327 (closed defect: worksforme)
Opened 6 years ago
Last modified 7 months ago
''Reply to comment'' does not work well with Safari
| Reported by: | eblot | Owned by: | jonas |
|---|---|---|---|
| Priority: | low | Milestone: | |
| Component: | ticket system | Version: | devel |
| Severity: | normal | Keywords: | macosx safari |
| Cc: | |||
| Release Notes: | |||
| API Changes: | |||
Description
It seems that the "reply to comment" feature recently introduced within ticket pages does not work as expected on Safari 2.0.3/Intel:
When I open an existing ticket and click on a "reply" button, the text area is kept blank, whereas it should be updated with the content of the original, quoted comment.
Refreshing the page makes the quoted comment appear in the text area.
Attachments
Change History
comment:1 follow-ups: ↓ 2 ↓ 3 Changed 6 years ago by cboos
comment:2 in reply to: ↑ 1 Changed 6 years ago by eblot
Preview renders ok the text that is shown in the textarea, but does not make the quoted text to appear in the preview window if the quoted text is not shown in the text area.
It is worth noting that sometimes, the quoted text do appear on the first time the "reply" button is pushed. I have not find yet what is the triggering event (what makes it work or fail). For example, I've been unable to quote your comment here.
comment:3 in reply to: ↑ 1 ; follow-up: ↓ 5 Changed 6 years ago by cboos
Can you try to change the Reply form to use POST instead of GET?
comment:4 Changed 6 years ago by eblot
Replying to eblot:
For example, I've been unable to quote your comment here.
But I've had no trouble quoting my own comment or yours once I replied to your first comment. Very weird.
I tried to close/open Safari (three different ways: the application, the window, the tab) and it does not seem related to this issue.
comment:5 in reply to: ↑ 3 ; follow-up: ↓ 6 Changed 6 years ago by eblot
comment:6 in reply to: ↑ 5 Changed 6 years ago by cboos
Replying to eblot:
... I cannot reproduce this issue with the current trunk [3488].
I was reporting about p.e.c.
But then, can you reproduce the issue using p.e.c's revision, i.e. r3432?
If not, weird and weirder, but if yes, and if you have some time to loose,
can you locate the change that corrected the issue, so that we could
better understand what happened? There are not much changes affecting
the Reply feature in [3432:3488/trunk].
Best is to "bisect" that range...
comment:7 follow-up: ↓ 8 Changed 6 years ago by eblot
Yes, I'll try when I get some spare time. As it is not a 100% reproducible issue, it mght take some time...
comment:8 in reply to: ↑ 7 Changed 6 years ago by eblot
- Resolution set to worksforme
- Status changed from new to closed
Replying to eblot:
Yes, I'll try when I get some spare time. As it is not a 100% reproducible issue, it mght take some time...
So I'm unable to reproduce this issue with r3432, but I cannot reproduce it on p.e.c. anymore.
The 'trouble' is that I've upgraded yesterday night to OS 10.4.7, I don't know if this upgrade has changed something about Safari.
I'm closing this ticket for now.
comment:9 follow-up: ↓ 10 Changed 6 years ago by eblot
- Resolution worksforme deleted
- Status changed from closed to reopened
Re-opening this ticket, as the problem keeps randomly showing up with trac.edgewall.org (at least). My current Safari release is 2.0.4 (419).
comment:10 in reply to: ↑ 9 Changed 5 years ago by eblot
Replying to eblot:
Re-opening this ticket, as the problem keeps randomly showing up with trac.edgewall.org (at least). My current Safari release is 2.0.4 (419).
Unfortunately, the issue still appears with the latest development release, as trac.edgwall.org has been upgraded this week.
This is a random issue, I can't find a sequence of actions that always reproduces the problem. On another bug, I wished to add a comment to the original description. I clicked on "reply" button from the 'Description' box, the edit area has been left blank; I then simply logged in - which implies a browser refresh of the page - and the commented description appeared in the text area.
comment:11 Changed 5 years ago by eblot
Actually, it seems that the problem does not occur w/ the latest WebKit?, which will be the engine for the next Safari release.
I'm not sure how to close this bug: worksforme or wontfix, as it seems a Safari 2 issue?
comment:12 Changed 5 years ago by cboos
- Keywords macosx safari added
- Milestone set to none
none milestone, as it's an external issue which affects Trac.
I think we'll be able to close it when it's no longer an issue with commonly available Safari releases.
comment:13 Changed 5 years ago by eblot
Actually, it is still and issue with Omniweb (which uses WebKit, i.e. the same engine as Safari) and the official Safari release, that is for regular MacOS X users.
comment:14 Changed 4 years ago by osimons
I've been using Safari for quite some time, and have not seen this is my recent memory.
eblot, is this still and issue, or can it be closed? Anyone seeing this with 0.11?
comment:15 Changed 4 years ago by eblot
- Resolution set to worksforme
- Status changed from reopened to closed
No, the issue has disappeared with both WebKit? and Safari 3.x
comment:16 Changed 7 months ago by rblank
- Milestone not applicable deleted
Does the preview work? It's doing basically the same thing...