Submitting ticket changes breaks window.history on Chrome

[ethan.jucovy@…]

To reproduce, using Chrome Version 25.0.1364.99 (Mac)

1. Go to /newticket and file a new ticket
2. The page will reload at /ticket/N#ticket
3. Click "Modify Ticket"
4. The page does not reload. The URL bar now reads /ticket/N#no4
5. Click "Resolve as fixed" and click "Submit changes"
6. The page reloads. The URL bar now reads /ticket/N#comment:1
7. Click the browser's Back button
8. The page does not reload. The URL bar now reads /ticket/N#no4
9. Click the browser's Back button again.
10. (This is the point at which it becomes a bug.) The page does not reload. The URL bar now reads /ticket/N#comment:1

You are now stuck in a loop — no matter how many times you click the browser's Back button, the page will never reload, and the URL bar will just cycle its fragment between #no4 and #comment:1. To escape the loop you need to use the browser's History menu, or something like javascript:window.history.go(-2), or (the option that's become my habit) actually follow another link from the Trac UI or just type in a different URL in the browser.

This bug does not occur with Firefox 18.0.2 for Mac. I haven't tested on other browsers/OSes/devices.

[ethan.jucovy@…]

It seems like this is a Chrome bug more than anything else. But, this diff seems to fix it, by redirection after form submission to a URL that includes a querystring that will be unique for each ticket change. That convinces Chrome not to get stuck in a loop:

trac/ticket/web_ui.py

@@ -1398 +1398 @@
                            controller.__class__.__name__)
             controller.apply_action_side_effects(req, ticket, action)
 
+        fragment = "?reload=%s%s" % (cnum, fragment)
         req.redirect(req.href.ticket(ticket.id) + fragment)
 
     def get_ticket_changes(self, req, ticket, selected_action):

I haven't tested this for all cases (e.g. I'm not sure what will happen here if not cnum) but it seems to fix the issue for me. As I said though, it seems more likely that it's a bug in Chrome, so maybe this is too ugly a hack to put into trac.

[Christian Boos]

Replying to ethan.jucovy@…:

It seems like this is a Chrome bug more than anything else.

Right, I've been about to say that as well. I also use Chrome since a while, and late in the 24.x cycle I've started to notice such bad behavior with the history, and AFAICT by far not just with Trac. Now that I think more about it, things got much better after I disabled one or two Chrome plugins… maybe you want first to try if you can reproduce the bug without any Chrome plugin?

[ethan.jucovy@…]

Replying to cboos:

maybe you want first to try if you can reproduce the bug without any Chrome plugin?

Yup, I can still reproduce it with all plugins disabled, and no extensions installed.

I haven't managed to find any upstream issue filed about this yet, but this, from November 2011, sounds like the exact same bug: ​http://metatalk.metafilter.com/21214/Back-button-loop-in-chrome — so it does sound like it's not unique to Trac.

[Christian Boos]

Btw, reproduced with Chrome Version 26.0.1410.19 beta-m.

Still, all the other browsers I've tested behaved more or less sensibly, so I think it's a Chrome bug and we shouldn't try to add ugly workaround.

Speaking of ugly workarounds, with IE10, I have another glitch, as the step 6 shows: /ticket/N#__msie303:comment:1.

[anonymous]

I have had this problem ever since adopting Chrome as my main browser, for a couple of years, and it still occurs with 27.0.1453.93. It is probably a Chrome bug; not trac.

Workaround: pull down menu on back button and select the page I want to go to.

[jasimon9]

I just rechecked this bug and it appears to be fixed. You need to hit the back button three times to return from the edited ticket, but after the third click you are back on the report page; you are no longer stuck in the loop.

Btw, the anonymous entry of May 23, 2013 was from me.

[Ryan J Ollos]

Replying to jasimon9:

I just rechecked this bug and it appears to be fixed. You need to hit the back button three times to return from the edited ticket, but after the third click you are back on the report page; you are no longer stuck in the loop.

Tested with Chrome 91.0.4472.77 and also confirmed the issue is resolved.