89835 - Window opened up with JavaScript has focus in the URL bar while NN4 and IE put focus on the content area

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect)

Description

[Martin Honnen]

With the test url above a window displaying http://www.mozilla.org/ opens but
keyboard focus is set on the URL bar so when you type you type in the url bar.
This is much different from NN4 and IE behaviour where focus is on the content
area of the window so that keyboard typing can be handled with JavaScript event
handlers. 
I will attach two pages building a test case showing while Mozilla's behavior of
putting keyboard focus in the URL bar is troublesome for JavaScript developers.

Comment 1

[Martin Honnen]

Attachment: used for bug demo (is opened by JavaScript and then attempts to handle key events which works with NN4 and IE4+ but fails with Mozilla as there the URL bar captures key events)

Comment 2

[Martin Honnen]

Attachment: bug demo (open this in Mozilla and NN4 and compare behaviour of the window then opened up with JavaScript, with Mozilla all typing goes to the URL bar while with NN4 JavaScript can handle the key events)

Comment 3

[Boris Zbarsky [:bzbarsky]]

Over to DOM 0.

The code in navigator.js that does the focusing is:

 // Focus the content area if the caller instructed us to.
 if ("arguments" in window && window.arguments.length >= 3 &&
     window.arguments[2] == true)
   _content.focus();
 else
   gURLBar.focus();

Is there a way to have window.open() pass in the third optional arg automatically?

Comment 4

[jag (Peter Annema)]

Actually I think the solution would be to have focus by default go to the
content area, unless specified to go to the urlbar.

It seems to me that in the common case what you want to do is navigate through
the content of the page you just loaded / opened. Only when opening a new
navigator window (Accel+N / File -> New Navigator Window) you're most likely to
want to edit the url.

Blake, what do you think?

Comment 5

[Jens Lautenbacher]

I can only second that... 
It's one of the most annoying things that often --- but not always :-( --- after
following a link the focus is in the locationbar, and I need to click 2 times
into the content area to (why 2 times I don't know, but if I click one time
only, the next cursor down (meant to scroll) pops up the autocompleter) before I
can use the keyboard again for scrolling.

Maybe one can think of a good strategy for predicting what is the most probable
action the user want's to take next, but I think most of the time, people want
to have focus on the contentarea after load of a new page.

Comment 6

[Joe Drew (not getting mail)]

I third that.

This is one of the most annoying bugs. I get so aggravated when I push down in a
window that's just opened and it instead messes up the URL bar. I wish someone
would fix this..

Oh wait. I did.

Comment 7

[Joe Drew (not getting mail)]

Attachment: Patch to reverse focusing priority: focus url bar when told; content default

Comment 8

[Joe Drew (not getting mail)]

I third that.

This is one of the most annoying bugs. I get so aggravated when I push down in a
window that's just opened and it instead messes up the URL bar. I wish someone
would fix this..

Oh wait. I did.

Comment 9

[jag (Peter Annema)]

The !window.locationbar.visible case is wrong with your patch. Make it &&
window.locationbar.visible.

I actually had a patch similar to this, but the problem with it is that you'll
also need to add logic to nsAppRunner.cpp to tell the newly opened window to
focus the urlbar.

Do you want to give it a try? Else I'll see if I can do this sometime soon.

Comment 10

[Joe Drew (not getting mail)]

Attachment: Revised URL patch file

Comment 11

[Joe Drew (not getting mail)]

This patch file fixes the one issue with the .js files. However, I don't know
that any C++ code needs to be modified: this just reverses an earlier patch
which focusses the content area when told, and focusses the URL bar on File->New
Window and launch. It does seem to work.

If you find issues with the patch as it currently is, though, I'll see what I
can do to address them.

Comment 12

[jag (Peter Annema)]

What your patch doesn't cover is focussing the urlbar when you start the
browser.

Comment 13

[Joe Drew (not getting mail)]

When I tested, the URL bar _was_ focussed on startup. I'll see if I can test
again here; if not, it'll have to wait until around 7-8pm EDT.

Comment 14

[Joe Drew (not getting mail)]

OK: I don't know why it happened when I was testing, but here in M0.9.2 with
modified .js files, the urlbar starts unfocussed. I'll see what I can do to fix it.

Comment 15

[Alec Flett]

reassigning to jag, he seems to be on top of this :)

Comment 16

[Jesse Ruderman]

The patch in this bug probably also fixes
bug 103758 upon startup, focus should be in the page content
bug 87946 focus goes to URLbar when opening new browser via Open Web Location 
[no form]

Comment 17

[jag (Peter Annema)]

[e-mail]: if you're still looking into this, you need to look at
http://lxr.mozilla.org/seamonkey/source/xpfe/bootstrap/nsAppRunner.cpp#370

There I create an nsISupportsWString with the url, that becomes
window.arguments[0]. You'll need to replace that with an nsISupportsArray, stuff
the nsISupportsWString in there at index = 0, and create a nsISupportsPRBool and
put it at index = 2. I suspect you'll need to create an nsISupportsVoid for
index = 1, but I'm not sure.

Comment 18

[Jesse Ruderman]

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

Comment 19

[jag (Peter Annema)]

Marking nsbeta1, could be fixed together with bryner's bug about where to place
focus on startup.

Comment 20

[Peter Trudelle]

nsbeta1+ per Nav triage team, ->1.0

Comment 21

[Peter Trudelle]

ADT3 per ADT triage team.

Comment 22

[Peter Trudelle]

Mass moving nsbeta1+/adt3 bugs assigned to Navigator team engineers out to
target milestone 1.0.1.  Please confine your attentions to driving down our list
of TM 1.0 bugs for beta.  Better to help, debug, or test one of them than fix
one of these.

Comment 23

[scottputterman]

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email [e-mail].  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.

Comment 24

[scottputterman]

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email [e-mail].  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.

Comment 25

[Niels Aufbau]

I haven't seen this bug for a while.  The testcase works, and the linked images
bookmarklet works correctly.