spun off from bug 202157 comment 12. looks like this regressed btwn 2003.04.10.03 (works fine) and 2003.04.14.10 (broken). 1. turn on caret browsing (hit F7 key). 2. go to http://mozilla.org 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.
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)
Check-ins: <http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=04%2F11%2F2003&maxdate=04%2F12%2F2003+23%3A59%3A00&cvsroot=%2Fcvsroot> Bug 201400 did some work involving caret browsing during that time.
does this happen in composer and mail also?
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.
Keywords: nsbeta1 → nsbeta1-
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.
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?
This should be fixed by the checkin for bug 202157.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Fixed on 1.8 branch.
*** Bug 351249 has been marked as a duplicate of this bug. ***
(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 (188.8.131.52) 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:184.108.40.206) Gecko/20060728 Firefox/220.127.116.11? 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 http://forums.mozillazine.org/
You need to log in before you can comment on or make changes to this bug.