Closed
Bug 430723
Opened 17 years ago
Closed 17 years ago
Arrow keys stop working after going back one page
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Core
DOM: UI Events & Focus Handling
Tracking
()
VERIFIED
FIXED
mozilla1.9
People
(Reporter: betheking, Assigned: cpearce)
References
Details
(Keywords: access, dogfood, regression, Whiteboard: [key hell])
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
jst
:
review+
jst
:
superreview+
mtschrep
:
approval1.9+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008042305 Minefield/3.0pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008042407 Minefield/3.0pre
After going back one page, arrow keys and page up/page down cannot be used to move up/down on page. Other keys, such as tab and alphanumeric keys still work, indicating that the browser has keyboard focus.
I've tested it on a few pages, and it seem to happen on all of them. One of the tests was on http://slashdot.org/
Reproducible: Always
Steps to Reproduce:
1. Open a new tab and load a page with a few links on it.
2. Follow a link. Navigate up and down on the page using arrow keys (or page up/page down).
3. Go back one page using alt-left.
Actual Results:
Arrow keys, page up and page down do not scroll the page in any way. Other keys, such as tab works, as well as find as you type.
Expected Results:
Page can be scrolled using the keys.
Could this be a regression from bug 386782? Nightly build from 20080423 works fine, the 20080424 build does not.
Comment 1•17 years ago
|
||
This also happens on Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9pre) Gecko/2008042404 Minefield/3.0pre
Scrolling with a touchpad works. Also, the usual keys work again after reloading the page on which they have stopped working.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 3•17 years ago
|
||
Also occurs for me on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008042511 Minefield/3.0pre
Flags: blocking-firefox3?
Comment 4•17 years ago
|
||
Also seen on Vista HP SP1 here - so OS = ALL ?
Updated•17 years ago
|
OS: Windows XP → All
Hardware: PC → All
Updated•17 years ago
|
Comment 5•17 years ago
|
||
FWIW, I had this with the space bar, which is what I use to scroll down, happen to me today. The space bar would do nothing. It wasn't working. I tried a different tab and it was working fine. It happened on a bugzilla page, while reading about another bug.
Comment 6•17 years ago
|
||
There is mention in the forums that this could be due to bug 429020
Updated•17 years ago
|
Comment 7•17 years ago
|
||
Backing out the patch for bug 429020 fixes it for me.
Comment 8•17 years ago
|
||
That's weird. I got different results (typed before your comment):
I've narrowed down the regression range using hourly builds from http://hourly-archive.localgho.st/mac.html - it regresses between 20080423_1434 and 20080423_1452.
Bonsai Query: http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1208986440&maxdate=1208987519
=> Bug 386782.
Moreover, I get a bunch of assertions which are probably connected to this bug.
When going back:
###!!! ASSERTION: mEditorFlags should not be 0: 'mEditorFlags != 0', file /Users/markusstange/Programming/mozilla/editor/composer/src/nsEditingSession.cpp, line 1397
###!!! ASSERTION: mStateMaintainer should exist.: 'mStateMaintainer', file /Users/markusstange/Programming/mozilla/editor/composer/src/nsEditingSession.cpp, line 1398
###!!! ASSERTION: mEditorFlags should still be valid...: 'mEditorFlags != 0', file /Users/markusstange/Programming/mozilla/editor/composer/src/nsEditingSession.cpp, line 1424
###!!! ASSERTION: mStateMaintainer should exist.: 'mStateMaintainer', file /Users/markusstange/Programming/mozilla/editor/composer/src/nsEditingSession.cpp, line 1425
###!!! ASSERTION: EnsureEditorData() called when detached.
: '!HasDetachedEditor()', file /Users/markusstange/Programming/mozilla/docshell/base/nsDocShell.cpp, line 9022
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file /Users/markusstange/Programming/mozilla/docshell/base/nsDocShellEditorData.cpp, line 255
###!!! ASSERTION: Failed to reattach editing session: 'NS_SUCCEEDED(res)', file /Users/markusstange/Programming/mozilla/docshell/base/nsDocShell.cpp, line 5334
When pressing down/up/space:
###!!! ASSERTION: This will stomp editing session!: '!mIsDetached', file /Users/markusstange/Programming/mozilla/docshell/base/nsDocShellEditorData.cpp, line 214
Comment 9•17 years ago
|
||
Backing out the patch for bug 429020 does not fix it for me (OS X 10.4).
Backing out the patch for bug 386782 does.
(In reply to comment #8)
> Moreover, I get a bunch of assertions which are probably connected to this bug.
Some of them are bug 430628 and bug 430615.
Blocks: 386782
Comment 10•17 years ago
|
||
Turns out I can't reproduce at all sometimes (even with both patches for bug 386782 and bug 429020 in place). I even see the assertions, but everything works as expected.
Comment 11•17 years ago
|
||
The following STR have worked for me very reliably:
1. Visit http://en-us.www.mozilla.com/en-US/firefox/central/
2. Click the link to Mozilla Add-ons (in the box at the bottom).
3. Click the back button.
4. Press up / down. (necessary for reproduction)
5. Click the forward button.
6. Press up / down - no effect.
Updated•17 years ago
|
Flags: in-litmus?
Comment 13•17 years ago
|
||
Yeah, this is a regression from bug 386782.
Assignee: nobody → peterv
No longer blocks: 429020
Comment 15•17 years ago
|
||
I can confirm that the patch fixes it.
But now clicking the back button triggers:
###!!! ASSERTION: Why detach an editor twice?: '!aSHEntry->HasDetachedEditor()', file /Users/markusstange/Programming/mozilla/docshell/base/nsDocShell.cpp, line 5345
###!!! ASSERTION: We're going to overwrite an owning ref!: '!(aData && mEditorData)', file /Users/markusstange/Programming/mozilla/docshell/shistory/src/nsSHEntry.cpp, line 851
Updated•17 years ago
|
Status: NEW → ASSIGNED
Component: Keyboard Navigation → Keyboard: Navigation
Flags: blocking-firefox3?
Product: Firefox → Core
Updated•17 years ago
|
Flags: blocking1.9+
Updated•17 years ago
|
QA Contact: keyboard.navigation → keyboard.navigation
Comment 16•17 years ago
|
||
interesting thing to note, if you have find as you type enabled, and start typing, you regain control using the arrow keys. when the find box closes, you lose the control again -- so it may very well have something to do with this.
Comment 17•17 years ago
|
||
additionally, clicking ctrl-f to open the find window regains you control.
Assignee | ||
Comment 19•17 years ago
|
||
I've included the changes made in the patch peterv posted with some others in the regression-fix patch for 386782. That patch fixes this bug, and a bunch of others.
Comment 20•17 years ago
|
||
Reassigning based on comment 19.
Assignee: peterv → chris
Status: ASSIGNED → NEW
Assignee | ||
Comment 21•17 years ago
|
||
Comment on attachment 317990 [details] [diff] [review]
v1
This was rolled into the regression fix patch in bug 386782.
Assignee | ||
Updated•17 years ago
|
Attachment #317990 -
Attachment is obsolete: true
Attachment #317990 -
Flags: review?(chris)
Updated•17 years ago
|
Whiteboard: [key hell][fixed by 386782]
Assignee | ||
Comment 22•17 years ago
|
||
(In reply to comment #21)
> (From update of attachment 317990 [details] [diff] [review])
> This was rolled into the regression fix patch in bug 386782.
>
After request from Roc, I'm splitting the 386782 regression fix patch out again into separate bugs. This is Peter V's patch with a mochitest. Since Peter and I have both worked on this, JST can you review this?
Attachment #318539 -
Flags: review?(jst)
Updated•17 years ago
|
Attachment #318539 -
Flags: superreview+
Attachment #318539 -
Flags: review?(jst)
Attachment #318539 -
Flags: review+
Comment 23•17 years ago
|
||
Are we ready to check this in? Looks like it has JST's r+. Just wondering if we forgot to request approval here.
Assignee | ||
Comment 24•17 years ago
|
||
Comment on attachment 318539 [details] [diff] [review]
Peter V's patch with mochitest
Requesting approval1.9.
Attachment #318539 -
Flags: approval1.9?
Assignee | ||
Updated•17 years ago
|
Comment 25•17 years ago
|
||
Comment on attachment 318539 [details] [diff] [review]
Peter V's patch with mochitest
a+ schrep
Attachment #318539 -
Flags: approval1.9? → approval1.9+
Assignee | ||
Updated•17 years ago
|
Keywords: checkin-needed
Whiteboard: [key hell] → [key hell][needs landing]
Checked in
Status: NEW → RESOLVED
Closed: 17 years ago
Flags: in-testsuite+
Flags: in-litmus?
Flags: in-litmus-
Resolution: --- → FIXED
Updated•17 years ago
|
Keywords: checkin-needed
Whiteboard: [key hell][needs landing] → [key hell]
Target Milestone: --- → mozilla1.9
Comment 29•16 years ago
|
||
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008053008 Firefox/3.0
Checks out on XP and OS-X. Marking as verified.
Status: RESOLVED → VERIFIED
Comment 30•16 years ago
|
||
I've noticed that the key up/down behavior doesn't work "right" (still have to press command plus left/right, at least on my Mac) in the "Bookmark this Page"/"Page Bookmarked" dropdown in FF3.0 (release).
Build identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0
If it matters, I'm using an en-GB build with the locale changed back to en-US in prefs... I like British spellings.
Updated•6 years ago
|
Component: Keyboard: Navigation → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•