Closed Bug 716584 Opened 12 years ago Closed 2 years ago

Mouse events lost on plugin containers

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

9 Branch
x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: paul.geisler, Unassigned)

Details

User Agent: Mozilla/5.0 (Ubuntu; X11; Linux x86_64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
Build ID: 20111228084940

Steps to reproduce:

Move the mouse over an flash plugin whose parent container has attached some mouseover and mouseout listeners.

Thus a script cannot decide if a mouse 'hovers' the parent container as it may 'leave' the container by entereing the embedded plugin. Especially JS coded tooltips or bubble helps may disapper when an inner plugin is hovered. 


Actual results:

A mouseout event is fired for the parent container, but no mouseover event for the flash plugin. 


Expected results:

A mouseover event for the flashplugin must be fired too.
This is important as the script cannot decide wether the mouse hovers the parent container.
Hello Paul, i`m using Mozilla/5.0 (X11; Linux i686; rv:13.0a1) Gecko/20120216 Firefox/13.0a1, openSUSE 12.1, i don`t experience mouse issue in pages that have flash; i have tested several sites that need mouse interaction and they worked fine to me.

Be sure to install the latest flash player for 64 bits machines that is available starting with version 11 of the Adobe product; of course check that you have the video driver installed as well since some flash content is requiring hardware acceleration.
Have you tested that the 'mouseover' event is actually fired on the parent element if the mouse pointer enters the flash container? 
It is not so obvious to see this errors in everyday websites since hover popups or drag and drop are not that widely used.
Yes, i have tested this with a flash game called Deepolis; in that game the user must use the mouse to steer his ship, double-click to attack enemies and of course interact with objects like stations whene one can sell game elements for in-game cash. All of this actions are happening inside the game`s window that is running the flash player plugin.
Well I am talking about DOM events that have nothing to with the actions inside the flash container!

If the mouse enters the flash container, JS listeners attached to the parent containers mouseover and mouseout events see a mouseout event, but no mouseover event. That means the mouse pointer actually 'disappears' from the event view, if it hovers a flash container. That makes it impossible to decide if the mouse is still over the parent container of the plugin container, thus breaking drag'n drop, hover and other behaveiors when a flash plugin comes into play.
Hi Paul, have you noticed this still happening? If so can you give me a link to a specific example? Thanks!
Component: Untriaged → DOM: Events
Product: Firefox → Core
Event handling or perhaps even Widget. I'm not sure we can actually get access to native
mouse events always. If the plugin is windowed, it gets its own OS level widget...
Component: DOM: Events → Event Handling
Bug is still there. I've made a test page:

http://hirnsohle.de/film/test.php

Move the mouse from the black sourroundings to the green testarea and the black flash-plugin inside and back. The red headline will reflect the mouseover/out events on the testarea.

Just compare the behaviour on Linux Firefox and Linux Chrome.

On Firefox, a mouseout gets fired if the mouse enters the flash plugin. No mouseover event is fired. 

On Chrome, a mouseout gets fired if the mouse enters the flash plugin. Immediately a mouseover event (for entering the flash plugin) is fired. 

If I would show something like a tool tip on the green container in Firefox, it would disappear as soon I enter the flash plugin area. For all other HTML-elements the ballon help would keep open. This is clearly an inconsistent behavior.
Component: Event Handling → User events and focus handling

Flash Player is no longer supported

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.