103758 - upon startup, focus should be in the page content

Status: VERIFIED DUPLICATE of bug 37638

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

Description

[sairuh (rarely reading bugmail)]

i couldn't find an existing bug that fits this one...but do lemme know if it's a
dup. bryner/saari, feel free to reassign as needed.

basically, when i start up the browser, i expect to be able to have focus in the
web page content, not the URL bar --mainly so i can start scrolling immediately
with the keyboard.

recipe:
0. have your browser's start page be something other than about:blank. i chose
http://mozilla.org.(*)
1. make sure you don't have mailnews, browser, editor, etc already running [just
to simplify this]; quit as needed.
2. start the browser.
3. after the page loads, try to scroll/navigate using the following: spacebar,
pageDown/pageUp keys, arrow keys.

result: cannot. focus is in the URL bar.

this is similar to bug 37638, where focus is in the URL bar for browser windows
opened via accel+N or File > New Navigator Window.

(*) important note:
------------------
i noticed that if i set my home page to a page where the page content explicitly
sets focus, then that is respected by the browser. for example, if i set home to
be http://bugzilla.mozilla.org, then upon startup focus is in the page
[specifically, the query textfield in this case], not in the URL bar.

Comment 1

[Sean Harding]

It would be nice to still have the focus be the URL bar if your home page is
about:blank. That's how mine is set, and it would be just as much of an
annoyance to me to have to move focus before I can type in an URL as it is for
you to have to move focus to scroll...

Comment 2

[Danek Duvall]

It's not *quite* the same, but you can just press ctrl-l and start typing, which
is almost like having the focus in the location bar in the first place.  In
fact, it shouldn't be more keystrokes, since you have to get rid of the existing
text somehow anyway (ctrl-u, I guess), as it's not hilighted.  Someone's fingers
are going to have to relearn something, though, unless it's made configurable.

Comment 3

[Sean Harding]

And shift-tab (at least on Unix) takes you out of the control bar into the
content so you can scroll, which is almost as good as having the focus there in
the first place. Heh. (It is more keystrokes because there is no text to get rid
of; the URL bar is empty in a new browser window when the home page is set to
blank).

I don't have super strong feelings about this. It won't ruin my day if it's
changed. But I think it's the "right" thing to do to have focus in the URL bar
for new windows with no content loaded and in the content for new pages that do
have content loaded. It's a better user experience.

Comment 4

[Danek Duvall]

*Shift*-tab!  Dang.  Here I've been trying to figure out how many (normal) tabs
it takes to get into the content pane.  It's a good workaround for me (but just
a workaround).

I think you're right about how to "configure" this by leaving your homepage
blank.  My comment about the keystrokes was based on having "about:blank" there
instead of nothing.  My misunderstanding.

Of course, this doesn't take care of pages brought up via middle-click, but
that's not technically covered by this bug.

Comment 5

[Brian Ryner (not reading)]

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

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This really doesn't seem to be a duplicate of bug 87946, and bug 37638 is not
really focused anymore.  Should this be reopened?  FWIW, MacIE5, WinIE 5.5, and
NN 4.77 on Windows and Linux all allow scrolling of the web page content when a
new window opens with the home page in it.  (I agree that the focus should be on
the URL bar when we load about:blank as the homepage.  Perhaps all these
problems about how to communicate the method used to load the page to the code
that focuses the URL bar could be solved by simply focusing the URL bar only if
about:blank was loaded (in the manner that causes the URL bar to display "")?)

Comment 7

[sairuh (rarely reading bugmail)]

agreed. i don't quite understand why this was dup'd... at the very least, i'd
like to keep this open as a separate testing situation.

Comment 8

[Ashley Bischoff (blog at handcoding.com)]

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

Comment 9

[Adam Kramer]

"It would be nice to still have the focus be the URL bar if your home page is
about:blank," mentioned by Sean Harding, does not hold of the Macintosh build
2001101701. (See bug 107932)

Comment 10

[sairuh (rarely reading bugmail)]

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

Comment 11

[Brian Ryner (not reading)]

Attachment: patch

Comment 12

[Brian Ryner (not reading)]

Jag, can you r= this?

Comment 13

[jag (Peter Annema)]

Comment on attachment 61033 [details] [diff] [review]
patch

