Closed Bug 237998 Opened 20 years ago Closed 19 years ago
DIV's with overflow:auto have odd on
Mouse Out and on Mouse Over behaviour
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 Moving the mouse over the just the scrollbars does not spark an onMouseOver event in Mozilla 1.6 and the latest 1.7 beta. Likewise, moving the mouse over the scrollbars from inside the DIV sparks an onMouseOut event when it shouldn't. This works fine in Netscape 7.1 and FireFox 0.8 - The problem can be seen by opening a scrollable menu at http://www.milonic.com/ Reproducible: Always Steps to Reproduce: 1. 2. 3. Expected Results: The mouseOver event should fire when the mouse moves inside the rectangle DIV ignoring the scrolbars. Likewise, mouseOut should only fire when the mouse has moved out of the div boundary. The scrollbars should have no effect.
This sounds like the usual confusion over mouseout and widgets, but could it really have worked in Firefox 0.8?
There are differences between Firefox 0.8 and Mozilla 1.6/1.7b, Honest. I've changed the demo to make my point a little clearer. http://www.milonic.com/bugreports/mozbug1.php When you mouse over the div, it shouldn't matter if you are over the content or the controls widgets, it's still a mouseover event that should be fired. Although this is happening its' being superseded by a mouseout event as you'll see by the demo. I hope this is a little clearer now.
Any news on when this bug will be fixed? I can confirm that it DOES work properly in Firefox 0.8 and that the problem is related to mouse events and scrollbars on Mozilla 1.6+ I have more and more users of our menu now complaining that it fails under Mozilla 1.6 and 1.7b. If you visit http://www.milonic.com/menusample12.php and open the 'Menu Samples' menu (you'll need to resize your browser small enough to force scroll bars) you'll see what I mean. The menu closes when the mouse moves over the scroll bar in Mozilla 1.6 but does not in Firefox 0.8. I'v also created a demo of why it does this at http://www.milonic.com/bugreports/mozbug1.php It appears that a mouseOUT event is firing when moving the mouse over the scroll bar whn in reality it should be a mouseOVER event. Cheers Andy
I think the mouseover is being prevented from bubbling by the scrollbar. I think we can stop that. Neil?
Hmm... I can allow mouseover/out events although they're currently getting targetted at the xul scrollbar rather than the scrolled element as XUL elements currently don't seem to support being native anonymous; even if that is fixed you'll still get paired out/over events when you mouse between the scrolled content and the scrollbars. Also note that all mouse events are being allowed for scrollcorners!
Scrollcorners should definitely act the same way as scrollbars. I think we should allow mouseover/out to bubble, even though we can't fix the out/over firing when moving to scrollbars problem (or the event target problem) yet.
* Removes all the event blockers from the scrollbar binding * Creates a new binding, scrollbar-base, used to disable contextmenu and some other events on both scrollbars and scrollcorners * Sets the cursor to default on scrollcorners
Assignee: general → neil.parkwaycc.co.uk
Status: UNCONFIRMED → ASSIGNED
Do we really need two <handler>s for contextmenu? The testcase says "In Firefox 0.8 you get 3 events fire Over, Out and then Over again - This is IMHO correct" ... why would that be correct? Don't you really just want ONE "over" event?
(In reply to comment #8) >Do we really need two <handler>s for contextmenu? Yes; the first stops the context menu itself and works when JS is disabled. >The testcase says "In Firefox 0.8 you get 3 events fire Over, Out and then >Over again - This is IMHO correct" ... why would that be correct? Don't you >really just want ONE "over" event? That's much trickier, as you are actually changing the element the mouse is over, albeit from a real element to an anonymous element.
I'm trying to understand why OTHER browsers are firing Over, Out and Over.
How about we decide once and for all how mouse events should work with XBL bindings and then implement that in XBL and event handling itself? Chances are, that would fix up the scrollbar issue altogether.
Sure. But I'm wondering if we should do something about this bug for 1.7.
By "fix" we mean "restore 1.6 behavior"?
Yes. Well, I wouldn't use the word 'fix' :-). But I would rather match the 1.6 behaviour than transition to something differently incorrect.
Especially if we agreed with other browsers in 1.6. But I don't understand how or why that would be the case.
>The testcase says "In Firefox 0.8 you get 3 events fire Over, Out and then >Over again - This is IMHO correct" ... why would that be correct? Internet Explorer and Opera 7.1 fires only "over" - Netscape 6.0+ & 7.1, Konquerer and Firefox 0.8 fire Over-Out-Over. Mozilla 1.6+ just fires Over- Out. How these browsers actually get to the final event is IMO, irrelevant, as long as they do actually get to an onMouseOver event when the mouse is over the scrollbar. This just isn't happening with 1.6 and I personally think it should. > Sure. But I'm wondering if we should do something about this bug for 1.7. I think you should ( but them who am I to say :o) ) Basically, I don't think it's working properly and should be looked at. Could this affect other objects? If it does could there be more problems later on? If you could sort this out it would be VERY much appreciated by a lot of people. Something did happen to 1.6 that I guess needs a little attention now before it potentially spreads to the other Mozilla based browsers. If you need anymore info on this (or other peoples opinion) just let me know and I'll be more than happy to oblige. Cheers Andy
Yeah, I'm all for restoring the behavior we had until we decide on the behavior we actually want. And I think we should do that for 1.7 if it's at all feasible.
There must be something wrong with the build I was testing with - I tried another build and it gave me the correct event target.
Comment on attachment 146040 [details] [diff] [review] Proposed patch alright, then, I think this will take us back to 1.6 behaviour. Hmm, should we let "mousemove" bubble as well?
Attachment #146040 - Flags: review?(roc) → review+
Attachment #146040 - Flags: superreview?(dbaron)
Attachment #146040 - Flags: superreview?(dbaron) → superreview?(bryner)
Attachment #146040 - Flags: superreview?(bryner) → superreview?(alecf)
Comment on attachment 146040 [details] [diff] [review] Proposed patch neat. sr=alecf
Attachment #146040 - Flags: superreview?(alecf) → superreview+
Fix checked in to the trunk. I'll leave it up to roc to decide whether he wants this for 1.7f or not.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Hi Guys, This bug is still causing us a tremendous amount of grief. Can you please let me know if it is going to be fixed. If not, I can look at a workaround but it would be nice not to have to. What confuses me most is that it works in FireFox and but now also fails in Netscape 7.2. Look forward to hearing from you. Cheers Andy
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
Andy, is it a problem on _trunk_, or just with Netscape 1.7.2 (which is using a rather old Gecko version and doesn't have the fix that was checked in for this bug)?
Boris, yes it seems OK in the Trunk, Mozilla 1.8a3 looks good. Although the test case is firing several events, we do end up with the correct one that we can work with. Sorry for not looking at the betas before, but I thought we got this one licked a while back. Cheers, Andy
Re-resolving fixed, since it is. The patch was checked in to trunk, not branch. The fix will not appear in Firefox 1.0, Netscape 7.2, Mozilla 1.7, etc. It'll be in Mozilla 1.8.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago → 19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.