Closed Bug 20022 Opened 25 years ago Closed 20 years ago

:hover state not set until mouse move

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla1.8alpha2

People

(Reporter: CodeMachine, Assigned: dbaron)

References

(Blocks 1 open bug)

Details

(Keywords: css2, fixed1.8, Whiteboard: [patch])

Attachments

(8 files, 17 obsolete files)

1.10 KB, text/html; charset=UTF-8
Details
547 bytes, text/html; charset=UTF-8
Details
16.17 KB, text/html
Details
1.10 KB, text/html; charset=UTF-8
Details
2.86 KB, patch
roc
: review+
dbaron
: superreview+
Details | Diff | Splinter Review
39.37 KB, patch
roc
: review+
Details | Diff | Splinter Review
1.37 KB, patch
Details | Diff | Splinter Review
2.85 KB, patch
roc
: review+
mtschrep
: approval1.8b5+
Details | Diff | Splinter Review
Overview Description:

When you choose a menu item, and the mouse by chance hovers over a personal
toolbar button, mouseover effects do not occur.

Actual Results:

Mouseover will only occur when you move the mouse, even though you're within the
button the whole time.

Expected Results:

Menu dismissal should result in mouseover status being checked and turned on if
necessary.

Build Date & Platform Bug Found:

Linux 1999112208
Assignee: trudelle → saari
Priority: P3 → P5
Target Milestone: M20
Must be a slow bugfinding day!  assigning to saari as p5 for m20
Assignee: saari → pinkerton
taking popup/menu bugs. I hate my life.
bulk accepting xpmenu/popup bugs. sigh.
Status: NEW → ASSIGNED
QA Contact: claudius → sairuh
Mass move of all M20 bugs to M30.
Mass moving M20 bugs to M30
Target Milestone: M20 → M30
Mass-moving all M20-M30 XPToolkit bugs to Future
Target Milestone: M30 → Future
QA Contact: sairuh → jrgm
this bug has remained w/out comment from the author for about a year...does it
still happen? i'm marking WFM since no one else has said anything...
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
This is still there as of M18.  Be aware that personal toolbar buttons don't
hover anymore.

Choose Search/Find Again. such that you're hovering over the reload toolbar
button.  A dialog will about but the mouseover doesn't until you move the mouse
slightly.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
True of both Modern and Classic.
oh, but they eventually appear, right? Yeah, we don't do any hover resolution
until mouse-move, so if a window comes to the front under the mouse, you won't
see any :hover styles until the mouse moves. This is a gecko bug, not a toolkit bug.
Assignee: pinkerton → waterson
Status: REOPENED → NEW
Component: XP Toolkit/Widgets → Layout
OS: Linux → All
Hardware: PC → All
Summary: Mouseover does not occur after menu goes away. → :hover state not set until mouse move
oops --> clayton for triage
Assignee: waterson → clayton
QA Contact: jrgm → petersen
XML/DOM team's turn to triage Clayton's bugs.
Assignee: clayton → joki
*** Bug 62217 has been marked as a duplicate of this bug. ***
Has this bug been fixed, or partially fixed?  I cannot duplicate the bug using
the search menu.  When I choose find again from the menu, my mouse ends up over
the reload button and the reload button is properly highlighted without any
mouse movement. (Windows build 2000122805 classic skin)  I can check again on
linux once I get to work.
Also the "previous date" test from Bug 62217 wfm.  Again I will test on linux.
This bug appears for me in Linux (Build 2000122710).  Maybe it should not be OS=ALL?
Bug 28934 is related.
hyatt: FYI
Severity: trivial → minor
Keywords: css2, mozilla1.0
QA Contact: petersen → ian
I can't reproduce this bug on 2001021812 Linux. The reload button's mouseover
effect appears correctly without moving the mouse.
Coming here from bug 77051 ...

Another issue:

When I select one of the menus, for example "Tasks" and then hover over the
toolbar buttons the following happens:
1. toolbar buttons are highlighted 
2. the associated action doesn't trigger when I click 

