127694 - GNotebook focus bug

Status: RESOLVED DUPLICATE of bug 210373

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

Description

[Marco Pesenti Gritti]

With two tabs open in galeon, if you reload one of them, then fastly switch to
other, at some point the focus is removed from the active tab and set on the
inactive one.
This happen because every time a new url is loaded the focus is grabbed on the
owner gtkmozembed widget.
I thought to two ways to fix the problem:

1 on nsWidget::SetFocus return NS_ERROR_FAILURE if the mozarea is not visible
2 Add a set_focus callback to gtkmozembed with a gint return value so we can
decide to not let the focus to be set. (This unfortunately required also a
change in GlobalWindowImpl::Focus())

They both appear to fix the problem, but I'm not sure if they are correct.
In the case they are not can you please suggest a way to fix it ? I'm bored to
close duplicated of this bug :)

(Unlike in mozilla SetFocus doesnt work unless you have already clicked on the
embed one time, should I post a separate bug ?)

Comment 1

[Marco Pesenti Gritti]

If you need a testcase please let me know.

Comment 2

[Kai Lahmann (is there, where MNG is)]

Marco: has somebody fixed this?

Comment 3

[Kenneth Herron]

Mpeseng, could you check and see if this problem still exists?

Comment 4

[Marco Pesenti Gritti]

I cant reproduce it anymore but I'm using gtk2 toolkit, not sure if it makes a
difference

Comment 5

[Tommi Komulainen]

Attachment: Automatically refreshing page with onload="document.foo.focus()"

This page triggers the bug for me...

Comment 6

[Zibi Braniecki [:zbraniecki][:gandalf]]

WFM - Mozilla 20030509.

Comment 7

[Kai Lahmann (is there, where MNG is)]

as comment says

Comment 8

[Tommi Komulainen]

I have both galeon and mozilla from yesterday trunk, gtk2 builds, and the
attached page is still consistently grabbing the focus.

Comment 9

[Mark Howard]

This is definitely not fixed with galeon 1.3.10 and mozilla 1.5. Can somebody
reopen this please?

Comment 10

[Crispin Flowerday (not receiving bug mail)]

This is still an embedding problem. It isn't a problem in mozilla proper.

Reopening.

Comment 11

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

Attachment: possible fix

The cause of this bug are the toplevel focus in/out handlers. They're designed
for a 1:1 relationship between toplevels and embeds. When -- like in Epiphany
and Galeon -- there are more than one embed in the toplevel in a GtkNotebook,
we need to only activate the focus controller of the embed in the currently
active notebook page. We can do this by checking whether the embed is mapped:
widgets in non-active notebook pages are unmapped. Additionally, we need to
track toplevel focus and activate the focus controller when an embed is mapped:
this is the case that we switch to another notebook page without the toplevel
losing focus.

Comment 12

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

Comment on attachment 157717 [details] [diff] [review]
possible fix

This is still reproducible using epiphany with mozilla trunk from 20041026.
Also it's a potential security risk, since input destinated for the current tab
gets to the hidden background tab. Asking for r/sr.

Comment 13

[Marco Pesenti Gritti]

Comment on attachment 157717 [details] [diff] [review]
possible fix

See bug 226708 for an explanation of the problems with focus controller
activation.

I dont think we need to check for the mapped state. The dom window on the other
tab should not be active anyway (see ChildFocusIn/Out). It's actually activated
on page loading, but that's a different, more generic issue.

Comment 14

[Marco Pesenti Gritti]

Ultimately this looks like a bug of 210373 to me.

*** This bug has been marked as a duplicate of 210373 ***