From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16 i686; en-US; m18) Gecko/20000919 BuildID: 2000091908 Opening a new window always gives focus to the address bar of that new window. This is correct behavior in some instances. For example, Ctrl-N (new window), or Mozilla startup. However, when using open link in new window, this is wrong. The document should have focus instead. That way, document keyboard accelerators will work. (For example, under Linux at least Ctrl-W is close window when document has focus, and is delete word when the address widget has focus.) Reproducible: Always Steps to Reproduce: 1. go to any html page with links. (www.mozilla.org is a good choice) 2. either middle click on a link, or right click a link and use the open link in new window menu option. 3. Observe where the cursor ends up. Try scrolling through the document with the arrow keys. Actual Results: The address bar is given focus, and the user is scrolling through stored addresses. Expected Results: The document should have scrolled because focus should have been there.

i think this is either an xp toolkit/widgets or events issue... trying the former.

need the default owner here...

-> future. Yes, it would be better this way, or barring that, to just always focus the document, and have an easy keyboard shortcut to set focus in the URLbar.

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

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

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

Seem more than "trivial" to me - annoys me all the time, to the point where I have considered going back to Netscape 4.x several times. My usual problem is openning something I want to read in a new window, using the arrow keys to attempt to scroll the content; not only do I not scroll the content, but I *also* lose the URL, as it is scrolled away to nowhere. That combination of behaviours, and the frequency with which it affects me, makes it my most negative Mozilla experience.

Nominating for nsbeta1. I agree with this bug (for "open link in new window") but I'm not sure if I agree with bug 37638 (for opening any new window, including when starting Navigator or hitting Ctrl+N).

Also note that not giving the page body the focus results in the unsettling UI behavior below (build 2001020808, Linux): Enable the sidebar, and select/open the search panel. Collapse the sidebar. Open a link in a new window via mouse. The (hidden) search panel now has the keyboard focus, so the user can type away (such as an arrow key to scroll or any alphanumeric) to no apparent effect.

I agree that this is more than trivial severity. ->saari/normal, clearing target milestone.

I have a fix for this in my tree, I think. Not the best, but it'll do.

Blake, attach the patch, I'm curious what you did!

I'm waiting to checkin another fix before attaching it, but all I did was add a boolean (whether or not to set the focus to the content area) as a third window argument to navigator.js and act accordingly in Startup().

cool, sounds right, danke!

r=timeless cc'ing alec for sr

r=saari

sr=alecf

Fix checked in.

Close, but not quite. If the sidebar has focus (for example, the search box) then the new window gives focus to the sidebar again. This is somewhat counter-intuitive.

file a new bug.

>If the sidebar has focus (for example, the search box) then the new window >gives focus to the sidebar again. This is a separate bug that was introduced by the fix for bug 61417. If it annoys you, please comment in that bug asking for the patch to be temporarily backed out until bug 41813 and bug 50665 are fixed, or vote for one (or both) of the latter two bugs. Or you could turn off the search sidebar.

verified on linux build 2001-02-28-08

blake, you suck. Checking if window.arguments[2] == true without checking if you actually have the third argument. Tsk!

Uhhh...no. That was completely intentional. Checking first for the existence of a third argument is redundant and useless because window.arguments[2] will simply be null if it doesn't exist; a strict warning will not be thrown.

No, it will be === undefined if it does not exist, not null. Jag tells me this produces a strict warning, although I can't personally verify, it wouldn't exactly surprise me ;)

Either way, I don't get a strict warning about this.

I've just got a nit to pick with the recent fix. When you start Mozilla, the focus is still on the location bar. It seems to me that the focus should be on the content at startup, not the location bar. The focus should only be on the location bar only when using the "File|New Navigator Window" menu option or by hitting CTRL+N

I disagree. What's the first thing most people want to do when they start their browser? I'd say going to a webpage... Anyways, these are all separate bugs. Please split them off if necessary.

People generally have their home page set to a page that they use frequently. There is a good chance that, when they start the browser, it will already be on a page they want to see. Also, most people will want to go to a page from a bookmark, not by typing in a URL. Starting mozilla, then going to a bookmarked page will not change the focus away from the location bar. This is exactly the type of unintuitive behavior that this bug is supposed to be addressing. I'm just giving a different example of the same underlying problem.

This is about focusing the content area when you open a link in a new window, as the summary says. Good point about the bookmarks, but I already have another bug on focusing the content area when bookmarks are used.

vrfy fixed. 2/28-05 if you need to spam, please do it elsewhere.

Timeless: please be more polite when trying to prevent bugs from morphing. (Also, please note that trying to prevent each bug from morphing slightly can easily stifle conversation.)

Reopening. Sorry, Blake - this doesn't work in all cases. If you have the sidebar open when you "Open In New Window", it'll get focus on the new window. Win95 2001-03-24. Gerv

Reclosing because we've got a separate bug on that (history, bookmarks and search panels all grab focus on their own) (per discussion with Gerv on irc)

I'm guessing that other bug about sidebar elements stealing focus is bug 76621

See bug 97702 Using 2001083008, Sidebar closed. Middle Clicking or Right Click->Open in new window works fine. However, windows opened via JS still give focus to the location bar. Steps to Reproduce: 1) http://www.mozilla.org/quality/help/bugzilla-helper.html 2) Click on "See bugs in this component" button under step 3 3) Use the <page down> key. Result: Location bar drops open Expected Result: Page scrolls.

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

File a new bug please.

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