81668 - Embedding client needs to have focus on intial startup

Status: RESOLVED FIXED

(Core :: XUL, defect, P1)

Description

[John Gaunt (redfive)]

There is a window class by the name of MozillaWindowClass that needs to be given
focus during the startup. This clues the accessibility software ( written by
vendors ) to load our accessibility tree.

I have tracked down some stuff during startup. When we activate a call is made
to GlobalWindowImpl::Focus. During this call we don't have a PresShell yet, so
focus isn't give to the window. However after startup if you give focus to
another window and come back ( either by raising a window or alt-tabbing, then
alt-tabbing back ) when we enter the same code we do have a PresShell and are
able to give focus to the window.

cc-ing those who are in on the email thread going on about this

Comment 1

[John Gaunt (redfive)]

So it sounds like this is where we are at:

1) our implementation of an embedded client has a bug ( mfcembed ) and we should
be getting the proper focus. -- file a bug on mfcembed. Right now we get the
proper focus when alt-tabbing away and back, but don't when the application
starts up.

2) We should not take focus from the embedded client but have them give it to us
somehow. This would point to problem #1, and we should let those who are
embedding us know they should do this. -- make sure the documentation points
this fact out, somethings like "to ensure accessibility when the embedded client
startsup up method GiveFocusToFoo() needs to be called".

Comment 2

[John Gaunt (redfive)]

I just tried this with mozilla, I see the same behavior, except on startup focus
is given to a bunch of hidden windows of class "MozillaWindowClass". Alt-tabing
or clicking in the window gives focus to the non-hidden window of class
"MozillaWindowClass"

What exactly is the MozillaWindowClass? Is it ANY of our windows , or a top
level window? or something else?

Comment 3

[John Gaunt (redfive)]

The problem seems to be a difference between the timing of the call to activate. 
In mozilla we call activate later then we do in MFCEmbed. Therefore the 
PresShell has already been created. 

So it's kinda a chicken and the egg problem... well more chicken and the pig. 
See we cut the head off the chicken, but it takes awhile to die -- because 
loading a uri is done asynchronously -- but the pig is dead and we are ready to 
start cooking bacon, but we can't becasue the chicken is running around still.

Here is what I am looking at:
1) make another call to CBroswerFrm::OnActivate() from 
CMfcEmbedApp::OnNewBrowser() when we return from the first call. ( attaching 
stacks ) The problem is when we return from starting up the frame and such we 
still don't have a PresShell, so that call is not doing any good ( I suppose I 
could loop, but ew ).
2) In DocShell::OnStateChange() the listener for nsIWebProgress we can add a 
call to focus the mainwidget when the load is done, but then we're doing that 
everytime we load a page or other web content, again ew. Plus I don't know what 
that will do if we are loading in the background -- will it pop the app to the 
front?

In mozilla we focus a bunch of stuff that is reported as [hidden] by the MSAA 
tools and then finally focus the sidebar as the one and only not hidden 
MozillaWindowClass window. of course if you start clicking or tabbing around you 
get focuses on other MWC windows that aren't hidden.

Comment 4

[John Gaunt (redfive)]

Attachment: Stacks for the call to GlobalWindowImpl::Focus() for intial MFCEbmed and alt-tab x2

Comment 5

[John Gaunt (redfive)]

Just tried adding the last call in this block ( to setfocus() ) and it worked. 
We get a focus to a MozillaWindowClass window on startup of the MFCEmbed 
app. Haven't checked to see how fubar mozilla is with this in yet. 

line 3528
else if ((aStateFlags & STATE_STOP) && (aStateFlags & STATE_IS_NETWORK)) {
        // Page has finished loading
        mBusyFlags = BUSY_FLAGS_NONE;
        nsCOMPtr<nsIWidget> mainWidget;
        GetMainWidget(getter_AddRefs(mainWidget));
        if (mainWidget) {
            mainWidget->SetCursor(eCursor_standard);
        }
        // need to set focus here again, for embedding because the call
        //  to set focus is getting made too early.
        mainWidget->SetFocus(PR_TRUE);
    }

Comment 6

[saari (gone)]

That is probably going to break some of mozilla's behavior. We don't always
focus the content area when we're done loading a page. Opening a new window is
an example. If that still works, it is a timing dependent thing. Be sure to test
with pages with iframes too.

Comment 7

[John Gaunt (redfive)]

Yup, it sure did. Popped up windows that were supposed to be hidden during
startup. Well, one anyway.

Hyatt suggested a better way. Get the global focus listener in
nsGlobalWindowImpl::Focus(), only if we get there without having a PresShell,
and then call SetFocusedWindow() passing |this|. The result looks to be
successful, although we appear to be giving focus to a window that is normally
hidden and we can't tab around. But maybe that is another bug. I'm testing using
mozilla right now to make sure nothing glaring pops up. I'll have to get with
you, saari, and find out the focus testing I will need to do for this.

Comment 8

[saari (gone)]

Okay, I'm not surprised that you've focused a normally hidden window and can't
tab around. Too many hidden windows is a problem IMO, but we're stuck with that
for the time being.

So is this all happening in response to the native windows WM_ACTIVATE message
that the embedding application gets when it starts up?

Comment 9

[John Gaunt (redfive)]

I totally lied, hyatt's fix *isn't* working, I hadn't recompiled out the fix
above from nsDocShell. DOH!!! No more crack for me!

Comment 10

[John Gaunt (redfive)]

OK, it looks like it actually is doing what Hyatt says it should, it just isn't
getting reported to MSAA correctly. That is the next task, find out why we
aren't reporting correctly the first time.

Comment 11

[John Gaunt (redfive)]

Attachment: fix that almost works, and 2 stack traces for reference

Comment 12

[John Gaunt (redfive)]

Just posted a fix that hyatt recommended. It does fire the focus event on the 
global window when the pressShell is around, but the window is hidden still. 
Need to find a way around that part, delay the focus event or generate another 
focus event once everything is finished.

Comment 13

[Alex Weyers]

I suppose this has been a problem in our embedding case as well.

We've been forcing the focus onto the document by calling nsWebBrowser's 
implementation of nsIWebBrowserFocus::Activate().  We are doing this when our 
progress listener is notified that the document has finished transferring.  I 
guess this is the second case of John's two possible solutions.  It works for 
us.

Comment 14

[John Gaunt (redfive)]

alex: see bug 81668, it outlines our problem with hyatt's solution. just moving
the call to CheckForFocus to a later point.

Comment 15

[John Gaunt (redfive)]

I'm a dork. reference my bug in my bug.

I meant bug 83220

Comment 16

[John Gaunt (redfive)]

Attachment: proposed patch to nsGlobalWindow.cpp

Comment 17

[John Gaunt (redfive)]

Fixed in accessibility branch: Accessible_052901_Branch4

Comment 18

[David Hyatt]

sr=hyatt

Comment 19

[John Gaunt (redfive)]

checked in friday 29th to the trunk. letting it bake before pushing for branch (
0.9.2 ) checkin.

Comment 20

[lchiang]

adding vtrunk keyword to indicate the bug has been fixed on the trunk.  Bug left
open for tracking checkin to branch (nsbranch) when appropriate.

Once bug has been fixed on the branch also, pls remove vtrunk keyword.

Comment 21

[John Gaunt (redfive)]

Checked in on the 0.9.2 branch on wed 4 july.

Comment 22

[John Morrison]

May God have mercy on us all. The 212 bug spam-o-rama is Now!