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)

defect
Not set
major

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)

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.
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
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?
Also seen on Vista HP SP1 here - so OS = ALL ?
OS: Windows XP → All
Hardware: PC → All
Blocks: 386782
Keywords: regression
Version: unspecified → Trunk
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.
There is mention in the forums that this could be due to bug 429020
Severity: normal → major
Keywords: access, dogfood
Backing out the patch for bug 429020 fixes it for me.
Blocks: 429020
No longer blocks: 386782
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
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
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.
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.
Flags: in-litmus?
Yeah, this is a regression from bug 386782.
Assignee: nobody → peterv
No longer blocks: 429020
Attached patch v1 (obsolete) (deleted) — Splinter Review
This fixes it for me.
Attachment #317990 - Flags: review?(chris)
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
Status: NEW → ASSIGNED
Component: Keyboard Navigation → Keyboard: Navigation
Flags: blocking-firefox3?
Product: Firefox → Core
Flags: blocking1.9+
QA Contact: keyboard.navigation → keyboard.navigation
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.
additionally, clicking ctrl-f to open the find window regains you control.
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.
No longer blocks: 386782
Depends on: 386782
Reassigning based on comment 19.
Assignee: peterv → chris
Status: ASSIGNED → NEW
Comment on attachment 317990 [details] [diff] [review] v1 This was rolled into the regression fix patch in bug 386782.
Attachment #317990 - Attachment is obsolete: true
Attachment #317990 - Flags: review?(chris)
Whiteboard: [key hell][fixed by 386782]
Attached patch Peter V's patch with mochitest (deleted) — Splinter Review
(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)
Attachment #318539 - Flags: superreview+
Attachment #318539 - Flags: review?(jst)
Attachment #318539 - Flags: review+
Are we ready to check this in? Looks like it has JST's r+. Just wondering if we forgot to request approval here.
Comment on attachment 318539 [details] [diff] [review] Peter V's patch with mochitest Requesting approval1.9.
Attachment #318539 - Flags: approval1.9?
Blocks: 386782
No longer depends on: 386782
Whiteboard: [key hell][fixed by 386782] → [key hell]
Comment on attachment 318539 [details] [diff] [review] Peter V's patch with mochitest a+ schrep
Attachment #318539 - Flags: approval1.9? → approval1.9+
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
Keywords: checkin-needed
Whiteboard: [key hell][needs landing] → [key hell]
Target Milestone: --- → mozilla1.9
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
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.
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: