I am using Mac OS X (10.1.5) and Navigator 0.3.0 (11 June). When creating a new window in Navigator (either when first launching, selecting New Window in the File menu or Command-clicking a link), the window is not active. Using the page up/down keys or the arrow keys just result in an annoying "beep". You have to click somewhere in the window and then the keyboard navigation methods work fine. Click a link to a new page and it works fine. Even opening a new tab works without having to click inside the new tab first. This bug only affects new windows.

->bryner

albert, do you have a default home page set? or, do you have new pages (and/or tabs) set to open a blank page (about:blank)? in other words, what is the url in the Home Pref panel (or, do you have "use system preference" selected)? i'm not sure if these preference settings matter, it'd be good to see whether they do. fwiw, i can repro this quite easily using 2002.07.15.05 nb. 0. settings: mozilla.org is my home page (system pref checkbox is not selected). in addition, i've set the home to load when opening new windows and tabs. 1. hit cmd+N, or select File > New Window from the toplevel menu. 2. try to navigate with the keyboard (eg, hit spacebar, arrow keys, pageUp/Down, tab). results: nothing happens --get the annoying beep, as Albert pointed out... however, when i hit the tab key (which still didn't help wrt navigation/focus), the beeping stopped.

I have a home page set with "Use system Preferences" selected. I have new tabs open without loading my home page and a new windows loading with my home page. My home page is http://my.yahoo.com. This bug affects all new windows including when you initially launch Navigator. I have to click somewhere in the window before page up/down or the arrow keys will work for navigation purposes.

When a new tab or new window opens, the focus should be in the content window. About:blank is the only exception, where the focus should be in the location bar.

Looking for some feedback on this. Basically, what I've done is add a flag to CHBrowserWrapper::loadURI that tells it to focus the content area when the page finishes loading. This allows a lot of duplicated code to focus the content area to be consolidated. Odd things happen if I try to focus gecko any sooner than the completion of page loading. For example, the drawer will appear as a detached window. I'm not sure quite what's happening here, but I suspect it's because no document has been reflowed in the content area yet, so there aren't any widgets there to take focus. On a related topic, I'd really like to clean up the mess of functions that we use to open URL's. We have multiple methods on both MainController and BrowserWindowController for loading pages, opening pages in new windows, new tabs, etc. The number of possible code paths is pretty large, and makes it tough to consolidate things like deciding whether to focus the URL bar or content area. Also, we need to look at whether we actually need to do explicit loading of about:blank anywhere.

I haven't looked at your patch yet; but I'm wondering what happens if you go to a page that sets focus to a particular widget? Does that still work?

It should. All we do is tell Gecko to activate - that doesn't focus a different widget if gecko already has focus.

Comment on attachment 93501 [details] [diff] [review] first cut patch r=sfraser

Checked in.

Possible regression from this bug (from mailing list): I am sorry, but it only does this if the page has not loaded all the way and you quit. On Saturday, August 3, 2002, at 12:32 PM, John Dennis wrote: > Just so you can see this it seems to happen on versiontracker and aande. I am not sure why, but it does. > On Saturday, August 3, 2002, at 12:26 PM, John Dennis wrote: > >> Well I downloaded the nightly build this morning and it does an interesting thing. When I go to quit it looks as though it quits, but just then it pops the window back up for just a second before quitting. This is not a problem for me, but interesting just the same.

Sounds like we could be getting an onendload and trying to focus gecko as the app is shutting down. We should try to guard against this if that's indeed what is happening. I'll investigate on Monday.

Using 08-05 build on OS 10.1.5, the content window in new tabs have focus, but it doesn't seem like the content window in new windows have focus. 1. Launch 08-05 chimera build. 2. Cmd-N to open new window. 3. Use up and down arrow keys. Expected result: Content window scrolls up and down. Actual result: Content window does not scroll up and down. Need to mouseclick into the content window first before up/down arrow keys can be used. Is this what the patch intended to fix? As for the "Quit" possible regression, sfraser/bryner, could you file a new bug for it?

Oops, please disregard my comment #12. I wasn't using the most current build. Verified with 08-05 build on OS 10.l.5. sfraser/bryner - please open new bug for the quit issue.