130380 - Page up/down don't scroll content when focus in urlbar

Status: RESOLVED INCOMPLETE

(Core :: DOM: UI Events & Focus Handling, enhancement)

Description

[Kee Hinckley]

The page up and page down keys (adb keyboard, if it matters) don't do anything.
 They should scoll the page.

Comment 1

[Kathleen :Brade]

Can you clarify what context you are in?  Are you in a Browser window?  Mail? 
Composer?  What is your build id?

Comment 2

[Kee Hinckley]

Sorry for the lack of detail.
Build 2002031005.

I had thought this was 100% reproduceable, but either it's not, or it's a
context issue.  In particular, while the scroll keys should scroll a textarea if
my cursor is in a text area (like it is right now), they ought to scroll the
page when the cursor is in a single line text region.

What I probably saw when I reported this was that I opened a new window and
tried to scroll it and it wouldn't.  The problem is that with a new window, the
cursor focus is in the url entry box, and page down/up scroll *that* instead of
the window.  I think that's pretty clearly not what the user expects.

Comment 3

[Bruce Davidson]

PgUp and PgDown seem to work fine normally (iBook keyboard). In either a
multi-line text area or a text input control they don't scroll the page, but
instead scroll the text area (which is of course a no-op on a single line text
input control). Personally, I believe this to be correct behaviour and we should
mark this as INVALID.

Comment 4

[Kee Hinckley]

This problem is more insidious than I thought when I first reported it.  When
I'm in a text area of any kind (including the URL entry area), *none* of the
navigation keys do what you would expect.  It's not just page-up and page-down.
 For instance command-left-arrow normally moves to the previous browser page,
but in a text region or in the URL entry area it moves to the beginning of the line.

We should separate this into three different categories and determine how each
should be addressed.

1. URL Entry
2. Single line text entry
3. Multi-line text entry

First of all, if a key makes no sense in the text region, then it ought to do
what it does when the focus is elsewhere.  The page-down/page-up keys make no
sense in single line text entry.  They are being used to dual purpose in the URL
entry area (they show the list of potential URLs), but I believe that is less
important than scrolling the page.

Secondly, if an accelerator is being used all the time for one purpose (moving
back and forth between pages) I don't see that you can suddenly use it for
another purpose (beginning and end of line) unless there is a compelling need. 
In that particular case you could always provide control-key as an alternative.

The issue is that the user is going to have no idea why the key isn't working. 
To all appearances nothing at all is happening.  Users have very little concept
of "focus".  They aren't going to know that just because they are sitting in a
text region all of their keys now do something else.  There's no visual feedback
that the meeting of all the keys has changed.  We've just made things modal and
given them no idea of the fact.