>Index: navigator.js
>===================================================================
>RCS file: /cvsroot/mozilla/xpfe/browser/resources/content/navigator.js,v
>retrieving revision 1.413
>diff -u -r1.413 navigator.js
>--- navigator.js	8 Dec 2001 07:50:06 -0000	1.413
>+++ navigator.js	10 Dec 2001 00:42:17 -0000
>@@ -264,6 +276,25 @@
>   return true;
> }
> 
>+function tabToUrlBar(event)
>+{
>+  if (event.keyCode == 9) {

>+    var contentArea = document.getElementById("appcontent");
>+    contentArea.removeEventListener("keypress", tabToUrlBar, false);
>+    contentArea.removeEventListener("blur", removeTabListeners, true);

Just call removeTabListeners() instead.

r/sr=jag with that change.

Comment 14

[Johnny Stenback (:jst)]

Comment on attachment 61033 [details] [diff] [review]
patch

sr=jst

Comment 15

[Brian Ryner (not reading)]

checked in.

Comment 16

[Diego Biurrun]

This fix is apparently causing an evil focus stealing regression on finishing
page load.  Please revise the patch.  See

http://bugzilla.mozilla.org/show_bug.cgi?id=114930#c7

Comment 17

[Jerome Lacoste]

As a comment to the patch, we should perhaps add some symmetry to the
removeTabListeners(event) function.

Replace:
+    _content.focus();
+    var contentArea = document.getElementById("appcontent");
+    contentArea.addEventListener("keypress", tabToUrlBar, false);
+
+    // This lets us get out of the tabbing sequence if the user clicks.
+    contentArea.addEventListener("blur", removeTabListeners, true);


with:
+    _content.focus();
+    addTabListeners(null);     // correct parameter?

and

+function addTabListeners(event)
+{
+    var contentArea = document.getElementById("appcontent");
+    contentArea.addEventListener("keypress", tabToUrlBar, false);
+    // This lets us get out of the tabbing sequence if the user clicks.
+    contentArea.addEventListener("blur", removeTabListeners, true);
+}


I think symmetry improve maintenance.

Comment 18

[Diego Biurrun]

Bryner, how about backing this out for the branch and coming up with a corrected
patch for the trunk?  At the moment we have traded a fix for a small nit against
a major annoyance...

Comment 19

[Brendan Eich [:brendan]]

Absolutely, back this out of the 0.9.7 branch and trunk, and do a better fix for
0.9.8 when you can.  Adding mozilla0.9.7+ keyword, linking to tracking bug, and
reopening.  a=[e-mail] on the branch back-out.

/be

Comment 20

[[not reading bugmail]]

this bug report sounds like multiple issues here:

doesn't sound like a problem with focusing.. but keyboard doesn't allow ( or is
not implemented using the arrow keys or the pgup/pgdn.) using the page described
in the *important note I see I can scroll with the mousewheel just fine.  

A) if the problem is you want the focus on startup to always be the url bar that
is different that being able to tab upto the urlbar after loading page for
bugzilla.  as is the problem in bug 114976.  Then the initial focus before
pageload outa be the URLbar regardless of the page content.

B) if the issue is upon loading bugzilla page that has the focused cursor,
you're saying you want to use the keyboard to scroll thru the document.. Sounds
like the keyboard is not hooked upto the scrolling like mouse-wheel is.

Comment 21

[[not reading bugmail]]

so on one side of the fence you have people using the homepage perf to a page
they know they want to see the desired content on opening the browser.. or
afterward will use tabs or URL to create a new tab for new desired page content.
 So they want focus to be in page content.

on the other side of the fence you have people that are either both really
clueless about the homepage feature and want to type in a random page they want
to look at.    or just open the browser to quickly look at something at hit the
tab key to get to the URL bar.. So then they want the focus to be defaulted to
the URLbar.  

Tab order used to work just fine before.. now with tabs/frames/URLbar/and
textbox/page content  this seems on the outside like a more difficult issue to fix.

Comment 22

[Brian Ryner (not reading)]

Not going to have a regression-free fix for this for 0.9.7.

Comment 23

[Brendan Eich [:brendan]]

bryner backed out the regressive fix from the 0.9.7 branch, so removing this bug
from that milestone's tracking bug.

/be

Comment 24

[Diego Biurrun]

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

Comment 25

[Diego Biurrun]

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

Comment 26

[Brian Ryner (not reading)]

-> 0.9.9

Comment 27

[savardd]

The same problem comes when opening an URL from with the TARGET tag.

For exemple:
http://www.mozilla.org/quality/help/bugzilla-helper.html
click on the Login link in Step1 and the focus will be on the URL bar instead of
the document and cause that we can't start scrolling the document befor clicking
two times on the document.  

(I don't know why I need to click twice on the document to be able to scroll it)

Comment 28

[R.K.Aa.]

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

Comment 29

[sairuh (rarely reading bugmail)]

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

Comment 30

[sairuh (rarely reading bugmail)]

note to self: test the case of bug 87946 once this is resolved.

Comment 31

[S. Malling]

Thoughts:
When navigator is launched /new windows is opened...... what if we have a
special mix of focus....

Like this
1. ulr is highlited, so you easely could start typing
2. focus shifts to "normal ulr-bar-focus" if you pressed left or right arrow
(cursor move)
3. focus shifted to "normal page-focus" if up/down arrow, page up/page down was
pressed, (instead of that netscape search) maybe home/end too.

This should only be set when new windows are created.

If we can make is this way, I think everybody should be happy :-)

Comment 32

[Brian Ryner (not reading)]

Nominating for nsbeta1 triage.

Comment 33

[Chris McAfee]

I HATE this bug.  please nominate, fix, escalate, whatever it takes.

Comment 34

[lohphat]

I can't rememeber if this is part of this bug or related:

On startup, even if I click on the page content, hitting the spacebar will not
scroll because the focus is still in the location bar.  The only way to get
scrolling focus is to click on the vertical scrollbar area first.

Comment 35

[Diego Biurrun]

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

Comment 36

[Peter Trudelle]

nsbeta1+ per Nav triage team

Comment 37

[[not reading bugmail]]

I dont mind the way it currently works, as I use the mouse to get to URL, open a
link and then by habit I click on the page content, and either A) scroll with
the mouse wheel, or hit pgup/pgdn.. to move up and down.  So this is a work
around I current use by habit and I'm not really bothered by the way it is
currently implemented.

Comment 38

[Brian Ryner (not reading)]

Duping against 37638 - there is a patch there that will fix this as well.


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

Comment 39

[sairuh (rarely reading bugmail)]

okay, v.