244664 - TestGtkEmbed - focus never leaves GtkMozembedWidget when tabbing

Status: RESOLVED FIXED

(Core Graveyard :: Embedding: GTK Widget, defect)

Description

[Christophe Cornu]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)
Build Identifier: 

Start TestGtkEmbed (tested on a GTK2 build of Mozilla)
Go to any website, e.g. http://www.gtk.org
Give focus to the url text widget.
Tab many times. Focus goes into the GtkMozEmbed widget and into each of the 
links as expected. Arrived at the bottom of the web page the following happens:
1. The url text widget briefly becomes selected and probably gains focus
2. Mozilla/GtkMozembed widget steals focus back from the text widget. The text 
widget loses focus and appears gray. Following tabs continue to traverse 
inside Mozilla.

Doing 'shift-tab' exhibits a similar problem (can't tab out of Mozilla).

Mozilla itself does not have this problem. Is this a bug in the embedding API 
nsIWebBrowserChromeFocus?

Reproducible: Always
Steps to Reproduce:
1.
2.
3.



Expected Results:  
It should be possible to tab in and out of Mozilla/GtkMozembed.

Comment 1

[Christophe Cornu]

This is reproducible with Mozilla 1.4 / Mozilla 1.7rc1

Comment 2

[Christian Persch (GNOME) (away; not receiving bug mail)]

I've investigated this a bit.

Here's what happens when I focus the last link in the page, and press Tab again:
- EmbedWindow::FocusNextElement is called
- the embed child gets focus-out event
- immediately, the embed grabs the focus again, and a focus-in event occurs.

http://lxr.mozilla.org/seamonkey/source/content/events/src/nsEventStateManager.cpp#3329

3329         PRBool tookFocus = PR_FALSE;
3330         nsCOMPtr<nsIDocShell> subShell = do_QueryInterface(pcContainer);
3331         if (subShell) {
3332           subShell->TabToTreeOwner(aForward, &tookFocus);
3333         }
3340         if (tookFocus) {
3341           SetContentState(nsnull, NS_EVENT_STATE_FOCUS);
3342           docShell->SetHasFocus(PR_FALSE);

TabToTreeOwner just calls EmbedWindow::FocusNextElement. This emits "move_focus"
on the toplevel, which really does move the focus to the next element of the
focus chain, and therefore the embed child gets a focus-out event. |tookFocus|
will be TRUE, and so we get to SetContentState:

http://lxr.mozilla.org/seamonkey/source/content/events/src/nsEventStateManager.cpp#3776
3776       PRBool fcActive = PR_FALSE;
3777       if (mDocument) {
3778         nsIFocusController *fc = GetFocusControllerForDocument(mDocument);
3779         if (fc)
3780           fc->GetActive(&fcActive);
3781       }
3782       notifyContent[2] = gLastFocusedContent;
3783       NS_IF_ADDREF(gLastFocusedContent);
3784       // only raise window if the the focus controller is active
3785       SendFocusBlur(mPresContext, aContent, fcActive);

Here |fcActive| will be TRUE when it should not be. Why? Because of the code in
EmbedPrivate::ChildFocusOut:

http://lxr.mozilla.org/seamonkey/source/embedding/browser/gtk/src/EmbedPrivate.cpp#783
783   piWin->Deactivate();
784 
785   // but the window is still active until the toplevel gets a focus
786   // out
787   nsIFocusController *focusController = piWin->GetRootFocusController();
788   if (focusController)
789     focusController->SetActive(PR_TRUE);

I.o.w., the window is deactivated, but the focus controller is active. Therefore
SendFocusBlur() calls nsWindow::SetFocus which gtk_widget_grab_focus()es the
embed again.

The code in EmbedPrivate::ChildFocusOut was introduced in bug 76617. However, it
does not seem to be necessary with gtk 2; the testcase from that bug, works fine
without it, and also appears to introduce no other focus problems. Maybe it can
just be removed for gtk 2 ?

Comment 3

[Christian Persch (GNOME) (away; not receiving bug mail)]

Attachment: proposed patch

Comment 4

[Christian Persch (GNOME) (away; not receiving bug mail)]

Comment on attachment 167156 [details] [diff] [review]
proposed patch

Oh well... :(

This breaks focusing the input field in web page doing focus in onload, like
google. The focus will be in the location entry instead (in Epiphany).

Comment 5

[Christian Persch (GNOME) (away; not receiving bug mail)]

This is fixed by the checkin from bug 210373.