Closed Bug 652748 Opened 9 years ago Closed 9 years ago

When reloading a bug page, any commentID (#nn) is lost


(Bugzilla :: Creating/Changing Bugs, defect)

Not set



Bugzilla 4.2


(Reporter: tonymec, Assigned: LpSolit)




(1 file)

Mozilla/5.0 (X11; Linux x86_64; rv:6.0a1) Gecko/20110417 Firefox/6.0a1 SeaMonkey/2.2a1pre ID:20110417003006

Reproducible: Always

Steps to Reproduce:
1. Display a bug page (for instance this one).
2. Go to one comment (e.g. click "Last comment" near top right, or "Description" or "Comment N" near the end of any comment header)
---> The URL displayed in your URL bar ends with #cN where N is the comment number. This is expected.
3. Reload the page (e.g. in Firefox or SeaMonkey, hit Ctrl+R)
---> The #cN part has disappeared from the displayed URL.
4. Scroll the page.
5. Click the Go button (if your browser has one), or else give focus to the URL bar then hit Enter.
---> The page does not go back to the comment shown at step 2.

Actual results:
See ---> lines above.

Expected results:
- At step 3, the URL should remain the same (with # and anchor ID at the end)
- At step 5, the page should scroll back to the comment displayed at step 2.

Additional info:
- By using similar steps on a page produced by Wikimedia software (e.g. a MozillaWiki page), I get the "expected" behaviour.
- This did not happen at BMO before the recent upgrade to Bugzilla 4.0. I haven't checked other Bugzilla installations.
I cannot reproduce. Aurora keeps #cN at the end of the URL, and then redisplay the page correctly and at the right place (as #cN isn't lost). I don't see how this could be a problem with Bugzilla. It's rather a problem with your web browser. Also, removing keywords which are of no use in the Bugzilla product.
Closed: 9 years ago
Resolution: --- → WORKSFORME
I can reproduce (incl in safe mode) using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110425 Firefox/6.0a1 ; as well as also Chrome 12.0.742.5 dev.

Doesn't seem to occur on landfill; believe BMO specific.
Assignee: create-and-change → nobody
Component: Creating/Changing Bugs → Bugzilla: Other b.m.o Issues
Product: Bugzilla →
QA Contact: default-qa → other-bmo-issues
Resolution: WORKSFORME → ---
Version: 4.0 → other
Ah ok, I couldn't reproduce, because I had browser.history.allow{Push,Replace}State both set to false in about:config. If I set them to true, then I can reproduce your issue. So this is due to bug 577720 upstream, but this bug was supposed to land in Bugzilla 4.2 only, not in 4.0. This means bmo backported this patch to 4.0.

pyrzak: note that Bugzilla 4.1.1 is also affected by this bug.
Depends on: 577720
I'll have a look.  May be a FF bug.
Oh, I see.  It just looks like bugzilla is calling replaceState(expected URI) even when it's at the expected URI.  I think Firefox is off the hook...
Bringing it back into Bugzilla as 4.1.1 is affected. I have a fix.
Assignee: nobody → create-and-change
Component: Bugzilla: Other b.m.o Issues → Creating/Changing Bugs
Product: → Bugzilla
QA Contact: other-bmo-issues → default-qa
Target Milestone: --- → Bugzilla 4.2
Version: other → 4.1.1
Attached patch patch, v1Splinter Review
Assignee: create-and-change → LpSolit
Attachment #528373 - Flags: review?(guy.pyrzak)
Comment on attachment 528373 [details] [diff] [review]
patch, v1

This seems to fix the issue with bmo/4.0 as well.
Attachment #528373 - Flags: review+
Attachment #528373 - Flags: review?(guy.pyrzak)
Flags: approval+
Committing to: bzr+ssh://
modified template/en/default/bug/show-header.html.tmpl
Committed revision 7790.
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
I still see the bug at BMO, but maybe comment #9 doesn't yet apply to it?
I checked in my patch upstream. bmo still has to pull it into its own repo.
It will be there when IT does a new code push to production.
The bughas now disappeared from => VERIFIED.
You need to log in before you can comment on or make changes to this bug.