151039 - Window (page content) doesn't have "focus"

Status: VERIFIED FIXED

(Camino Graveyard :: General, defect)

Description

[Albert Kammerer]

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.

Comment 1

[saari (gone)]

->bryner

Comment 2

[sairuh (rarely reading bugmail)]

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.

Comment 3

[Albert Kammerer]

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.

Comment 4

[Winnie Lam]

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.

Comment 5

[Brian Ryner (not reading)]

Attachment: first cut patch

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.

Comment 6

[Kathleen :Brade]

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?

Comment 7

[Brian Ryner (not reading)]

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

Comment 8

[Simon Fraser [no longer active]]

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

r=sfraser

Comment 9

[Brian Ryner (not reading)]

Checked in.

Comment 10

[Simon Fraser [no longer active]]

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.

Comment 11

[Brian Ryner (not reading)]

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.

Comment 12

[Winnie Lam]

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?

Comment 13

[Winnie Lam]

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.