One of the above behaviors is not correct (probably #2)
With regard to #2: I've read somewhere there is a difference between windows and
Linux. On windows the actions are triggered on 'MouseDown' while on Linux it is
'MouseUp'. I'll try to confirm this. Otherwise this seems WFM
See also:
bug 50511 scrolling/app switching under mouse should cause mousemove
bug 78765 link left in :hover state after being hovered and scrolled off using 
mouse wheel [specific to mouse-wheel scrolling, doesn't happen with arrow keys]
I believe this is what I'm seeing intermittently when rolling over the main
menus at the top of the window. It's as it the fact that I'm over the meny isn't
'caught' as a hover event. Soon as you move my one pixel the state is corrected.
This belongs in the Event Handling component.  I believe Event Handling is quite
recent, so it was not available when this bug was filed.
Component: Layout → Event Handling
QA Contact: ian → madhur
QA Contact: madhur → rakeshmishra
I can confirm this on 1.0 (2002053012) in WinXP.  Dismissing a menu with the
mouse over any toolbar button or the bookmarks will not cause the "hover" style
to be in effect until you move the mouse slightly.

This is similar to bug 150069, which deals with the :hover CSS pseudo-style in
rendered HTML.  The root cause may be the same.
*** Bug 168647 has been marked as a duplicate of this bug. ***
QA Contact: rakeshmishra → trix
*** Bug 46388 has been marked as a duplicate of this bug. ***
Blocks: 50511
I think what needs to happen here is that anytime we do a reflow or a scroll we
should notify the event state manager that things have moved and it should (1)
change the :hover-ed content, (2) set the cursor and (3; probably) fire
mouseout/mouseover.

There's currently a hack to do (some of?) this for the wheel scrolling case only.

There might be some complications for the key scrolling case because of our use
of GetFrameForPoint for key events, although hopefully we've fixed that. :-)

This is actually one of the more basic bugs that really annoys me, so changing
from P5 to P2.
Priority: P5 → P2
http://bugzilla.mozilla.org/show_bug.cgi?id=179125#c3

joki is no longer here
Assignee: joki → saari
QA Contact: trix → ian
I guess 'mozilla1.0' keyword should be removed/replaced now: v1.4 is released.
*** Bug 137412 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.0
Assignee: saari → dbaron
Whiteboard: [patch]
Target Milestone: Future → mozilla1.7alpha
Attached patch patch (obsolete) — Splinter Review
After discussion with jst, I decided that these synthesized mouse movements
should not lead to DOM mousemove events, but should lead to mouseover /
mouseout events.

This still needs a lot more testing.
Attachment #140120 - Attachment is obsolete: true
Attached patch patch (obsolete) — Splinter Review
Attachment #140122 - Attachment is obsolete: true
Attached patch patch (obsolete) — Splinter Review
Attachment #140123 - Attachment is obsolete: true
(In reply to comment #33)
> After discussion with jst, I decided that these synthesized mouse movements
> should not lead to DOM mousemove events, but should lead to mouseover /
> mouseout events.

In several case, I praised the symmetry in the |dragenter|/|dragexit| events and
cursed the absence of |mouseenter| in the DOM spec. Wouldn't it make sense to
have such an event internally? mouseover can be resource consuming.
What's asymmetric about mouseover and mouseout?  Are you sure you're not
thinking of mousemove?  (over == enter and out == exit may be abuse of the
English language, but they're standardized, and symmetrical themselves)
I chose "over" and "out" as the prepositions long ago, in a fit of whimsy.

Are we firing mouseovers continuously or something?

/be
(In reply to comment #37)
> What's asymmetric about mouseover and mouseout?
arg, my bad! I got involved with mozilla with bug 139471 and bug 145350 that
adds a the dragenter handler to our DND helper because dragover is firing
continously.
I naively assumed that mouseover had the same behaviour as dragover, but no, it
fires only once, just like dragenter.
Sorry for the my last comment, but it was highly beneficial for me, I have to
fix one incorrect use that I made.
Comment on attachment 140124 [details] [diff] [review]
patch

>-          if (baseView != view) {

I thought this check was an optimization, but it's apparently required for
:hover effects in popups to work.  (Either that, or something else in my tree
broke :hover inside popups.)
I can no longer reproduce the problem mentioned in my previous comment.
Ignore comment 42, actually.

The problem is that we reflow everytime the user moves the mouse while over a menu.

Probably the easy fix is not to synthesize a mouse move if there's a mouse grabber.
Well, there are two problems:

 * we reflow when the user moves the mouse over the bookmarks menu (probably
because of the arrows) or a menu on the personal toolbar

 * when synthesizing the mouse event after than reflow, BuildEventTargetList
seems to get a display list that thinks the view for the page content is above
the view for the menu -- thus the top 2 items on the bookmarks menu work, but
the rest don't.
That's pretty weird. The views for menus are floating, so they should always be
on top. In fact they are in normal operation, what could be different about this
case?
Attached patch patch (obsolete) — Splinter Review
ok, never mind.  I was missing a coordinate system translation which messed
things up for any views that weren't at the origin.  The combination of that
and the excessive menu reflow caused a little feedback loop (one cycle per
mouse movement) where the menu switched from hovered to non-hovered on every
mouse move.
Attachment #140195 - Flags: superreview?(roc)
Attachment #140195 - Flags: review?(bryner)
So what happens when someone writes a test page where :hover causes an element
to shrink, and someone moves the mouse just inside the element? Do we reflow,
fire synthetic event, reflow, fire synthetic event forever? I presume so since
that's kind of correct ... but can the user recover or does it lock up hard?
> fire synthetic event, reflow, fire synthetic event forever? I presume so since
> that's kind of correct ... but can the user recover or does it lock up hard?

is the synthetic event fired synchronously or async?  Users are able to recover
from async events merely by moving the mouse, which should still be possible
given that we are still processing the event loop. If it's an async event/reflow
loop we're pretty much gonna be toast, right?
Attached file infinite loop testcase
Hmm.  Perhaps the event should be fired asynchronously, then.  The only case
where the delay could matter is for :hover changing after a Reflow, and that's
a relatively unimportant case.
Attached patch patch (obsolete) — Splinter Review
this posts events to the queue
Attachment #140195 - Flags: superreview?(roc)
Attachment #140195 - Flags: review?(bryner)
Attachment #140231 - Flags: superreview?(roc)
Attachment #140231 - Flags: review?(bryner)
Comment on attachment 140231 [details] [diff] [review]
patch

Actually, never mind that.  I realized some of the event queue changes I made
here are bad for nested event loops.
Attachment #140231 - Attachment is obsolete: true
Attachment #140231 - Flags: superreview?(roc)
Attachment #140231 - Flags: review?(bryner)
Attachment #140255 - Flags: superreview?(roc)
Attachment #140255 - Flags: review?(bryner)
Comment on attachment 140255 [details] [diff] [review]
patch

> reasonType

Shouldn't this be ReasonType?

> +   * (aFromScroll is false) or scrolled (aFromScroll is true).

Lose the reference to aFromScroll

> handler_fn

Make this HandlerFn? I thought we always made type names InterCaps.

+  // XXX set event.isShift, event.isControl, event.isAlt, event.isMeta ?

I think you need to, right?

Can you explain why you're not firing mousemove? Seems like mouse-tracking
DHTML will get confused otherwise.
The DOM spec says that mousemove should be fired when the pointing device is
moved, which it isn't in this case.  Mouse-tracking DHTML mostly uses
mouseover/mouseout, I'd hope.

>+  // XXX set event.isShift, event.isControl, event.isAlt, event.isMeta ?
>I think you need to, right?

This would make the code a good bit more complicated, since the view manager
will need to remember those states as well (assuming we get keyup / keydown
events for them that can be reliably associated with the correct modifiers,
which I'm not sure we do).
Also, I'm thinking maybe I should prevent the infinite loop from happening at
all (since it suppresses paints, which can be confusing) by allowing an
additional event to be posted only if the source is a scroll rather than a reflow.
> Shouldn't this be ReasonType?

I was being consistent with the other member enum of an event (orientType).
Attached patch patch (obsolete) — Splinter Review
avoid infinite loops, readd |aFromScroll|
Attachment #140255 - Flags: superreview?(roc)
Attachment #140255 - Flags: review?(bryner)
Attachment #140425 - Flags: superreview?(bryner)
Attachment #140425 - Flags: review?(roc)
> The DOM spec says that mousemove should be fired when the pointing device is
> moved, which it isn't in this case.

Well, the pointer is moving relative to the element...

> Mouse-tracking DHTML mostly uses mouseover/mouseout, I'd hope.

I meant xeyes-like hacks, or the pointer-following tooltips that some sites
have. Can you think of any examples of pages that watch mousemove and wouldn't
want it to fire because of scrolling or reflow?

> This would make the code a good bit more complicated,

Yeah, I don't know how to implement it either, I just think we should :-(. Maybe
just change the comment to
// XXX We should set event.isShift, event.isControl, event.isAlt, event.isMeta!
Comment on attachment 140425 [details] [diff] [review]
patch

>Index: view/src/nsViewManager.cpp
>-nsInvalidateEvent::nsInvalidateEvent(nsViewManager* aViewManager)
>+nsViewManagerEvent::nsViewManagerEvent(nsViewManager* aViewManager)
> {
>   NS_ASSERTION(aViewManager, "null parameter");  
>-  mViewManager = aViewManager; // Assign weak reference
>   PL_InitEvent(this, aViewManager,
>                (PLHandleEventProc) ::HandlePLEvent,
>                (PLDestroyEventProc) ::DestroyPLEvent);  

As we discussed, you should be able to get rid of these casts now.


>@@ -1959,72 +1955,71 @@ NS_IMETHODIMP nsViewManager::DispatchEve
>           view = mMouseGrabber;
>           capturedEvent = PR_TRUE;
>         }
>         else if (nsnull != mKeyGrabber && (NS_IS_KEY_EVENT(aEvent) || NS_IS_IME_EVENT(aEvent))) {
>           view = mKeyGrabber;
>           capturedEvent = PR_TRUE;
>         }
>         else {
>           view = baseView;
>         }
> 
>         if (nsnull != view) {
>+          float t2p;
>+          mContext->GetAppUnitsToDevUnits(t2p);
>+          float p2t;
>+          mContext->GetDevUnitsToAppUnits(p2t);
>+

I realize you just moved this code around, but you could just say:  float p2t =
1 / t2p;  , couldn't you?  

sr=bryner with those changes.
Attachment #140425 - Flags: superreview?(bryner) → superreview+
This might help show what we're currently doing here. This prints out what DOM
mouse{move,over,out} events are fired in a document. Turns out that IE, and
Mozilla too, fires all those events when (de)activating a window (sometimes
with different coordinates though), which I for sure didn't think we did.
Attached patch patch (obsolete) — Splinter Review
This fixes the casts for the event handlers to PL_InitEvent and fires mousemove
events as well.  I didn't fix the dev2app/app2dev stuff because I've had enough
rounding errors for today already.
Comment on attachment 140543 [details] [diff] [review]
patch

Oh, and after I land this I need to look into differences in what happens on
activate events between Windows and GTK2...
Attachment #140543 - Flags: review?(roc)
Fix checked in to trunk, 2004-02-03 16:11 -0800.
Status: NEW → RESOLVED
Closed: 24 years ago20 years ago
Resolution: --- → FIXED
This patch generates spurious mousemove events. It breaks a lot of extensions.

For instance, in Firebird, load http://news.bbc.co.uk/ in one tab. Each time,
the "ticker" for LATEST "writes", a squirt of mousemove events are generated
even if the mouse doesn't move.

Worst. If you listen mouse move events in another tab (at the level of content
area) you get the mouse move events of the BBC tab when the ticker writes. You can  
imagine the result when you use mouse move events to draw gesture trails.

Backing out for the moment seems reasonable.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to comment #62)
> Created an attachment (id=140529)
> Testcase that shows what DOM mouse{move,over,out} events are fired.
> 
> This might help show what we're currently doing here. This prints out what DOM
> mouse{move,over,out} events are fired in a document. Turns out that IE, and
> Mozilla too, fires all those events when (de)activating a window (sometimes
> with different coordinates though), which I for sure didn't think we did.

Not sending mousemove events is a very simple patch, and there's no need to back
out.  But why do the mousemove events break extensions?
This may have caused bug 233164 
Blocks: 233164
(In reply to comment #68)
>  But why do the mousemove events break extensions?

Well, not all. Those that use mouse move as Optimoz mouse gestures, All-in-One
gestures, Autoscroll, etc. Mousemove events should only be dispatched when the
mouse pointer changes its coords on the screen (W3C DOM events says: "The
mousemove event occurs when the pointing device is moved while it is over an
element").

I still don't understand why these extensions can't handle a mousemove with
unchanged coordinates.
Attachment #140691 - Attachment description: mousemove tracker → broken
Attachment #140691 - Attachment is obsolete: true
(In reply to comment #66)
> Worst. If you listen mouse move events in another tab (at the level of content
> area) you get the mouse move events of the BBC tab when the ticker writes. You
can  
> imagine the result when you use mouse move events to draw gesture trails.

I can't reproduce this problem on Linux.  Could you please file a separate bug
with accurate steps to reproduce?
This patch breaks native Firebird Autoscroll as well (verified on Win XP with
unofficial build from Mozillazine).

(In reply to comment #71)
> I still don't understand why these extensions can't handle a mousemove with
> unchanged coordinates.
Let's take the autoscroll feature as an example. You first middle-click to set
the marker position. Then moving the mouse relative to the marker determines the
scrolling direction and speed. If spurious mousemove events are generated, it
breaks everything.
Comment on attachment 140756 [details] [diff] [review]
restore code to prevent mousemoves from firing (checked in to trunk, 2004-02-06 15:10 -0800)

bryner already reviewed this (as part of attachment 140425 [details] [diff] [review])
Attachment #140756 - Flags: superreview+
Attachment #140756 - Flags: review?(roc)
Blocks: 233285
Comment on attachment 140756 [details] [diff] [review]
restore code to prevent mousemoves from firing (checked in to trunk, 2004-02-06 15:10 -0800)

I still think this is silly, but okay.
Attachment #140756 - Flags: review?(roc) → review+
Attachment #140756 - Attachment description: restore code to prevent mousemoves from firing → restore code to prevent mousemoves from firing (checked in to trunk, 2004-02-06 15:10 -0800)
I investigated a little bit the problem. Firing mousemove events is not the real
issue. It seems that the issue is that the mousemove events are fired with the
coords of the element that is reflowed not the mouse coords.

I'll make a testcase tomorrow to illustrate what I think the problem is.
Blocks: 233327
This latest checkin seems wrong to me. IMNSHO the original fix was correct, we
*should* fire mousemove events when a view is being scrolled.

I would think that the DOM uses coordinates relaive to the document, not the
viewport. Which means that when the document scrolls but the mouse stays
stationary with respect to the viewport, the mouse *does* actually move with
respect to the document. In other words: since the mouse is now positioned at a
different position in the documents coordinate-space it must have moved and an
event should be fired.

However:
Extensions such as optimoz and autoscroll should be using the chromes coordinate
space. In that space the mouse hasn't moved so it could be argued that the event
shouldn't be propagated through the chrome-DOM. And it should defenetly have the
same coordinates through that DOM.
In any event I don't see why the extnesions shouldn't be able to deal with these
new events that are generated.
I liked it better when scrolling with the keyboard didn't fire mouseover.  Now
DHTML tooltips on e.g. http://www.bradchoate.com/ appear under the mouse cursor
when I scroll using the keyboard.
Unofficial Firebird 20040207 WIn XP.
Last checkin solved the mouse move problem. Still something wrong with
http://news.bbc.co.uk/ . The mouse pointer cursor is changing from pointer to
hand when the ticker plays. With native autoscroll (which uses a special
cursor), mouse cursor toggles very quickly when ticker writes.

Steps to reproduce:
1. Goto http://news.bbc.co.uk/
2. bring the mouse pointer over the Latest ticker.
3. Move the mouse to the right of the page. watch the pointer that transforms to
hand when the ticker plays. If the mouse is moved while the ticker writes, the
mouse pointer flickers (changed at each new letter).
(In reply to comment #81)
> I liked it better when scrolling with the keyboard didn't fire mouseover.  Now
> DHTML tooltips on e.g. http://www.bradchoate.com/ appear under the mouse cursor
> when I scroll using the keyboard.

This seems like a good thing to me. And it's much more consistent then to have
the tooltip update just because i brush against the mouse or hit the desk with
my elbow (i.e. when the mouse moves a pixel)
Me too. And if I don't want the tooltips, I can always move the cursor away.
This has most probably caused crash bug 233211. Look there for details.
Attached patch what I propose to backout (obsolete) — Splinter Review
I don't want to back out some of the cleanup that's essentially unrelated to
this bug.

I have a verbal a=chofmann on backing out.
Backed out.
Status: REOPENED → ASSIGNED
Target Milestone: mozilla1.7alpha → mozilla1.7beta
This also seems to have caused the bug 234435 crash....
Depends on: 234435
*** Bug 235108 has been marked as a duplicate of this bug. ***
Blocks: 119061
There might be some similarity between fixing this and some of the issues
related to keeping mouseover/mouseout/:hover state correct when the pointer is
moving in and out of iframes.  Worth considering before, or perhaps after,
relanding.
*** Bug 243784 has been marked as a duplicate of this bug. ***
Attached patch patch (obsolete) — Splinter Review
patch updated to trunk
Attachment #140543 - Attachment is obsolete: true
Attachment #141416 - Attachment is obsolete: true
Attachment #141417 - Attachment is obsolete: true
Attached patch patch (obsolete) — Splinter Review
This is the previous patch modified to fix bug 233164, bug 234435, and bug
238546.  That basically leaves bug 233211 / bug 234188 and bug 233374, which
all seem to be Windows-only.
Attachment #150457 - Attachment is obsolete: true
Attached patch patch (obsolete) — Splinter Review
This also fixed bug 233374.  I'm unable to reproduce the drag & drop crashes on
Win2K using the steps in bug 234188 comment 0, bug 233211 comment 0, or bug
233211 comment 7.  Hopefully they've gone away, but perhaps they're Win9x-only,
in which case I'll need help debugging.

I think this is ready to land.	If the crashes are still there, somebody can
help debug.
Attachment #150459 - Attachment is obsolete: true
Target Milestone: mozilla1.7beta → mozilla1.8alpha2
Comment on attachment 150470 [details] [diff] [review]
patch

The main changes since the backout are the drag&drop stuff in
nsEventStateManager.cpp, a null-check in nsPresShell.cpp, and the removal of
the mRootView check on the NS_MOUSE_EXIT handling (with 6-line comment) in
nsViewManager.cpp.  I also fixed a change I only half-did the first time --
using ViewManager() instead of mViewManager in nsViewManagerEvent.
Attachment #150470 - Flags: superreview?(roc)
Attachment #150470 - Flags: review?(roc)
Comment on attachment 150470 [details] [diff] [review]
patch

   PRBool	   acceptActivation;	       
+  reasonType	   reason;

Wanna try to pack those two members into 32-bits?
Attached patch patch (obsolete) — Splinter Review
This packs the struct (not that important, since it's used on the stack, but
not a problem) and also restores the bizarre workaround for a bug in
RevokeEvents that I recall from talkback data the first time around as being
still needed.  (I put it in nsViewManager.cpp's ::HandlePLEvent this time.)
Attachment #150470 - Flags: superreview?(roc)
Attachment #150470 - Flags: review?(roc)
Attachment #150512 - Flags: superreview?(roc)
Attachment #150512 - Flags: review?(roc)
Attachment #150512 - Flags: superreview?(roc)
Attachment #150512 - Flags: review?(roc)
Do you want review on this patch, or are you still working on it? I'd love to
get this relanded soon!
I still haven't figured out the right way to handle mouse exit / enter.
So here's a rough description of the problem I'm running into:

 * if I listen only to mouse exit events whose widget is the root view's widget,
then things don't work on Windows (bug 233374)

 * if I treat mouse exit and mouse enter events as toggling a boolean and don't
change mMouseLocation at all, we won't handle things if the mouse is moved while
over a plugin, since the view manager won't get that event.  (This mainly
matters for reflow, not scrolling, since most plugins seem to eat the keyboard
events that we probably shouldn't be sending them in the first place (since
sending key events based on mouse position is silly).)

 * If I use the coordinates of mouse enter events, things get off-by-one related
to the amount scrolled, or sometimes just stop working completely.  I've seen
multiple types of behavior here, and it's not helped by the fact that sometimes
we clearly do process things just fine but the cursor doesn't update (probably
some sort of GTK bug).  See the testcase:
data:text/html;charset=us-ascii,%3Cdiv%20style%3D%22height%3A%20500px%22%3E%3C%2Fdiv%3E%0D%0A%3Ciframe%20src%3D%22http%3A%2F%2Fwww.mozilla.org%22%3E%3C%2Fiframe%3E%0D%0A%3Cdiv%20style%3D%22height%3A%20500px%22%3E%3Ca%20href%3D%22http%3A%2F%2Fwww.mozilla.org%22%3EMozilla%3C%2Fa%3E%3C%2Fdiv%3E
If you scroll the page down a bit, place the mouse over the link, and then
scroll the page down (so you're over the iframe) and then up, things often end
up in a broken state where either the link isn't recognized at all or where
things are one line off.
(My current strategy is to try to make the third approach work.)
I think many of the problem are related to two weird things that are going on:

 * when the mouse moves from chrome to content, the chrome VM doesn't get any
indication of mouse exit, so two VMs think they're tracking the current mouse
location and one of them has the wrong one

 * when the cursor changes, the chrome VM decides (not sure why yet) that it's
necessary to synthesize a mouse move event based on the bogus location
The mouse enter and exit events seem perfectly symmetrical, as they should be. 
However, the events I see are:

move from outside to chrome:
[vm=0x88a54f8] received mouse enter for widget 0x88a56a8

move from chrome to content:
[vm=0x88a54f8] received mouse exit for widget 0x88a56a8
[vm=0x88a54f8] received mouse enter for widget 0x89f3c48
[vm=0x88a54f8] received mouse enter for widget 0x8a010f8
[vm=0x880a948] received mouse enter for widget 0x8bc0a98
[vm=0x880a948] received mouse enter for widget 0x8d15648

move from outside to content:
[vm=0x88a54f8] received mouse enter for widget 0x88a56a8
[vm=0x88a54f8] received mouse enter for widget 0x89f3c48
[vm=0x88a54f8] received mouse enter for widget 0x8a010f8
[vm=0x880a948] received mouse enter for widget 0x8bc0a98
[vm=0x880a948] received mouse enter for widget 0x8d15648

roc, any ideas how to tell which mouse enter events are the ones I don't want?
[vm=0x88a54f8] received mouse exit for widget 0x88a56a8
This is the top-level window.

[vm=0x88a54f8] received mouse enter for widget 0x89f3c48
I think this is a widget that wraps the <browser>. Maybe it's from a
tabs-related <deck>?

[vm=0x88a54f8] received mouse enter for widget 0x8a010f8
I think this is the widget in <browser> that contains the primary-content
subdocument.

[vm=0x880a948] received mouse enter for widget 0x8bc0a98
This is the toplevel widget for the browser's subdocument.

[vm=0x880a948] received mouse enter for widget 0x8d15648
This is the scroll port widget for the browser's subdocument.

GTK2 isn't being very consistent here. Firing MOUSE_ENTER at all four of these
widgets without any intervening EXIT seems wrong. It should probably be only
firing MOUSE_ENTER on the innermost widget. This is probably a GTK2 bug. It
would be interesting to see what the behaviour looks like on Mac and Windows.
Attached patch patch (obsolete) — Splinter Review
This has some debugging printfs ifdef'd out.  I'll test this on various
platforms...
Attachment #150512 - Attachment is obsolete: true
Mouse enter/exit events work the way I want on Windows (i.e., any widget that's
received a mouse enter more recently than a mouse exit is the widget receiving
mouse move events).
Our Mac code generates them the same way as Windows.
I think a more precise statement of what you want, and get on Windows, is that
there is always at most one widget which has received a MOUSE_ENTER but not a
MOUSE_EXIT, and only that widget can receive MOUSE_MOVE events.

We should fix GTK2 so that's true.
Attached patch patchSplinter Review
This makes the gtk, gtk2, and xlib port's NS_MOUSE_EXIT and NS_MOUSE_ENTER
events work the same as the windows and mac gfx ports.	I didn't test the xlib
changes but I tested the other two.

I also stuck in my NS_PAINT_SEPARATELY diffs for GTK2.	Why not? :-)
Attachment #151147 - Attachment is obsolete: true
Attachment #151394 - Flags: superreview?(roc)
Attachment #151394 - Flags: review?(roc)
Comment on attachment 151394 [details] [diff] [review]
patch

okay!
Attachment #151394 - Flags: superreview?(roc)
Attachment #151394 - Flags: superreview+
Attachment #151394 - Flags: review?(roc)
Attachment #151394 - Flags: review+
Fix checked in to trunk, 2004-06-21 21:28/29/32 -0700.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
This landing caused a slight Tp (pageload time) regression / increased
variability.  This is the patch I landed to fix that, and it seems to have
worked (mostly, at least).  See btek and luna tinderboxes.

This also gave me the idea for bug 248226.
*** Bug 248735 has been marked as a duplicate of this bug. ***
*** Bug 252967 has been marked as a duplicate of this bug. ***
*** Bug 253043 has been marked as a duplicate of this bug. ***
Requesting blocking-aviary1.0 (this has not been ported to the Aviary branch yet).
See bug 250117 for details.
Flags: blocking-aviary1.0?
Please do NOT port this to Aviary. It's just another nice-to-have but
noncritical fix.
*** Bug 250117 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.0? → blocking-aviary1.0-
*** Bug 258738 has been marked as a duplicate of this bug. ***
*** Bug 260945 has been marked as a duplicate of this bug. ***
*** Bug 261432 has been marked as a duplicate of this bug. ***
*** Bug 266377 has been marked as a duplicate of this bug. ***
*** Bug 268568 has been marked as a duplicate of this bug. ***
Interesting followup bugs (probably both related to widget code problems with
NS_MOUSE_ENTER and NS_MOUSE_EXIT): bug 209565, bug 269415.
*** Bug 286113 has been marked as a duplicate of this bug. ***
*** Bug 290815 has been marked as a duplicate of this bug. ***
*** Bug 298307 has been marked as a duplicate of this bug. ***
No longer blocks: 98114
*** Bug 98114 has been marked as a duplicate of this bug. ***
Comment on attachment 140756 [details] [diff] [review]
restore code to prevent mousemoves from firing (checked in to trunk, 2004-02-06 15:10 -0800)

>     // 2. Give event to the DOM for third party and JS use.
>-    if ((GetCurrentEventFrame()) && NS_SUCCEEDED(rv)) {
>+    if ((GetCurrentEventFrame()) && NS_SUCCEEDED(rv) &&
>+         // We want synthesized mouse moves to cause mouseover and mouseout
>+         // DOM events (PreHandleEvent above), but not mousemove DOM events.
>+         !IsSynthesizedMouseMove(aEvent)) {
This may have caused bug 305706 and/or bug 262406. Unfortunately
manager->PostHandleEvent is in this block, so that the ESM's idea of the
current event frame is never cleared. If the synthesized mouse move is caused
by a resize then the subsequent resize event gets erroneously targetted at the
same frame instead of the document.
Depends on: 305706
Attachment #195196 - Attachment description: sounds reaonable → sounds reasonable
Attachment #195196 - Flags: superreview?(roc)
Attachment #195196 - Flags: review?(neil.parkwaycc.co.uk)
Attachment #195196 - Flags: superreview?(roc)
Attachment #195196 - Flags: superreview+
Attachment #195196 - Flags: review?(neil.parkwaycc.co.uk)
Attachment #195196 - Flags: review+
Comment on attachment 195196 [details] [diff] [review]
sounds reasonable

This fixes some regressions from a change that's happened since 1.7, and it's
been on the trunk a few days.
Attachment #195196 - Flags: approval1.8b5?
Flags: blocking1.8b5+
Comment on attachment 195196 [details] [diff] [review]
sounds reasonable

Approved for 1.8b5 per bug meeting
Attachment #195196 - Flags: approval1.8b5? → approval1.8b5+
Comment on attachment 195196 [details] [diff] [review]
sounds reasonable

Checked in to trunk, 2005-09-15 23:04 -0700.
Checked in to MOZILLA_1_8_BRANCH, 2005-09-19 16:24 -0700.
*** Bug 316856 has been marked as a duplicate of this bug. ***
Depends on: 322338
See also Bug 322338 for a follow-on ramification.
And see also bug 320533 for another related issue.
No longer blocks: 119061
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: