535826 - IPP Flash doesn't receive mouseover events, in Ubuntu 9.10 with Compiz effects enabled

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect)

Description

[Daniel Holbert [:dholbert]]

STEPS TO REPRODUCE:
 0. Run gnome-appearance-properties, choose "Visual Effects" tab, and click the
radio button for "Normal" (if it's not already selected)
 1. Visit URL: http://homestarrunner.com/main1.html
 2. Mouse over the buttons on the left ('toons, games, characters, etc.)

EXPECTED RESULTS: Homestar should say the name of the button that you moused over, and something should animate in the background.

ACTUAL RESULTS: Nothing happens.

NOTE: If I *click* a button, then the EXPECTED RESULTS will play, just before the page changes.
NOTE: If I disable Compiz effects, I get EXPECTED RESULTS.
NOTE: If I enable dom.ipc.plugins.enabled in my m-c nightly, I get EXPECTED RESULTS here (though I then hit bug 535612 instead)

I see this in a Firefox 3.0 build, too -- so, looks like a non-regression -- Compiz is probably just doing something that we don't expect.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.16pre) Gecko/2009103004 GranParadiso/3.0.16pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20091218 Minefield/3.7a1pre

Comment 1

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

This is a rather scary bug, because homestarrunner is a windowed applet.  Gecko doesn't have anything to do with its event handling AFAIK.  Maybe there's some bad interaction with a mozgtk widget?

Comment 2

[Karl Tomlinson (:karlt)]

I don't see any problem with Shockwave Flash 10.0 r42 and kompmgr-3.5.10, so this doesn't seem directly related to compositing window managers in general.

Comment 3

[Karl Tomlinson (:karlt)]

xev -id <window-id> can be used to check the MotionNotify events on the plugin window.

To get the id of the window, open the page in a new toplevel window, run "xwininfo -tree" and click somewhere within that toplevel window.
The relevant window (for homestarrunner) is the deepest one with the correct geometry.  e.g.

xwininfo: Window id: 0x3403a5d "Everybody! Everybody! - Minefield"

  Root window id: 0x8b (the root window) (has no name)
  Parent window id: 0x1473a7b (has no name)
     2 children:
     0x3403a62 (has no name): ()  995x690+0+0  +339+175
        1 child:
        0x3403a65 (has no name): ()  995x690+0+0  +339+175
           1 child:
           0x3403fc9 (has no name): ()  995x542+0+124  +339+299
              1 child:
              0x3403fd0 (has no name): ()  995x542+0+0  +339+299
                 2 children:
                 0x340406a (has no name): ()  550x10+223+412  +562+711
                    1 child:
                    0x3404870 (has no name): ()  550x10+0+0  +562+711
                       1 child:
                       0x3404871 (has no name): ()  550x10+0+0  +562+711
                          1 child:
                          0x3404872 (has no name): ()  550x10+0+0  +562+711
                 0x340405b (has no name): ()  550x400+223+8  +562+307
                    1 child:
                    0x340486a (has no name): ()  550x400+0+0  +562+307
                       1 child:
                       0x340486b (has no name): ()  550x400+0+0  +562+307
                          1 child:
                          0x340486c (has no name): ()  550x400+0+0  +562+307
     0x3403a5e (has no name): ()  1x1+-1+-1  +338+174

The window id for motion events on the larger main plugin is 0x340486c.
(I don't yet know why xev doesn't report button events.)

Comment 4

[Karl Tomlinson (:karlt)]

(In reply to comment #3)
> (I don't yet know why xev doesn't report button events.)

http://www.sbin.org/doc/Xlib/chapt_08.html
"The pointer is automatically grabbed between the ButtonPress and ButtonRelease events on behalf of the client for whose window the ButtonPress was selected. This way, you always expect to receive button events in pairs since the release will be sent to your client regardless of the position of the pointer at that time. Only one client can select button events on any one window at one time, due to the grab that automatically takes place."

Comment 5

[Karl Tomlinson (:karlt)]

Does setting GDK_NATIVE_WINDOWS in the environment eliminate the symptoms here?

Comment 6

[Karl Tomlinson (:karlt)]

NO_EM_RESTART=1 needs to be in the environment to properly test GDK_NATIVE_WINDOWS as GDK_NATIVE_WINDOWS will not be propagated to child processes.

Comment 7

[Daniel Holbert [:dholbert]]

I actually can't reproduce this anymore.  I tested (a) current m-c nightly (with IPC disabled), (b) the m-c nightly referenced in comment 0, and (c) a Firefox 3.0.x build (note that comment 0 mentions this affecting 3.0)

I tested the above builds on both a desktop running Ubuntu 10.04 alpha and a laptop running Ubuntu 9.10 up-to-date.  I'll retest on the desktop that I originally reported this from (running Ubuntu 9.10) tomorrow.

Perhaps this bug was caused in part by a GTK bug that has since been fixed in Ubuntu?  Or it could be related to different machine-specific issue that I'll discover tomorrow, if the original machine still reproduces the bug...

Comment 8

[Daniel Holbert [:dholbert]]

(In reply to comment #7)
> I'll retest on the desktop that I
> originally reported this from (running Ubuntu 9.10) tomorrow.

I just retested on that machine, using today's mozilla-central nightly (20100203).

Initially, I was able to reproduce this (in both my main profile & in a fresh profile, with the ipc pref disabled in both).  But after a reboot, I could no longer reproduce.  So, sounds like perhaps this was fixed in an Ubuntu/gtk update of some sort.

Resolving as WORKSFORME. (but please reopen if anyone else can still reproduce)

Comment 9

[Karl Tomlinson (:karlt)]

Nothing significant in libgtk2,
http://packages.ubuntu.com/karmic-updates/libgtk2.0-0
http://changelogs.ubuntu.com/changelogs/pool/main/g/gtk+2.0/gtk+2.0_2.18.3-1ubuntu2.1/changelog
but maybe something else changed.