Mac fails to scroll with pageDown or pageUp in caret mode (browser)




Keyboard: Navigation
15 years ago
12 years ago


(Reporter: sairuh (rarely reading bugmail), Assigned: Simon Fraser)


({fixed1.8.1, pp, regression})

Mac OS X
fixed1.8.1, pp, regression
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)





15 years ago
spun off from bug 202157 comment 12.

looks like this regressed btwn 2003.04.10.03 (works fine) and 2003.04.14.10

1. turn on caret browsing (hit F7 key).
2. go to
3. mouseclick the pointer near the top, eg, in the "Mozilla News" section, to
the left of "Mozilla 1.4 Beta Released..."
4. try to scroll using the PageDown key.

results: no scrolling occurs, caret fails to move.

Comment 1

15 years ago
some notes:

* doesn't seem to matter what the content is. a simple html page consisting of
lines of text (<br>'s), or even just one <br> that's scrollable, will show this.

* the four arrow keys remain working, as do Home and End.

narrower regression window:

works fine with 2003.04.11.08
broken with 2003.04.12.03
Summary: Mac fails to scroll with pageDown or pageUp in caret mode → Mac fails to scroll with pageDown or pageUp in caret mode (browser)

Comment 3

15 years ago
does this happen in composer and mail also?
Keywords: nsbeta1

Comment 4

15 years ago
this is not an issue in either composer or mail compose.

this is a problem when caret mode is ON in the browser --or while reading a mail
messages containing an html page (msg pane in 3pane window or standalone mail
window) with caret mode ON.

Comment 5

15 years ago
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-

Comment 6

15 years ago
Still in 1.4 full release. This bug baffled me because there is no indication
that one is in caret mode that I can tell. I simply couldn't Page Up or Page
Down. Very weird.


13 years ago
Blocks: 241023
This is certainly due to bug 201560 (checked in on 2003-04-11 20:08).
Notice the following comment in nsSelectMoveScrollCommand::DoCommandBrowseWithCaretOff:

// cmd_ScrollPageUp/Down are used on Mac. They do not move the
// caret in caret browsing mode.
Actually, that comment goes back to bug 165255 comment 20, where Aaron wrote:

> If you want, add a comment that explains that cmd_scrollPage* is used for mac,
> and cmd_movePage* is used for other platforms, since mac doesn't move the caret
> on pageup/pagedown, even in browse with caret mode.

I don't really understand what this means (especially the "even" part), but it makes this look as if it's by design. Aaron - can you please explain?


12 years ago
Depends on: 202157
This should be fixed by the checkin for bug 202157.
Last Resolved: 12 years ago
Resolution: --- → FIXED
Fixed on 1.8 branch.
Keywords: fixed1.8.1
*** Bug 351249 has been marked as a duplicate of this bug. ***

Comment 12

12 years ago
(In reply to comment #11)
> *** Bug 351249 has been marked as a duplicate of this bug. ***

As the filer of bug 351249, I'm a bit confused.  I'm merely a (l)user, but if the current version of FF ( exhibits the unwanted behavior, how is it that the bug is marked RESOLVED DUPLICATE and points to a bug marked RESOLVED FIXED?  How does the 1.8 branch related to the current version of FF Mac, which IDs itself as User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv: Gecko/20060728 Firefox/

Thanks for your time.
(In reply to comment #12)

This is fixed for Firefox 2.0 (built on Gecko 1.8.1), and onwards.

A better place for such questions is the MozillaZine forums, at
You need to log in before you can comment on or make changes to this bug.