Closed Bug 237998 Opened 20 years ago Closed 20 years ago

DIV's with overflow:auto have odd onMouseOut and onMouseOver behaviour

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: mozilla, Assigned: neil)

References

(
URL
)

Details

Attachments

(1 file)

Proposed patch
5.34 KB, patch
roc
: review+
alecf
: superreview+
Details | Diff | Splinter Review 
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.
Attached patch Proposed patch — — Splinter Review 
* 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
Attachment #146040 - Flags: review?(roc)
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 → 20 years ago
Resolution: --- → FIXED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: