All users were logged out of Bugzilla on October 13th, 2018

TestGtkEmbed - focus never leaves GtkMozembedWidget when tabbing



15 years ago
7 years ago


(Reporter: christophe_cornu, Assigned: blizzard)



Firefox Tracking Flags

(Not tracked)



(1 obsolete attachment)



15 years ago
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.
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 

Reproducible: Always
Steps to Reproduce:

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

Comment 1

15 years ago
This is reproducible with Mozilla 1.4 / Mozilla 1.7rc1
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.

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:
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
783   piWin->Deactivate();
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 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).
Attachment #167156 - Attachment is obsolete: true
This is fixed by the checkin from bug 210373.
Last Resolved: 13 years ago
Resolution: --- → FIXED
Component: Embedding: GTK Widget → Embedding: GTK Widget
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.