Edgewall Software

Opened 11 years ago

Closed 11 years ago

Last modified 10 years ago

#10382 closed defect (fixed)

page auto refresh will clear all contents in "Add a comment" box

Reported by: haisland@… Owned by: Remy Blank
Priority: normal Milestone: 0.12.3
Component: ticket system Version: 0.12.2
Severity: critical Keywords: iexplorer javascript
Cc: ryano@… Branch:
Release Notes:
API Changes:
Internal Changes:


  1. Open any exist ticket.
  2. Submit a comment with any content.
  3. After step 2, do NOT extend "Modify Ticket".
  4. Input any comment into "Add a comment" box.
  5. Click "Modify Ticket" link try to change ticket status.


Page will auto refresh after step 4 and all content in "Add a comment" box was cleared.

Additional info

  1. I had tried to search "clear…" and "Add a comment…" in exist ticket but not return similar result, so I have to create a new one.
  2. Set to Critical because this defect cause user input data lost.

Thank you!

Attachments (2)

#10382.zip (168.9 KB ) - added by haisland@… 11 years ago.
rec video for ticket 10382, it's wmv format.
10382-ie-no-reload-r10850.patch (619 bytes ) - added by Remy Blank 11 years ago.
Work around IE bug when changing hash after redirect.

Download all attachments as: .zip

Change History (15)

comment:1 by Christian Boos, 11 years ago

Which browser are you using?

All what this links does is to modify the anchor (<a href="#propertyform" title="Go to the ticket editor">Modify</a>), so clicking on it should just move you around in the page, not trigger a reload.

by haisland@…, 11 years ago

Attachment: #10382.zip added

rec video for ticket 10382, it's wmv format.

comment:2 by haisland@…, 11 years ago

Dear cboos,

Thank you for your response.

It occurs with IE7/8. Also I tested Firefox and it's OK.

Please try to reproduce it strictly with my steps. (also I recorded a video about it, please download here. It's wmv format and I swear it's safe.)

comment:3 by Christian Boos, 11 years ago

Component: generalticket system
Keywords: iexplorer javascript added

Wow … reproduced, on both 0.12-stable and trunk, with IE9. Thank you for the report!

comment:4 by haisland@…, 11 years ago

Dear cboos,

Thank you. I'm looking forward to see it can be fixed in 0.12.3. :-)

comment:5 by Remy Blank, 11 years ago

I can also reproduce this here. It looks like IE reloads the page for some reason when changing the anchor, but only after a redirect to URL containing an anchor. If I remove the fragment from the redirect, the issue disappears.

We're not the first ones to notice, and it seems to be a bug in IE. The reply suggests removing the "no-cache" header, but removing both Cache-Control and Pragma from the redirect doesn't change anything. Other workarounds include adding the following to the page, to make the page reload at once after the redirect:

<script type="text/javascript">
  window.location.hash = window.location.hash;

This is hardly satisfying. Any better ideas?

comment:6 by Carsten Klein <carsten.klein@…>, 11 years ago

perhaps adding another named anchor following the anchor that leads to that fragment id should suffice?

<a href="#fragment">Modify Ticket…</a><a name="fragment"/>

comment:7 by Christian Boos, 11 years ago

Another (untested) idea would be to set the hash with js after the redirect, i.e. the address would be .../ticket/xyz?__location=comment:1 and some js would translate that to window.location.hash = 'comment:1'. But I fear this will also trigger a reload…

So no, I don't see anything better to do than what is proposed in comment:5.

by Remy Blank, 11 years ago

Work around IE bug when changing hash after redirect.

comment:8 by Remy Blank, 11 years ago

The issue is present in IE7, IE8 and IE9. The workaround in 10382-ie-no-reload-r10850.patch seems to work, and is only active on IE. There's a cosmetic drawback: when navigating to a page without a hash, an empty hash is appended to the URL in the address bar. This is due to the fact that assigning an empty string to window.location.hash sets it to "#" and not the empty string. More importantly, it means that every page shown right after a redirect is always requested (and therefore rendered) twice, and hence doubles the load on the server.

I don't like it (at all), but if we don't find anything better, I'll apply this for 0.12.3.

comment:9 by Remy Blank, 11 years ago

One more drawback is that a first click on the "Back" button after the reload will remove the # from the URL, and hence stay on the same page. Only a second click will go back to the page prior to the reload.

comment:10 by Christian Boos, 11 years ago

It's not that bad:

  • if we don't implement this workaround, you'll have anyway a second GET as soon as you trigger a collapse/expand, which will happen often as the Modify panel is collapsed by default… so this second GET has better to be a GET that won't discard your edits ;-)
  • I tried another approach, by simulating a manual click, but this also triggers the second GET (using dispatchEvent() in IE9, I have not tried with the IE specific fireEvent() but that one will probably not work at all as the doc says it doesn't trigger the default action)
  • I have the impression that the reload is done very early, before the rendering, although it is a bit hard to see what really happens here with the developer tools, as the network view gets reset when the second GET fires

So I'd say go for the "fix" ;-)

comment:11 by Remy Blank, 11 years ago

Resolution: fixed
Status: newclosed

Right. Let's go with this fix, then. Applied in [10851].

comment:12 by Remy Blank, 11 years ago

Owner: set to Remy Blank

comment:13 by Ryan J Ollos <ryano@…>, 10 years ago

Cc: ryano@… added

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain Remy Blank.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Remy Blank 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.