Closed
Bug 665964
Opened 14 years ago
Closed 13 years ago
The backbutton stops working if an nsISHistoryListener vetoes navigation.
Categories
(Core :: DOM: Navigation, defect)
Core
DOM: Navigation
Tracking
()
RESOLVED
FIXED
mozilla7
People
(Reporter: jrmuizel, Assigned: khuey)
References
(Blocks 1 open bug)
Details
(Keywords: regression, Whiteboard: [regression from 622315][qa-])
Attachments
(1 file)
810 bytes,
patch
|
bzbarsky
:
review+
asa
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•14 years ago
|
||
I wonder if this is related to Bug 622315.
Comment 3•14 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.
Assignee | ||
Comment 4•14 years ago
|
||
I can reproduce that as well. I'll dig in here.
Assignee: nobody → khuey
Assignee | ||
Comment 5•14 years ago
|
||
This does not seem to be a regression from Bug 662315. Bisecting now.
Assignee | ||
Comment 6•14 years ago
|
||
I can only seem to reproduce this sporadically :-(
Assignee: khuey → nobody
Assignee | ||
Comment 7•14 years ago
|
||
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 | ||
Updated•14 years ago
|
Assignee: nobody → khuey
Component: Toolbars → Document Navigation
OS: Mac OS X → All
Product: Firefox → Core
QA Contact: toolbars → docshell
Hardware: x86 → All
Assignee | ||
Updated•14 years ago
|
Keywords: regression
Whiteboard: [regression from 622315]
Assignee | ||
Comment 9•14 years ago
|
||
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.
Assignee | ||
Comment 10•14 years ago
|
||
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 11•14 years ago
|
||
Comment on attachment 544874 [details] [diff] [review]
Fix at least one bug
r=me
Attachment #544874 -
Flags: review?(bzbarsky) → review+
Assignee | ||
Comment 12•14 years ago
|
||
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?
Assignee | ||
Comment 13•14 years ago
|
||
Assignee | ||
Updated•14 years ago
|
Whiteboard: [regression from 622315] → [regression from 622315][Inbound - Do not close the bug]
Assignee | ||
Comment 14•14 years ago
|
||
Whiteboard: [regression from 622315][Inbound - Do not close the bug] → [regression from 622315]
Updated•14 years ago
|
Attachment #544874 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Assignee | ||
Comment 15•14 years ago
|
||
http://hg.mozilla.org/releases/mozilla-aurora/rev/ffeea656548b
I'm going to open another bug for the general audit.
Status: NEW → RESOLVED
Closed: 14 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•14 years ago
|
||
I'm seeing this again on a nightly from 2011-08-09.
Comment 17•13 years ago
|
||
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•13 years ago
|
||
And again with a nightly from 2011-08-31
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 19•13 years ago
|
||
Open a new bug please.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 13 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 20•13 years ago
|
||
Done. Bug 683886
Comment 21•13 years ago
|
||
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.
Description
•