STEPS TO REPRODUCE: 1. Turn on dom.ipc.plugins.enabled (and restart Firefox) 2. Visit URL: http://homestarrunner.com/ 3. Click any of the links. (e.g. the big ones -- "come on in" / "watch intro", or any of the smaller ones at the bottom -- "main" / "toons" / etc) EXPECTED RESULTS: Clicking link should take me to the corresponding section of Homestar Runner. ACTUAL RESULTS: When I press mouse button down: - cursor changes from "finger" to normal arrow - The link's "hover highlight" disappears - Nothing else happens I get "expected results" (i.e. the link works) if I disable the IPC pref.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20091217 Minefield/3.7a1pre
BTW: I'm using Ubuntu 9.10 (up to date), with Flash 10.0 r42 (from Ubuntu repositories)
Can't reproduce on e10s-latest-DEBUG/Ubuntu 9.04 x86_64/Flash 10.0 r32. Will try some other configurations.
Weird... This is WFM on my home machine, using the same build ID as in comment 1. So, I just remotely connected to the originally-affected machine at the Mozilla office, using "nxclient", and it's now WFM on that machine. (at least in the nxclient session) I'll investigate a bit more tomorrow -- maybe it's due to some bizarre configuration-setting that only affects the local logged-in-session? Anyway, I'll update this bug tomorrow (possibly resolving as WFM if I can't reproduce again).
Just FTR, I couldn't repro on dholbert's configuration either.
Ok, so -- this bug only happens **when Compiz effects are enabled**. ADDITIONAL STEP TO REPRODUCE: 0. Run gnome-appearance-properties, choose "Visual Effects" tab, and click the radio button for "Normal" (if it's not already selected)
Summary: Homestar Runner front page's links don't work, with dom.ipc.plugins.enabled turned on → [OOPP][Linux] Homestar Runner front page's links don't work, with Compiz effects & 'dom.ipc.plugins.enabled' turned on
See also bug 535826. Basically, when Compiz effects are on, it looks like... - With IPC disabled, we send clicks through to flash, but not mouse hover - With IPC enabled, we send mouse hover through to flash, but not clicks :)
See Also: → bug 535826
(In reply to comment #4) > Weird... This is WFM on my home machine (I've confirmed that this becomes broken on my home machine when I enable Compiz)
So this is odd. Clicks are broken for OOP flash, but IP flash appears to be getting both hover and click events on my Ubuntu 9.10 machine with compiz enabled.
I've found another example of this bug, a barely clickable embedded youtube video: http://nintendoeverything.com/30918/ I use Ubuntu 9.10, when Compiz and OOPP are both enabled the play/pause button doesn't work (but sometime the progress bar works if I click several times). When I disable Compiz (or OOPP or both) everything works like expected.
Tentatively setting as a beta blocker, might need to revisit decision.
Since ipc plugins was just default-enabled in trunk ( http://hg.mozilla.org/mozilla-central/rev/f54bb3222492 ), I just retested this in the latest nightly, with ipc enabled. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20100127 Minefield/3.7a1pre * Homestar Runner still ignores clicks, per comment 0 * Some YouTube videos work, e.g. http://www.youtube.com/watch?v=zbqUvZ1Ja84 while others completely ignore clicks, e.g. comment 10, and this: http://www.youtube.com/watch?v=73A5lxEoDiM On the second youtube link above (which ignores clicks), I could occasionally get the video to pause or to full-screen by furiously clicking all over it. But the vast majority of my clicks have no effect.
Summary: [OOPP][Linux] Homestar Runner front page's links don't work, with Compiz effects & 'dom.ipc.plugins.enabled' turned on → [OOPP][Linux] Some Flash objects (e.g. Homestar Runner, Youtube) don't receive clicks, with Compiz effects & 'dom.ipc.plugins.enabled' turned on
After a lot of head-scratching by many people, we eventually decided this was a race in Flash. Here's how we fixed it for Chrome: http://code.google.com/p/chromium/issues/detail?id=20654
Thanks for the heads-up, Evan! Here's the actual chromium patch, I think: http://codereview.chromium.org/384059
Forgot to mention: I confirmed that this workaround fixes Homestar Runner. Thanks Evan!
Attachment #423937 - Flags: review?(roc) → review+
FWIW, here's some documentation on GDK_NATIVE_WINDOWS: http://library.gnome.org/devel/gtk/2.18/gtk-migrating-ClientSideWindows.html
Maybe this is related http://git.gnome.org/browse/gtk+/commit/?h=gtk-2-18&id=d86702621917fddc91c1403365de18b07e548f7f Looks like it will be included in GTK+-2.18.7 (when that is released).
Comment on attachment 423937 [details] [diff] [review] Set GDK_NATIVE_WINDOWS in plugin processes to work around plugins that don't properly handle new-style client-side GDK windows. >+ // Work around plugins that don't properly handle new-style GDK >+ // client-side windows. This may actually be a bug in GDK. Perhaps "don't interact well with GDK client-side windows" would be a less blame-attributing comment. >+ setenv("GDK_NATIVE_WINDOWS", "1", 1); Setting GDK_NATIVE_WINDOWS is not quite ideal because it prevents plugins from using GDK_WINDOW_OFFSCREEN windows. That's new to GTK+-2.18 anyway so I don't expect (common) plugins to be using that yet, but maybe some themes might want to try to make use of offscreen windows - I don't really know. However, we don't understand enough about what's happening here to suggest any other workarounds at this stage. I would have used PR_SetEnv to avoid the leak (GDK will unsetenv GDK_WINDOW_OFFSCREEN, but glibc keeps the strings created by setenv, for reasons that I do not know; PR_SetEnv is putenv with a const_cast), but I guess that's not a big issue.
Attachment #423937 - Flags: review?(karlt) → review+
Updated per comments, pushed http://hg.mozilla.org/mozilla-central/rev/354f5bdf07de.
9 years ago
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
https://litmus.mozilla.org/show_test.cgi?id=11627 added to Litmus.
Flags: in-litmus? → in-litmus+
You need to log in before you can comment on or make changes to this bug.