Closed Bug 165267 Opened 22 years ago Closed 22 years ago
Page Up and Page Down keys not working in browser
Bug 165244 may be a dupe of this, although that problem is on Mac, isn't immediate (the problem apparently appears some time after starting the browser), and affects the cursor keys as well.
I'm wondering if you got accessibility.browsewithcaret turned on by accident. Is there a caret blinking in your browser content? F7 is the key to toggle that on and off. Do arrow keys work to scroll the page?
WFM - 2002082804 trunk / XP.
When I press F7, it asks me if I want to turn Caret Browsing on. If I say yes, no caret appears, the Page Up and Page Down keys still don't work, and the arrow keys stop working. If I press F7 again, the arrows keys start working again, but the Page Up and Page Down keys don't.
It looks like the fix for bug 4302 (problems with Page Up and Page Down in Composer) is responsible for this regression. The keys work fine on builds before the fix for that bug landed (f.e. 2002-08-28-21).
Mike, I think this is yours.
Assignee: aaronl → mjudge
More info: - Myk and I tried to create a fresh profile, but the problem still occured. - Page Up/Dn did work when Myk was in Composer (just not in the browser)
Summary: Page Up and Page Down keys not working → Page Up and Page Down keys not working in browser
this works for me on windows. I dont even know where to begin. I think this is a dup of that mac bug. I dont know why this is happening but Kathy seemed to have a handle on it. does her fix fix this also?
Status: NEW → ASSIGNED
well I notice that control-end and control-begin are not working in composer now. I investigated and I believe someone on layout has rearranged the scroll views again. After getting the root scrollable view and getting its client data I am not able to find the BlockFrame properly. I will have to talk to someone on layout about this.
raising severity, sorry. This makes it very difficult to actually use any webpage longer than a page (eg any bug in bugzilla).
Severity: normal → major
Mike, maybe it would be easiest if someone expieriencing the bug let you debug on their system. Maybe bz can show you?
This affects Windows too. I'm seeing it in an optimized build from this evening on win2K. We cannot ship 1.2alpha with such basic functionality broken.
OS: Linux → All
Someone else screwed up here. my tree after I checked in worked. now that I just updated I am no longer even getting the message to scroll the page up or down. This is not even getting to the nsPresShell::ScrollPage method. someone hoarked events or keybindings in the last day. I wouldnt even know where to start debugging this. The code that was checked in for 4302 modified nsPresShell::PageMove heavily.`
OK. 5 minutes of investigation shows that the responsible checkins are these: http://bonsai.mozilla.org/cvsquery.cgi?module=MozillaTinderboxAll&date=explicit&mindate=1030541100&maxdate=1030542500 What happened was: 1) bindings were added to the various platformHTMLBindings.xml 2) bindings were removed from htmlBindings.xml reverting change #2 fixes the pgup/pgdown problem. I'm not sure why. All the platformHTMLBindings files have handlers for the VK_PAGE_UP keys... the difference is that the platform bindings bind those keys to cmd_movePage* while htmlBindings bound them to cmd_scrollPage*
Aha! brade's checkin removed the VK_PAGE_* keys from the browserBase binding and editorBase binding... They are defined on the editor (and textAreas) binding in platformHTMLBindings.xml, but _not_ on the browser binding. I'd suggest just reinstating the browserBase bindings in htmlBindings.xml
*** This bug has been marked as a duplicate of 165255 ***
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
mass-verification of Duplicates. mail search string for bugspam: SolarFlaresAreTheCause
Status: RESOLVED → VERIFIED
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.