GNOME Bugzilla – Bug 72125
Non-focused tab's gtkmozembed steals focus when done loading
Last modified: 2005-03-31 18:07:37 UTC
There's some sort of race condition or something; what happens is(basically), there's a tab loading in the background. Up/down keys are working just normally. The not-focused tab finishes loading, and then any up/down, PgUp/PgDown and such keystrokes arn't sent to the focused tab, but rather to the gtkmozembed of the tab that just finished loading. Here's how I reproduce consistently. Takes a bit of fast mousework, I think, or a slow-ish connection maybe. Open up two tabs. Tab 1 is www.slashdot.org, tab 2 is www.arstechnica.com Bring tab 2 to focus; hit reload. Very quickly, move to tab 1. Hit the up/down keys or whatever so that it's obvious that gtkmozembed has focus. Keep hitting those keys until tab 2 is done loading and rendering. If tab1 is still scrolling, obviously it didn't work. But if it did stop scrolling, hit End or somesuch; switch to tab 2 and the Arstechnica page will be scrolled to the bottom. Thanks for all the great work :)
Coooool ;) Finally a reproducable testcase ;) the bad site seem to be arstechnica, now I can try to see what is going wrong ;)
Just adding a note, as we discussed on IRC; it isn't Arstechnica specifically (since we can both reproduce with two Slashdot.org pages), and I've noticed the irritating behaviour everywhere. :) (Again, this is just for completeness in the bug report - send to /dev/null, Marco :)
My plan is to kill all the focus bugs asap, that require: 1 Understand mozilla focus 2 Understand gtk focus 3 Understand gtkmozembed implementation of mozilla focus 4 Fix it ;) Will not be easy, but it's really time to solve this.
*** Bug 67391 has been marked as a duplicate of this bug. ***
*** Bug 72477 has been marked as a duplicate of this bug. ***
http://bugzilla.mozilla.org/show_bug.cgi?id=127694
*** Bug 68905 has been marked as a duplicate of this bug. ***
*** Bug 64638 has been marked as a duplicate of this bug. ***
*** Bug 67801 has been marked as a duplicate of this bug. ***
*** Bug 69257 has been marked as a duplicate of this bug. ***
*** Bug 72422 has been marked as a duplicate of this bug. ***
Moving the mouse really quickly and switching tab's may get tiresome. The easiest way of causing this problem to occour is have 1 tab which reloads itself after 1 second. Then try to use a web-form in a second tab. You won't be able to type in the webform, because the other tab will steal your keyboard focus. Just write a webpage with a META refresh tag in it. meta http-equiv="REFRESH" content="1; http://localhost/reload.html" And make the meta-refresh reload the same page. It will loop, reloading itself every second. And every time it reloads, it will steal your focus. We use a percentage progress bar in our web application, and it updates the progress bar every couple seconds. If I have one of these status bars in a tab in galeon, I can't use galeon anymore because it continually steals the focus. :(
According to blizzard whole mozilla focus suck badly ... hopefully this will be solved soon.
*** Bug 79484 has been marked as a duplicate of this bug. ***
*** Bug 78228 has been marked as a duplicate of this bug. ***
*** Bug 83086 has been marked as a duplicate of this bug. ***
*** Bug 81774 has been marked as a duplicate of this bug. ***
*** Bug 83437 has been marked as a duplicate of this bug. ***
*** Bug 65662 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of 73121 ***
*** Bug 73121 has been marked as a duplicate of this bug. ***
*** Bug 88110 has been marked as a duplicate of this bug. ***
*** Bug 90016 has been marked as a duplicate of this bug. ***
*** Bug 91242 has been marked as a duplicate of this bug. ***
*** Bug 87909 has been marked as a duplicate of this bug. ***
*** Bug 91462 has been marked as a duplicate of this bug. ***
*** Bug 91773 has been marked as a duplicate of this bug. ***
Just a little bit of info. This isn't limited to tabs as far as I can tell. This also happens with me with a window that has been popup up by another window... Here's my story: I have a constantly refreshing page (http-equiv="refresh" content="30") This page opens another window when I click on a link... The window that opens has a <textarea> that I type into. I type and type and when the original page refreshes I type no more. I've tried this in mozilla aswell and the bug wasn't there. I could reproduce this all day..
Any progress with this one? Looks to me as if galeon developers are waiting for input from mozilla and vice versa. But is anyone doing anything about it? :)
This need to be fixed in mozilla. We cant do much about it.
I realize that. I was just wondering if you know if someone's been doing something that isn't recorded in these two bugs, because the bugs seem being mostly ignored. Last entry in the mozilla bug is still waiting for an answer.
Nope, blizzard says mozilla focus sucks and he should go through it at some point. But I dont think he did any work on it.
While we wait for something to happen in the mozilla front, maybe someone wants to try a workaround instead. I just can't believe it could be this simple; just set the embed in inactive tabs insensitive. For all I can tell it works perfectly. But it just can't be that easy, what am I missing here? Of course, it's still a workaround... :-/
Created attachment 11204 [details] [review] Proposed workaround
I tried porting this to galeon 1.2.6, but it didn't fix it here. (It didn't change anything that is - didn't break anything either ;) Here's the diff i tried, maybe i didn't do it the right way... --- src/window_callbacks.c 2002-09-22 00:15:12.000000000 +0200 +++ src/window_callbacks.c 2002-09-22 00:18:02.000000000 +0200 @@ -2062,12 +2062,14 @@ embed_save_modified_location (old_embed); /* no longer the active embed */ + gtk_widget_set_sensitive(GTK_WIDGET (old_embed->mozembed), FALSE); old_embed->is_active = FALSE; embed_update_tab_status (old_embed); } /* this is now the active embed */ embed->is_active = TRUE; + gtk_widget_set_sensitive(GTK_WIDGET (embed->mozembed), TRUE); window->active_embed = embed; /* move this embed to front of tab list to maintain stacking order */
*** Bug 94538 has been marked as a duplicate of this bug. ***
*** Bug 101487 has been marked as a duplicate of this bug. ***
This appears to be fixed, but should probably have a second opinion before closing it and the mozilla bug report http://bugzilla.mozilla.org/show_bug.cgi?id=127694 (they want to know if it's fixed)
*** Bug 116139 has been marked as a duplicate of this bug. ***
*** Bug 119255 has been marked as a duplicate of this bug. ***
*** Bug 122557 has been marked as a duplicate of this bug. ***
What is going on with this bug? Its definitly not fixed.
I think this is the latest reincarnation. http://bugzilla.mozilla.org/show_bug.cgi?id=210373
*** Bug 123879 has been marked as a duplicate of this bug. ***
*** Bug 100891 has been marked as a duplicate of this bug. ***
Update: http://bugzilla.mozilla.org/show_bug.cgi?id=127694 Has a testpage which reproduces the bug consistently for me galeon 1.3.10, mozilla 1.5 This report was marked resolved worksforme. I've just reopened it. http://bugzilla.mozilla.org/show_bug.cgi?id=210373 Seems to have technical discussions, but no responses from mozilla developers for the past month.
*** Bug 130132 has been marked as a duplicate of this bug. ***
*** Bug 132804 has been marked as a duplicate of this bug. ***
Just another case: if I'm writing something in a form while a tab is loading, when it finishes loading, it steals the focus. The following page has a meta refresh and reproduces the bug (while using a form). http://acm.uva.es/cgi-bin/OnlineJudge?Status:Valladolid:IDSCMALN:16:-1:1.00:15:: I'm using galeon1.3.12 from Debian unstable.
*** Bug 134787 has been marked as a duplicate of this bug. ***
*** Bug 136621 has been marked as a duplicate of this bug. ***
Created attachment 25940 [details] [review] Proposed workaround (updated) Patch from comment #34 updated to apply and work with Galeon 1.3.14
It's been said that the set_sensitive workaround doesn't always work. Under what circumstances it fails hasn't been figured out (a little like the original mozilla bug.)
Created attachment 26806 [details] [review] unrealize inactive embeds This is a little more drastic workaround. It unrealizes the embed widget when it becomes active and shows it again when it becomes active. Unrealized widgets can't possibly grab focus so it might be slightly more effective. However this is ugly, we really really shouldn't need to do thing like that. gtkmozembed does initialization on realize. I've no idea if or how much this hack is making it leak.
Created attachment 26819 [details] [review] unrealize inactive embeds This one actually compiles with recent CVS.
*** Bug 140513 has been marked as a duplicate of this bug. ***
*** Bug 139117 has been marked as a duplicate of this bug. ***
*** Bug 143225 has been marked as a duplicate of this bug. ***
*** Bug 143421 has been marked as a duplicate of this bug. ***
*** Bug 143928 has been marked as a duplicate of this bug. ***
*** Bug 144233 has been marked as a duplicate of this bug. ***
*** Bug 144257 has been marked as a duplicate of this bug. ***
Still present: Fedora Core 2 (updated), Mozilla 1.6, Galeon 1.3.15 (binary from galeon.sf.net). ALWAY reproduceable: any tab or window that ends the loading steals the focus, except when you set the Windows Manager to Focus-Follows-Mouse (or focus on enter-window, whatever); in this case, only tabs to the focused window steal the focus.
*** Bug 144640 has been marked as a duplicate of this bug. ***
*** Bug 147857 has been marked as a duplicate of this bug. ***
I applied patch from comment #54 and tested, I have mozilla bug 127694's test case running in another tab, and whenever the test case reloads, this input box (where I'm typing the bug report) loses focus, and reverts to typeahead find, but on the same tab that I've been using. (As opposed to the old behavior where the *hidden* tab would steal typeahead find from an active tab's forms and from an active tab's typeahead find.) So it looks like even with comment #54's patch applied, the JavaScript behavior still needs work. Could you guys please come up with a fix soon, even if it's a very hackish fix. This is very annoying behavior, and the bug is several years old.
*** Bug 152054 has been marked as a duplicate of this bug. ***
*** Bug 157503 has been marked as a duplicate of this bug. ***
I just found this problem is present in Netscape 7.02 for Windows also. So it is a mozilla core problem.
Created attachment 34035 [details] [review] stop mozilla from grabbing focus Yet another idea to work around this thing. This time trying to stop mozilla from grabbing the focus unless it's triggered by user interaction.
The previous patch is now committed to CVS: http://mail.gnome.org/archives/cvs-commits-list/2004-November/msg04799.html
*** Bug 159348 has been marked as a duplicate of this bug. ***
*** Bug 161021 has been marked as a duplicate of this bug. ***
could this issue be reopened? With galeon 1.3.19 the focus is not lost when the new tab has finished loading, but immediately when the tab is opened. E.g. I write a comment in this box, then use my middle mouse button to open one of the duplicates in a new tab -> I cannot continue typing in the box. To be able to continue typing in the page, I have to switch to another tab and back and click in the box. It should be enough to click in the box (no forced switching between tabs please)
The issue with middle clicking on a link stealing focus has been fixed in CVS. I would also much rather have new bugs rather than re-opening this one.
*** Bug 171613 has been marked as a duplicate of this bug. ***
just want to confirm that the middle-clicking-focus-stealing is solved with 1.3.20