The default bug view has changed. See this FAQ.

The backbutton stops working if an nsISHistoryListener vetoes navigation.

RESOLVED FIXED in Firefox 7

Status

()

Core
Document Navigation
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: jrmuizel, Assigned: khuey)

Tracking

(Blocks: 1 bug, {regression})

unspecified
mozilla7
regression
Points:
---

Firefox Tracking Flags

(firefox7+ fixed, firefox8 fixed)

Details

(Whiteboard: [regression from 622315][qa-])

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
I've seen this twice now. The back button remains inactive even after navigating to different pages. It only seems to affect a single tab. I have no idea how to reproduce it.
I wonder if this is related to Bug 622315.
Could be....
tracking-firefox7: --- → ?

Comment 3

6 years ago
I can reproduce this by opening a new tab, starting a page load then cancelling it immediately. No matter where I navigate in that tab from then on, the back button is always disabled.
I can reproduce that as well.  I'll dig in here.
Assignee: nobody → khuey
This does not seem to be a regression from Bug 662315.  Bisecting now.
I can only seem to reproduce this sporadically :-(
Assignee: khuey → nobody
I still haven't been able to come up with reliable STR, but I managed to hit this and popped into a debugger and the issue is indeed that mRequestedIndex is not reset.  At this point I'm just going to try to audit the relevant codepaths.
Assignee: nobody → khuey
Component: Toolbars → Document Navigation
OS: Mac OS X → All
Product: Firefox → Core
QA Contact: toolbars → docshell
Hardware: x86 → All
Blocks: 622315

Comment 8

6 years ago
tracking because if this is widespread, it would be concerning.
tracking-firefox7: ? → +
Keywords: regression
Whiteboard: [regression from 622315]
Brief summary:

In bug 622315 we gated navigation on checking nsSHistory::mRequestedIndex to see if there was already a pending navigation.  mRequestedIndex does not always get reset properly, so there are times where we think we're navigating and disable back/forwards when we shouldn't.

Without reliable STR this is going to be difficult to fix.  We can back out the regressing changeset if it comes to that.  This affects 7, so we have some time to figure this out.
Created attachment 544874 [details] [diff] [review]
Fix at least one bug

If the nsISHistoryListener vetoes we don't set mRequestedIndex.  This can't be hit in stock Firefox, afaict, but an addon could trigger this.
Attachment #544874 - Flags: review?(bzbarsky)
Comment on attachment 544874 [details] [diff] [review]
Fix at least one bug

r=me
Attachment #544874 - Flags: review?(bzbarsky) → review+
Comment on attachment 544874 [details] [diff] [review]
Fix at least one bug

Drivers, this fixes a particular codepath that addons can trigger in Firefox 7 that will cause forward/backwards to stop working on the tab.
Attachment #544874 - Flags: approval-mozilla-aurora?
http://hg.mozilla.org/integration/mozilla-inbound/rev/2ca111e7c2fb
Whiteboard: [regression from 622315] → [regression from 622315][Inbound - Do not close the bug]
http://hg.mozilla.org/mozilla-central/rev/2ca111e7c2fb
Whiteboard: [regression from 622315][Inbound - Do not close the bug] → [regression from 622315]

Updated

6 years ago
Attachment #544874 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
http://hg.mozilla.org/releases/mozilla-aurora/rev/ffeea656548b

I'm going to open another bug for the general audit.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
status-firefox7: --- → fixed
status-firefox8: --- → fixed
Resolution: --- → FIXED
Summary: The backbutton occasionally stops working → The backbutton stops working if an nsISHistoryListener vetoes navigation.
Target Milestone: --- → mozilla7
(Reporter)

Comment 16

6 years ago
I'm seeing this again on a nightly from 2011-08-09.
Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20100101 Firefox/7.0

I tried to verify this fix, but i wasn't able to reproduce this issue with the steps in Comment 3. Can anyone please help me with a test case or with thorough STR in order to get this issue checked on QA side?

Thanks!
(Reporter)

Comment 18

6 years ago
And again with a nightly from 2011-08-31
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Open a new bug please.
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED
(Reporter)

Comment 20

6 years ago
Done. Bug 683886
qa- as we are unable to reproduce the issue on an unpatched build. Can someone who is able to reproduce the bug before please verify this fix?
Whiteboard: [regression from 622315] → [regression from 622315][qa-]
You need to log in before you can comment on or make changes to this bug.