Closed
Bug 89835
Opened 23 years ago
Closed 22 years ago
Window opened up with JavaScript has focus in the URL bar while NN4 and IE put focus on the content area
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
WORKSFORME
mozilla1.0.1
People
(Reporter: martin.honnen, Assigned: jag+mozilla)
References
(Blocks 1 open bug, )
Details
(Keywords: polish, Whiteboard: [adt3])
Attachments
(4 files)
1.12 KB,
text/html
|
Details | |
431 bytes,
text/html
|
Details | |
2.51 KB,
patch
|
Details | Diff | Splinter Review | |
2.69 KB,
patch
|
Details | Diff | Splinter Review |
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•23 years ago
|
||
Reporter | ||
Comment 2•23 years ago
|
||
Comment 3•23 years ago
|
||
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•23 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•23 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.
Comment 6•23 years ago
|
||
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•23 years ago
|
||
Comment 8•23 years ago
|
||
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.
Assignee | ||
Comment 9•23 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.
Comment 10•23 years ago
|
||
Comment 11•23 years ago
|
||
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•23 years ago
|
||
What your patch doesn't cover is focussing the urlbar when you start the browser.
Comment 13•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
reassigning to jag, he seems to be on top of this :)
Assignee: alecf → jaggernaut
Comment 16•23 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•23 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•23 years ago
|
||
*** Bug 97702 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 19•23 years ago
|
||
Marking nsbeta1, could be fixed together with bryner's bug about where to place focus on startup.
Keywords: nsbeta1
Comment 20•23 years ago
|
||
nsbeta1+ per Nav triage team, ->1.0
Comment 22•22 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•22 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•22 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•22 years ago
|
||
I haven't seen this bug for a while. The testcase works, and the linked images bookmarklet works correctly.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•