Edgewall Software
Modify

Opened 15 years ago

Closed 14 years ago

Last modified 7 years ago

#3327 closed defect (worksforme)

''Reply to comment'' does not work well with Safari

Reported by: Emmanuel Blot Owned by: Jonas Borgström
Priority: low Milestone:
Component: ticket system Version: devel
Severity: normal Keywords: macosx, safari
Cc: Branch:
Release Notes:
API Changes:
Internal 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 (0)

Change History (17)

comment:1 by Christian Boos, 15 years ago

Does the preview work? It's doing basically the same thing…

in reply to:  1 comment:2 by Emmanuel Blot, 15 years ago

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.

in reply to:  1 ; comment:3 by Christian Boos, 15 years ago

Can you try to change the Reply form to use POST instead of GET?

comment:4 by Emmanuel Blot, 15 years ago

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.

in reply to:  3 ; comment:5 by Emmanuel Blot, 15 years ago

Replying to cboos:

Can you try to change the Reply form to use POST instead of GET?

I could, but it seems I cannot reproduce this issue with the current trunk [3488].
I was reporting about p.e.c.

in reply to:  5 comment:6 by Christian Boos, 15 years ago

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 by Emmanuel Blot, 15 years ago

Yes, I'll try when I get some spare time. As it is not a 100% reproducible issue, it mght take some time…

in reply to:  7 comment:8 by Emmanuel Blot, 15 years ago

Resolution: worksforme
Status: newclosed

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 by Emmanuel Blot, 15 years ago

Resolution: worksforme
Status: closedreopened

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).

in reply to:  9 comment:10 by Emmanuel Blot, 15 years ago

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 by Emmanuel Blot, 15 years ago

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 by Christian Boos, 15 years ago

Keywords: macosx safari added
Milestone: 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 by Emmanuel Blot, 15 years ago

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 by osimons, 14 years ago

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 by Emmanuel Blot, 14 years ago

Resolution: worksforme
Status: reopenedclosed

No, the issue has disappeared with both WebKit and Safari 3.x

comment:16 by Remy Blank, 10 years ago

Milestone: not applicable

comment:17 by Ryan J Ollos, 7 years ago

Keywords: macosx safari → macosx, safari

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Jonas Borgström.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Jonas Borgström to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.