Edgewall Software
Modify

Opened 12 years ago

Closed 4 years ago

Last modified 4 years ago

#11085 closed defect (worksforme)

Submitting ticket changes breaks window.history on Chrome

Reported by: ethan.jucovy@… Owned by:
Priority: normal Milestone:
Component: ticket system Version:
Severity: normal Keywords: chromebug
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:

Description

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.

Attachments (0)

Change History (7)

comment:1 by ethan.jucovy@…, 12 years ago

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

    diff --git a/trac/ticket/web_ui.py b/trac/ticket/web_ui.py
    index 4e3c0f4..03ea3d7 100644
    a b class TicketModule(Component):  
    13981398                           controller.__class__.__name__)
    13991399            controller.apply_action_side_effects(req, ticket, action)
    14001400
     1401        fragment = "?reload=%s%s" % (cnum, fragment)
    14011402        req.redirect(req.href.ticket(ticket.id) + fragment)
    14021403
    14031404    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.

in reply to:  1 ; comment:2 by Christian Boos, 12 years ago

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?

in reply to:  2 comment:3 by ethan.jucovy@…, 12 years ago

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.

comment:4 by Christian Boos, 12 years ago

Keywords: chromebug added
Milestone: not applicable

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.

comment:5 by anonymous, 12 years ago

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.

comment:6 by jasimon9, 10 years ago

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.

in reply to:  6 comment:7 by Ryan J Ollos, 4 years ago

Milestone: not applicable
Resolution: worksforme
Status: newclosed

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.

Last edited 4 years ago by Ryan J Ollos (previous) (diff)

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from (none) 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.