The only case where I think the local benefit possibly overrides the global
benefit is in multi-line text areas, where scrolling up and down in the text
area is *probably* more important, and more expected, than scrolling the page. 
But even there I'm not certain, and at the very least I'd give an alternative
(e.g. command-page-scroll) that will *always* scroll the page.  However I think
the safest solution would be to make the movement keys always behave
identically, regardless of context, and provide a set of modified keys to move
in the text area (e.g. command-page-down is for text areas, page-down is for the
screen).  This gives you a 100% consistent interface no matter where the focus
happens to be, and doesn't put additional burden on the user to figure out the
application's model of the universe.  I'm certain that's the model advocated by
Apple's (and just about anyone else's) style-guide, and as far as I know it's
the model used by all other browsers on the Mac (I justed tested IE and Opera, I
don't have a copy of OmniWeb handy).  When it comes down to it, the most
important aspect of a browser is not the text areas, it's the browsing, and the
keybindings should reflect this.

Consistency is by far the most important aspect of user interface design, and
it's better to be consitently wrong than inconsistently right.

Comment 5

[Bruce Davidson]

Command+Left arrow going to the start of the line in either a single- or
multi-line text input box is _exactly_ what I'd expect if we're obeying Apple
conventions. It would be extremely annoying to break that convention just so you
could go back to the previous browser page. However forwarding PgUp/PgDown to
the page if in a single line text box is reasonable.

Comment 6

[Kee Hinckley]

If command-left-arrow is going to go to the left end of the line in a text edit
box, then shouldn't it do the same thing on a page?  Scroll to the left?

Unfortunately every Mac browser I've ever used uses it to go the previous page.
 I don't care which one gets picked, but it should only do one thing, not
something different depending on the context.

One example of why the contextual meaning is so bad.  I just typed this message
in, and then used the scroll bar to go the bottom of the page to see what
comments were hear.  Having found that info, I wanted to move back up.  I
pressed PageUp and nothing happened.  I could just as easily have pressed
command-left-arrow.  The point is that I can't even *see* that my text cursor is
still in a text area, it's four screens up.  So I have *no* idea why my keyboard
isn't working properly.

Comment 7

[Darryl Zurn]

Kee Hinkley's comments are right on. If I click a link to bring up a new web
page, I want to use <PageDown> to *page* *down*, I definitely don't intend to
scroll through the URL list.

About 10 times per hour, using Mozilla, I'll click a link, hmm let's read more,
<PgDn> Cr*p! Jerks! <ESC>, <Tab>, THEN <PgDn> works as nature intended. 

PLEASE FIX.

Darryl Zurn
[e-mail]

Comment 8

[Darryl Zurn]

I should not have used that word in my earlier comment for this bug. Sorry

Thanks for the hard work on getting Mozilla to work so well on the Mac, but that
thing happens so frequently that I get pretty exasperated.

Darryl Zurn

Comment 9

[timeless]

*** This bug has been marked as a duplicate of 4302 ***

Comment 10

[Kathleen :Brade]

Actually, I don't think this is a duplicate of 4302 but some other page
navigation bug.  If you read comment 2, Kee Hinckley is complaining about page
up/down not scrolling the page when the focus is in the urlbar or in a
single-line widget.  In comment 3, Bruce Davidson disagrees and thinks it's
better than page up/down are no-ops (modulo comment 5?).

I don't think this is a Mac-specific issue.

Timeless--do you know what bug it's a duplicate of?

Comment 11

[Kee Hinckley]

Yes.  The issue of where the cursor goes when paging up and down is definitely
separate from the issue of whether paging up and down should page the page or
the current focus of the keyboard.

Personally I'd go with control sequences to scroll textareas and leave page
scrolling keys for what they say on the label--"Page" scroll.  That's what they
do in every other application, that's what they should do in Mozilla--no matter
what the focus.  Doing anything different flys in the face of every other
application and every other browser in existance.  It's not what the user expects.  

I get the impression that a number of the people in this discussion are emacs
users (as was I, before my pinky refused to move to hit the meta key one day--a
very scary thing).  So maybe this will ring true.  Modes are bad.  Users don't
think in terms of "My keyboard focus is in a menu so I'm in menu scroll mode" or
"My keyboard focus is in a text area so I'm in text area scroll mode".  Page
scroll should scroll the page. Use a different sequence for scrolling sub-elements.

Comment 12

[timeless]

arg. this bug is too long and too confused. can we start over?
step one is you need a better summary. If this summary survives for too much 
longer I'll kill this bug some way, either duping (because it is by summary) or 
invalidating.

Let's start by detailing some assumptions.
1. nc4w32 pagedown/up in the urlbar jumps to some page in the urlbar history.
2. nc4w32 pagedown/up in a single line input does nothing.
3. macos apps don't behave like this, but I'm entering this comment on w2k and 
have too many bugmails to read before i can spend time switching to my macs for 
comparisons (not that mozilla actually runs on them /helpwanted/).
4. 1-3 to me spell 'platform differences'
5. Comment 4 is simply too long, we don't need diatribes. at least we don't 
need them until after we have a clear description of the problem. details 
first, rants later -- preferably elsewhere.

Anyways.. enough of me ranting. yes I think i've probably seen a bug asking for 
these pieces, but i'm pretty sure it isn't an active bug (ie one i'll come 
across amongst the 750 unread bugmails in my bugmailInbox).

do what you like, but please start [A] by writing up simple steps to reproduce, 
and include the behavior of the following apps: ie5mac, ie5win, nc4mac, nc4win, 
opera-mac, opera-win. wannabe (mac). hypercard (mac) - design a stack that 
mimics mozilla. chimera (chimera.mozdev.org). And then [B] change the summary 
to clearly indicate the problem.

As for me, don't worry, I'm watching both zach and aaron, I'll get the bugmail 
-- eventually.

Comment 13

[Kee Hinckley]

Regarding comments from timeless:
1. I've changed the summary, and I've limited the platform to Macintosh.
2. I just went and tested both IE and Opera on the Mac--both of them treat
pageup/pagedown as page movers regardless of the keyboard focus which is as I
(and at least one other Mac user reporting here) would expect. To my surprise
(as you would probably gather from my "diatribe") IE 5 on Windows appears to
make it context-dependent, as does Netscape 4.7.  So it does appear to be a
platform-specific issue.
3. Regarding this "Comment 4 is simply too long, we don't need diatribes. at
least we don't need them until after we have a clear description of the problem.
details first, rants later -- preferably elsewhere."  I responded to what
appeared to be an attempt to dismiss the problem out-of-hand.  I'd be happy to
make such comments outside of the bug-tracking system, but as an end-user, this
is the only vehicle of communication I'm aware of for discussing bugs.

Comment 14

[Kathleen :Brade]

confirming based on comment 13

Comment 15

[Kathleen :Brade]

*** Bug 148374 has been marked as a duplicate of this bug. ***

Comment 16

[Dave Miller [:justdave]]

I think a good solution for the urlbar problem would be to not focus the urlbar
when a new window is opened in response to a link or a url event.  The urlbar
should only be focused by default if the window is opened by picking New
Navigator Window from the File menu.

If the urlbar has the focus, than I would expect my navigation keys to move me
around within that focus.  (And yes, I'm a Mac user).  The problem with the
urlbar as stated in comment #2 would go away if it were done this way.

Comment 17

[Frank Wein [:mcsmurf]]

*** Bug 170085 has been marked as a duplicate of this bug. ***

Comment 18

[Jonathan S Abrams]

A similar problem is occuring when using Apple+(left or right)arrow to navigate
forward and backward between pages.  It occurs when the focus is in a "search"
box on the page.

Would that be considered a bug?  Should this bug be modified to reflect that? 
Should a new bug be opened?

Comment 19

[Wayne Mery (:wsmwk)]

correct OS (apparently missed when HW was changed on 6/4/2002)

Comment 20

[Elliotte Rusty Harold]

Safari has the correct Mac behavior here. Emulate it.

In brief, even if the focus is in the location bar page up, page down, home and end still scroll the main window where the page is displayed. They do not move the cursor. 

Comment 21

[Bob]

I agree.  Command-(left or right) arrow should go to previous/next page even when in a text field (or the address bar).  This catches me multiple times every day.  The default behavior of Command-(left or right) arrow going to the beginning/end of the line is unnecessary since there is cntl-a and cntl-e for that.

This bug dates from 2002 and I'm using 3.0beta5 and this is still present.

Comment 22

[kikke]

The fix is here: http://www.starryhope.com/tech/apple/2006/keyfixer/
Since 2006...
Everythings works correctly with the script _inside_ the patch.

cp /Applications/Firefox.app/Contents/MacOS/chrome/toolkit.jar /tmp/toolkit.jar
cd /tmp/
unzip -oq toolkit.jar

Now, replace /tmp/content/global/platformHTMLBindings.xml with it:
http://pastebin.com/f5788c9a0

After all:

rm toolkit.jar
jar cf toolkit.jar content
cp /tmp/toolkit.jar /Applications/Firefox.app/Contents/MacOS/chrome/toolkit.jar

Thats all.

Comment 23

[David Bolter [:davidb] (NeedInfo me for attention)]

Mass un-assigning bugs assigned to Aaron.

Comment 24

[Josh Triplett]

Retitling this bug to reference page up and page down, as originally reported.  Home and end have a defined meaning in the URL bar and other editable text: they go to the beginning or end of the line.  However, page up and page down should work.  Technically they could scroll the dropped-down results from the awesomebar instead, but given how few results that normally shows, page up and page down seem much less likely than up and down.