Last Comment Bug 339293 - js mouseover not caught if mouse down on a different parent node that has css overflow: auto
: js mouseover not caught if mouse down on a different parent node that has css...
[CLOSEME 5-15-2010]
Product: Firefox
Classification: Client Software
Component: General (show other bugs)
: 1.5.0.x Branch
: x86 Windows XP
-- normal with 3 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
Depends on:
  Show dependency treegraph
Reported: 2006-05-25 21:41 PDT by lai kwan wong
Modified: 2010-05-22 17:07 PDT (History)
5 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Testcase (1.79 KB, text/html)
2008-01-21 06:55 PST, Andreas Blixt
no flags Details
Testcase 2 (1.30 KB, text/html)
2008-06-18 17:37 PDT, Evan Moses
no flags Details

Description User image lai kwan wong 2006-05-25 21:41:36 PDT
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20060426 Firefox/

In the sample, there's 2 parent div (green and white) with css overflow: auto. The childs 1,2 and 3,4 for the 2 parent divs. Mouseover events works fine for the child w/o mouse down. On mousedown, the mouseover event triggers w/in same parent div, but fails in the other one. (For example, mouse down (and hold) on child 1, drag into 2, notice the log. Now continuing w/ the mouse down, drag to 3 (from 2), notice NO mouseover events(no logs).)

Reproducible: Always

Steps to Reproduce:
1. create 2 parent div w/ css overflow: auto
2. put some child divs in w/ onmouseover handler
3. mouse down in a child node in 1 st parent div and drag into 2nd parent div, no mouseover events are logged. 
Actual Results:  
No mouseover events logged when dragging across diff parent div

Expected Results:  
mouseover events should be logged. (see url in IE)
Comment 1 User image Tony 2007-05-02 12:20:00 PDT
I am still able to replicate this bug as of May 2, 2007:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070502 SeaMonkey/1.5a

For another example, please see

In this case there is no parent/child relationship between the divs. The mouseover event does not fire on the yellow divs if you mousedown first on the blue div with overflow:auto.

The blank blue DIV has overflow: auto but no text. If it's any help, in Firefox 2.0, a mousedown in this div would not cause the mouseovers to fail. However, as of the latest build, it does.
Comment 2 User image Tony 2007-05-02 15:04:29 PDT
Additional test case:

Container div is overflow:hidden. The 'floating' div that appears when you mousedown indicates the ID of the div firing the mouseover event.

Mouse down on the list, then drag down: Hidden divs within the container div are firing the mouseover event when mousing over their position, were they visible. Mouseover events outside the container div do not fire.

This occurs for all overflow options except 'visible', and also occurs if either overflow-x or overflow-y are set to anything other than 'visible'
Comment 3 User image Kae Verens 2007-05-24 04:45:27 PDT
I think I may have narrowed it down further. I found in an application of my own which was exhibiting this behaviour, that if you run .preventDefault() on the mousedown event after it has fired, then this allows other events to start up. I'm not sure why this would be effective, but the mousedown appears to be trapping the browser context within the overflow scope.
Comment 4 User image Andreas Blixt 2008-01-21 06:42:07 PST
I can confirm this bug. I had an element with overflow: hidden; and when starting dragging inside that element, mouseover was not triggered on other elements.
Comment 5 User image Andreas Blixt 2008-01-21 06:55:16 PST
Created attachment 298265 [details]

I would like to add that I have user agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20071127 Firefox/

I've attached a testcase demonstrating the issue, should the aforementioned testcases disappear.
Comment 6 User image Evan Moses 2008-06-18 17:37:13 PDT
Created attachment 325671 [details]
Testcase 2

I've also run into this bug.  Here are the details, and a testcase to illustrate them.  When you click and drag on a div that 

a) is contained within a div with overflow:auto or overflow:hidden
b) has text in it and whitespace next to the text
c) has a mousedown handler that calls preventDefault (to prevent selection of the text)

When you drag the mouse outside of the overflow:auto div, if you clicked on the whitespace, mouseover events continue to fire with the target as the overflow:auto div, instead of the node that the mouse is currently over.  Note that the overflow:auto div /does/ in fact receive a mouseout event (visible occasionally in the attached case as a brief flash of white).  However, if you drag from the text, everything works as you would expect.

In the testcase, try clicking and dragging from "One" or "Two", dragging variously from the text or the whitespace to the right of the text.  If you drag from the whitespace, the outer div (with overflow: auto) will continue to be yellow no matter where you drag outside of it.  This doesn't happen if you drag from the text, or if you drag from "Three" or "Four".  

Note that this works the same if #outer has overflow:hidden instead of overflow:auto
Comment 7 User image Tim Buschtoens 2009-11-18 02:54:55 PST
I encounterd a very similar problem when trying to "drag" a div:

- "mouseout" and "mouseover" are not fired at all
- "mousemove" is fired, but always with the div on which the mousedown occurred as the "originalTarget".
- It seems only to happen with divs that have "overflow:hidden", not "overflow:auto".
- Setting "-moz-user-select:none" on the div that is dragged seems to solve the problem.
Comment 8 User image Tyler Downer [:Tyler] 2010-04-23 13:23:53 PDT
This bug was reported on Firefox 2.x or older, which is no longer supported and will not be receiving any more updates. I strongly suggest that you update to Firefox 3.6.3 or later, update your plugins (flash, adobe, etc.), and retest in a new profile. If you still see the issue with the updated Firefox, please post here. Otherwise, please close as RESOLVED > WORKSFORME
Comment 9 User image Tyler Downer [:Tyler] 2010-05-22 17:07:19 PDT
No reply, INCOMPLETE. Please retest with Firefox 3.6.x or later and a new profile ( If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.

Note You need to log in before you can comment on or make changes to this bug.