Edgewall Software

Ticket #3327 (closed defect: worksforme)

Opened 2 years ago

Last modified 3 months ago

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

Reported by: eblot Owned by: jonas
Priority: low Milestone: not applicable
Component: ticket system Version: devel
Severity: normal Keywords: macosx safari
Cc:

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

follow-ups: ↓ 2 ↓ 3   Changed 2 years ago by cboos

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

in reply to: ↑ 1   Changed 2 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.

in reply to: ↑ 1 ; follow-up: ↓ 5   Changed 2 years ago by cboos

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

  Changed 2 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.

in reply to: ↑ 3 ; follow-up: ↓ 6   Changed 2 years ago by eblot

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   Changed 2 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...

follow-up: ↓ 8   Changed 2 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...

in reply to: ↑ 7   Changed 2 years ago by eblot

  • status changed from new to closed
  • resolution set to worksforme

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.

follow-up: ↓ 10   Changed 2 years ago by eblot

  • status changed from closed to reopened
  • resolution worksforme deleted

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   Changed 2 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.

  Changed 21 months 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?

  Changed 16 months 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.

  Changed 16 months 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.

  Changed 6 months 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?

  Changed 6 months ago by eblot

  • status changed from reopened to closed
  • resolution set to worksforme

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

Add/Change #3327 (''Reply to comment'' does not work well with Safari)

Author



Change Properties
<Author field>
Action
as closed
Next status will be 'reopened'
 
Note: See TracTickets for help on using tickets.