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

[haisland@…]

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.

Result

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!

[Christian Boos]

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.

[haisland@…]

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

[haisland@…]

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

[Christian Boos]

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

[haisland@…]

Dear cboos,

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

[Remy Blank]

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;
</script>

This is hardly satisfying. Any better ideas?

[Carsten Klein <carsten.klein@…>]

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"/>

[Christian Boos]

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.

[Remy Blank]

Work around IE bug when changing hash after redirect.

[Remy Blank]

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.

[Remy Blank]

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.

[Christian Boos]

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" ;-)

[Remy Blank]

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