Closed Bug 665964 Opened 13 years ago Closed 13 years ago

The backbutton stops working if an nsISHistoryListener vetoes navigation.


(Core :: DOM: Navigation, defect)

Not set



Tracking Status
firefox7 + fixed
firefox8 --- fixed


(Reporter: jrmuizel, Assigned: khuey)


(Blocks 1 open bug)


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


(1 file)

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....
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
tracking because if this is widespread, it would be concerning.
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.
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

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?
Whiteboard: [regression from 622315] → [regression from 622315][Inbound - Do not close the bug]
Whiteboard: [regression from 622315][Inbound - Do not close the bug] → [regression from 622315]
Attachment #544874 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+

I'm going to open another bug for the general audit.
Closed: 13 years ago
Resolution: --- → FIXED
Summary: The backbutton occasionally stops working → The backbutton stops working if an nsISHistoryListener vetoes navigation.
Target Milestone: --- → mozilla7
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?

And again with a nightly from 2011-08-31
Resolution: FIXED → ---
Open a new bug please.
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
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.