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

RESOLVED WORKSFORME

Status

()

Core
DOM: Core & HTML
RESOLVED WORKSFORME
17 years ago
16 years ago

People

(Reporter: Martin Honnen, Assigned: jag (Peter Annema))

Tracking

(Blocks: 1 bug, {polish})

Trunk
mozilla1.0.1
polish
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt3], URL)

Attachments

(4 attachments)

(Reporter)

Description

17 years ago
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.
(Reporter)

Comment 1

17 years ago
Created attachment 41575 [details]
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)
(Reporter)

Comment 2

17 years ago
Created attachment 41576 [details]
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)
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?
Component: URL Bar → DOM Level 0
OS: Windows 95 → All
Hardware: PC → All
(Assignee)

Comment 4

17 years ago
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

17 years ago
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.
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.
Created attachment 43590 [details] [diff] [review]
Patch to reverse focusing priority: focus url bar when told; content default
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.
Keywords: patch, polish
(Assignee)

Comment 9

17 years ago
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.

Created attachment 43652 [details] [diff] [review]
Revised URL patch file
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.
(Assignee)

Comment 12

17 years ago
What your patch doesn't cover is focussing the urlbar when you start the
browser.
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.
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

16 years ago
reassigning to jag, he seems to be on top of this :)
Assignee: alecf → jaggernaut

Comment 16

16 years ago
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]
(Assignee)

Comment 17

16 years ago
hoserhead@woot.net: 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

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

Updated

16 years ago
Blocks: 55416
(Assignee)

Comment 19

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

Comment 20

16 years ago
nsbeta1+ per Nav triage team, ->1.0
Keywords: nsbeta1 → nsbeta1+
Target Milestone: --- → mozilla1.0

Comment 21

16 years ago
ADT3 per ADT triage team.
Whiteboard: [adt3]

Comment 22

16 years ago
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.
Target Milestone: mozilla1.0 → mozilla1.0.1

Comment 23

16 years ago
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email adt@netscape.com.  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1-

Comment 24

16 years ago
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email adt@netscape.com.  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1+

Comment 25

16 years ago
I haven't seen this bug for a while.  The testcase works, and the linked images
bookmarklet works correctly.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.