Last Comment Bug 125386 - flyout menu disappears when mouse passes over scrollable div or iframe
: flyout menu disappears when mouse passes over scrollable div or iframe
Status: RESOLVED FIXED
: testcase
Product: Core
Classification: Components
Component: DOM: Events (show other bugs)
: Trunk
: x86 Windows 98
: -- major with 2 votes (vote)
: ---
Assigned To: Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
: Hixie (not reading bugmail)
Mentors:
http://rpgnall.home.att.net/Test/Flyo...
: 147087 208107 236925 243843 259598 281549 283693 296189 301684 (view as bug list)
Depends on: 283478 283693 297080 311558
Blocks: 286826 113492 136527 244385 283623 283757 283942
  Show dependency treegraph
 
Reported: 2002-02-13 16:56 PST by Richard P. Gnall
Modified: 2007-11-27 14:40 PST (History)
35 users (show)
asa: blocking1.7.5-
asa: blocking1.8a4-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Flyout menu passing over scrollabe div (1.06 KB, text/html)
2002-02-13 16:58 PST, Richard P. Gnall
no flags Details
new testcase (821 bytes, text/html)
2002-02-15 11:39 PST, Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
no flags Details
Even better testcase (877 bytes, text/html)
2002-02-15 12:45 PST, Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
no flags Details
Simplified testcase showing extent of problem (799 bytes, text/html)
2004-05-18 10:01 PDT, Rick Hanson
no flags Details
fix? (4.72 KB, patch)
2005-02-10 20:34 PST, Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
no flags Details | Diff | Review
Additional fix on OS X (1.78 KB, patch)
2005-02-11 09:10 PST, Peter Van der Beken [:peterv]
jhpedemonte: review+
sfraser_bugs: superreview+
Details | Diff | Review
fix #2 (5.52 KB, patch)
2005-02-14 14:21 PST, Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
bzbarsky: review+
bzbarsky: superreview+
Details | Diff | Review
Attempt at the short-term fix (5.43 KB, patch)
2005-02-25 14:21 PST, Boris Zbarsky [:bz] (Out June 25-July 6)
no flags Details | Diff | Review
updated short term fix (3.68 KB, patch)
2005-02-25 15:24 PST, Scott MacGregor
bzbarsky: review-
bzbarsky: superreview-
Details | Diff | Review
Updated short term fix v1.1 (3.68 KB, patch)
2005-02-26 01:10 PST, Ere Maijala (slow)
emaijala+moz: review-
Details | Diff | Review
Patch to patch v1.2 (5.03 KB, patch)
2005-02-26 11:56 PST, Ere Maijala (slow)
bzbarsky: review+
bzbarsky: superreview+
Details | Diff | Review
stack (1.20 KB, text/plain)
2005-03-02 08:38 PST, Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com]
no flags Details
Possible fix for that crash? (1.58 KB, patch)
2005-03-04 13:15 PST, Boris Zbarsky [:bz] (Out June 25-July 6)
no flags Details | Diff | Review

Description Richard P. Gnall 2002-02-13 16:56:58 PST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; AT&T WNS5.0)
BuildID:    20020204

Hi -

Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.8) Gecko/20020204

http://rpgnall.home.att.net/Test/FlyoutOverScrollableDiv.htm

In the above example (the code for which I have posted below), I encounter an 
error when a flyout menu passes over a scrollabe <div>. (It works just fine in 
IE 5.5.)

In Mozilla:
1) When I pass my mouse over red Menu1, green Menu2 pops up as expected.
2) When I move the mouse into Menu2, it remains visible as expected.
3) When I move the mouse into the section of Menu2 which overlaps the yellow 
scrollable viewport, Menu2 disappears, which is NOT EXPECTED.

I have tried numerous variations on this theme, including changing the order of 
the div blocks in the HTML, assigning z-index, and using relative instead of 
absolute positioning. Using display instead of visibility just changes the 
nature of the error.

None of these seem to work. Does anyone know why this isn't working or know of 
a workaround?

Thanks,
Richard
rpgnall@att.net
---------------------------------------------------------------------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 
Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<style>
#menu1{
	position:absolute; top:10px; left:10px;
	width:100px; height:100px;
	background-color:red;
	}
#menu2{
	position:absolute; top:20px; left:90px;
	width:300px; height:100px;
	background-color:green;
	visibility:hidden;
	}
#viewport{
	position:absolute; top:50px; left:200px;
	width:100px; height:200px;
	background-color:yellow;
	overflow:auto;
	}
</style>
</head>
<body>

<div id="viewport">
	VIEWPORT:<p>
	A<p> long<p> list<p> of<p> text<p> which<p> I<p> would<p> like<p> to<p> 
be<p> scrollable<p> inside<p> this<p> viewport.
</div>

<div id="menu1"
 onMouseOver="document.getElementById('menu2').style.visibility='visible'"
 onMouseOut ="document.getElementById('menu2').style.visibility='hidden'">
	Menu 1
</div>

<div id="menu2"
 onMouseOver="document.getElementById('menu2').style.visibility='visible'"
 onMouseOut ="document.getElementById('menu2').style.visibility='hidden'">
	Menu 2
</div>

</body>
</html>
---------------------------------------------------------------------

Reproducible: Always
Steps to Reproduce:
1.When I pass my mouse over red Menu1, green Menu2 pops up as expected.
2.When I move the mouse into Menu2, it remains visible as expected.
3.When I move the mouse into the section of Menu2 which overlaps the yellow 
scrollable viewport, Menu2 disappears, which is NOT EXPECTED.

Actual Results:  green popup menu disappears

Expected Results:  green popup menu should remain in place, and only disappear 
when mouse leaves green or red menu
Comment 1 Richard P. Gnall 2002-02-13 16:58:54 PST
Created attachment 69366 [details]
Flyout menu passing over scrollabe div
Comment 2 Johnny Stenback (:jst, jst@mozilla.com) 2002-02-14 19:32:15 PST
Robert, at first glance this looks like a view/viewmanager problem, could you
investigate?
Comment 3 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2002-02-14 19:41:19 PST
Yeah, looks like me. This should have been fixed by my recent changes. Hmm...
Comment 4 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2002-02-15 11:39:04 PST
Created attachment 69699 [details]
new testcase

This testcase seems to show that the view manager is not at fault.
Comment 5 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2002-02-15 12:45:06 PST
Created attachment 69716 [details]
Even better testcase

In this testcase, drag the mouse from left to right over menu2. The
window.status shows that mouseover events are firing on menu2 all the way
along, as expected. However, when the mouse passes over the left OR right edge
of "viewport", an onmouseout of menu2 is fired! This is obviously wrong, and
suggests a problem with nsEventStateManager.
Comment 6 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2002-02-15 13:03:50 PST
I bet nsEventStateManager is seeing an NS_MOUSE_EXIT event from the widget
toolkit as the cursor moves into the widget associated with "viewport":
http://lxr.mozilla.org/seamonkey/source/content/events/src/nsEventStateManager.cpp#2142

nsEventStateManager is assuming this means the mouse has left the current view,
but this is not true. We're still in the menu2 view and frame even though the
mouse is now over a different widget. I'm not familiar with nsEventStateManager
so I'll hand this back to jst.

jst, I think you want to ignore NS_MOUSE_EXIT unless the mouse actually left the
area under control of the nsEventStateManager (i.e., we stopped getting
NS_MOUSE_MOVEs). There's only one nsEventStateManager per application window,
right? 
Comment 7 Johnny Stenback (:jst, jst@mozilla.com) 2002-02-15 19:58:46 PST
nsEventStateManager belongs to joki, so reassigning to him, and nominating for
mozilla1.0
Comment 8 Peter Trudelle 2002-03-04 16:43:43 PST
nsbeta1- per ADT triage team.  Will reconsider if this can be demonstrated on a
top site.
Comment 9 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2002-07-21 10:11:18 PDT
*** Bug 147087 has been marked as a duplicate of this bug. ***
Comment 10 Dash 2002-10-11 15:17:56 PDT
This also effects over elements such as inline frames.  I haven't created an
attachment as an iframe needs two files, so here:

http://www.aligrant.com/tmp/moz/iframe.htm

If you mouseover the popup you get a "sub-menu" say.  Moving off the div should
hide it, but it hides as soon as the mouse enters iframe area too.  You can also
move the mouse around the side of the div over the iframe and onto the div.  It
will then not hide again until you move off the iframe, and mouseout on the div
is ignored.

It's been causing me a nightmare for weeks trying to get a site working to
discover it wasn't my lack of JS ability but a bug :/  Got a whole site on hold
until it's fixed.
Comment 11 Vladimir Ermakov 2002-10-14 09:39:16 PDT
Either related or a dupe of bug 136527. Are divs and scrollable iframes simular
in some way, in terms of implementation?
Comment 12 Marius Kotsbak 2002-12-31 05:53:47 PST
I probably see this bug at http://www.cpen.no

The "button" produkter (products) on top doesn't work as it disappears when i
move  down to hexaglot over the scrollpane below. 

"Support"-button works OK as there is no scrollpane below.

The same page works ok in opera.

I think I have seen this problem on other pages as well, and is important to fix.
Comment 13 Martin Reurings 2004-05-14 06:49:43 PDT
Just came across this while working on a site. It seems a bit of a shame that
there's two duplicates of this bug under bug 136527 and bug 159914 and all of
them are assigned to a programmer who's already gone.
This bug seriously threatens clean CSS2 drop-down menu's and it would be a shame
if we leave it lying around. The testcases accurately show the problem.
Comment 14 José Jeria 2004-05-17 13:40:24 PDT
*** Bug 243843 has been marked as a duplicate of this bug. ***
Comment 15 José Jeria 2004-05-17 13:41:40 PDT
*** Bug 208107 has been marked as a duplicate of this bug. ***
Comment 16 Rick Hanson 2004-05-18 10:01:15 PDT
Created attachment 148755 [details]
Simplified testcase showing extent of problem
Comment 17 Andrew Schultz 2004-05-19 09:31:29 PDT
only drivers can set (+) blocking flags.  you can request (?) them.
Comment 18 Brandon Amedee 2004-05-25 22:30:56 PDT
Bug 164302 seems to be a dupe of this one.
Comment 19 iced 2004-08-27 13:53:16 PDT
Request OS to ALL

Bugs breaks CSS menus over DIV, IFRAME and just about everyother dom event
there atleast 15 dupes or related bugs and nsbeta1 as keyword, FIXME
Comment 20 José Jeria 2004-09-15 11:29:55 PDT
*** Bug 259598 has been marked as a duplicate of this bug. ***
Comment 21 Skye 2005-01-26 10:42:17 PST
<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=276059">Bug 276059</a> is
related.  I find it somewhat astounding that this issue is nearly 3 years old
now, and there seems to be no real activity on resolving it.  My own report of
this issue is a month old, and only today (01-26-05) has someone bothered to
look at and link it to <a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=136527"> 136527</a>, but
didn't even take the time to list it as a confirmed issue.  This problem does
NOT occur within Internet Explorer.  I am a Firefox user personally, but with a
growing market share, I'd think that resolution of an issue like this would be a
priority.  I had to completely reformat my layout for a website in order to make
it workable (I only did this because I felt stupid for recommending my customer
start using Firefox, who immediately noticed that something that works
flawlessly in IE broke badly in FF).  Will someone please take ownership of this
issue?
Comment 22 José Jeria 2005-02-08 13:50:38 PST
*** Bug 281549 has been marked as a duplicate of this bug. ***
Comment 23 Peter Van der Beken [:peterv] 2005-02-10 13:09:35 PST
Some debugging info: I put the following printf before the call to
nsViewManager::HandleEvent at
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/view/src/nsViewManager.cpp&rev=3.385&root=/cvsroot#2206

printf("[vm=%p]event coords (%i, %i), view: %p\n", this, aEvent->point.x,
       aEvent->point.y, view);

I also defined DEBUG_MOUSE_LOCATION. Here's an example of output for attachment
69716 [details]:

[vm=0xf191160]setting mouse location to (199,85)
[vm=0xf191160]event coords (2985, 1275), view: 0xf19cf30
[vm=0xf191160]got mouse exit for 0xf19cfb0
[vm=0xf191160]clearing mouse location
[vm=0xf191160]event coords (0, 525), view: 0xf19cf30
[vm=0xf191160]got mouse enter for 0xf1094f0
[vm=0xf191160]setting mouse location to (200,85)
[vm=0xf191160]event coords (0, 525), view: 0xf109470
[vm=0xf191160]setting mouse location to (202,85)
[vm=0xf191160]event coords (30, 525), view: 0xf109470

This is going left to right over "menu2", the mouse exit happens when passing
over the left edge of "viewport". It's odd that the coordinates seem to change
first, but not the view. In the next call to DispatchEvent the view changes too.
While it does make sense for the old view to be there (we're exiting it), the
coordinates for that MOUSE_EXIT event seem wrong.
Comment 24 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-02-10 20:34:40 PST
Created attachment 174015 [details] [diff] [review]
fix?

This patch fixes the bug for me. The approach is quite simple: dispatch
MOUSE_EXIT events through the normal mouse movement path in the view manager,
and in the ESM, if we determine that the 'exit' actually leaves the mouse still
in our view, then convert the EXIT to a MOVE, so that any necessary DOM exit
events will be generated synthetically and no spurious DOM exit events will be
generated. When the mouse leaves the top-level window the mouse coordinate will
no longer be in the view and the old exit code will execute.

The big question hanging over this patch is whether other toolkits set the
mouse coordinate in their native MOUSE_EXIT events correctly. GTK2 does. Any
takers for Windows and Mac?
Comment 25 Peter Van der Beken [:peterv] 2005-02-11 09:10:06 PST
Created attachment 174052 [details] [diff] [review]
Additional fix on OS X

Attachment 174015 [details] [diff] fixes it for me on Windows, but not on OS X.
This additional patch seems to fix it on OS X too. Since we set a different
widget for NS_MOUSE_EXIT in nsMacEventHandler::HandleMouseMoveEvent, we need to
set the coordinates relative to that widget.
Comment 26 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-02-13 14:00:01 PST
Excellent. Thanks for testing it. I'll get reviews for my patch, you get reviews
for yours :-)
Comment 27 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-02-13 14:00:50 PST
Comment on attachment 174015 [details] [diff] [review]
fix?

Apparently this patch alone fixes GTK2 and Windows, and Peter has an additional
fix for OSX...
Comment 28 Peter Van der Beken [:peterv] 2005-02-13 19:34:39 PST
Hmm, but I don't seem to be getting any MOUSE_EXITs anymore when leaving a
window. The problem seems to be that the call to BuildEventTargetList in
nsViewManager::HandleEvent returns an empty list, which sort of makes sense
(mouse outside of any views). The following patch does the trick, but I have no
idea if it's the right thing to do:

Index: view/src/nsViewManager.cpp
===================================================================
RCS file: /cvsroot/mozilla/view/src/nsViewManager.cpp,v
retrieving revision 3.386
diff -u -p -r3.386 nsViewManager.cpp
--- view/src/nsViewManager.cpp	11 Feb 2005 16:23:57 -0000	3.386
+++ view/src/nsViewManager.cpp	14 Feb 2005 03:21:19 -0000
@@ -2455,6 +2455,14 @@ nsEventStatus nsViewManager::HandleEvent
 
   nsEventStatus status = nsEventStatus_eIgnore;
 
+  if (aEvent->message == NS_MOUSE_EXIT && targetViews.Count() == 0) {
+    if (obs) {
+       PRBool handled;
+       obs->HandleEvent(aView, aEvent, &status, PR_TRUE, handled);
+    }
+    return status;
+  }
+
   // get a death grip on any view managers' view observers (other than this one)
   PRInt32 i;
   for (i = 0; i < targetViews.Count(); i++) {
Comment 29 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-02-14 10:58:23 PST
The view manager should be ensuring that an event is delivered to at least one
view. In particular, you should go through this statement:
http://lxr.mozilla.org/mozilla/source/view/src/nsViewManager.cpp#3605

I thought there might be a problem with this, and checked, and I'm pretty sure I
observed it working. Is there some Mac-specific issue here?
Comment 30 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-02-14 14:21:35 PST
Created attachment 174320 [details] [diff] [review]
fix #2

peterv noticed that some mouseexits were being lost. Turns out
CreateDisplayList's attempt to always deliver an event somewhere was wrong; we
might not hit aRealView during display list construction. So throw the event at
aTopView instead, since that's always the first view passed into
CreateDisplayList, so we're guaranteed to put it in the display list.
Comment 31 Simon Fraser 2005-02-14 15:18:18 PST
Comment on attachment 174052 [details] [diff] [review]
Additional fix on OS X

Gotta love those files with tabs.
Comment 32 Boris Zbarsky [:bz] (Out June 25-July 6) 2005-02-14 22:37:39 PST
Comment on attachment 174320 [details] [diff] [review]
fix #2

>Index: view/src/nsViewManager.cpp
>+    if (aEventProcessing && aTopView == aView) {

OK.  So this is the change that keeps us from regressing bug 144880, right?

>Index: content/events/src/nsEventStateManager.cpp
>+      // treat it as a move so we don't generate spurious "exit"
>+      // events Any necessary exit events will be generated by

Missing period between "events" and "Any".

Do we need to do anything for MOUSE_ENTER events when we move over an iframe? 
I guess the ESM doesn't do much with MOUSE_ENTER so we should be ok?

r+sr=bzbarsky assuming I'm right about bug 144880.
Comment 33 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-02-15 11:10:26 PST
(In reply to comment #32)
> (From update of attachment 174320 [details] [diff] [review] [edit])
> >Index: view/src/nsViewManager.cpp
> >+    if (aEventProcessing && aTopView == aView) {
> 
> OK.  So this is the change that keeps us from regressing bug 144880, right?

Yep.

> Do we need to do anything for MOUSE_ENTER events when we move over an iframe? 
> I guess the ESM doesn't do much with MOUSE_ENTER so we should be ok?

Yeah.
Comment 34 Peter Van der Beken [:peterv] 2005-02-20 02:37:48 PST
Attachment 174052 [details] [diff] checked in.
Comment 35 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-02-23 13:47:15 PST
checked in
Comment 36 Timo Tolonen 2005-02-24 15:16:41 PST
This caused bug 283478

Also caused some weirdness with firefox's button mouseover effects at least on
winxp. To reproduce hide toolbars that are under toolbar buttons (bookmarks
toolbar, tabbar) and move mouse over a toolbar button (Home), when you move
mouse downwards the button's mouseover effect doesn't disappear.

Comment 37 Martijn Wargers [:mwargers] (not working for Mozilla) 2005-02-25 05:47:00 PST
Another regression this has caused probably:
Hover over a bookmark in your bookmarks toolbar. A tooltip appears. This tooltip
doesn't disappear anymore after a while. It also gives a weird tooltip
interaction (seeing multiple tooltips, etc) with tooltips that are shown in the
content area.
Comment 38 Ere Maijala (slow) 2005-02-25 12:44:27 PST
Looks to me this patch causes us to re-enter
nsDragService::StartInvokingDragSession multiple times when dragging. I suspect
this could cause the crashes (which I see in quite a few different locations).
Comment 39 Scott MacGregor 2005-02-25 13:52:06 PST
This bug fix causes drag and drop operations to crash in Thunderbird. Please see
Bug #283693 for more details. 
Comment 40 Boris Zbarsky [:bz] (Out June 25-July 6) 2005-02-25 13:57:08 PST
Ere did some debugging, and it looks like the problem is the following:

1)  With the change for this bug, MOUSE_EXIT events while a mouse is down can be
    converted to move/drag/etc events.
2)  On Windows, when a mouse move event happens, we start a 200ms timer (see
    MouseTrailer::CreateTimer).  When this timer fires, MouseTrailer::TimerProc
    is called.  This checks whether we have left the window (nsWindow, to be
    exact) we were in when the timer was started, and if we did fires a
    MOUSE_EXIT event.
3)  So when a timer fires, we can start a drag session, etc.
4)  This code uses the Windows ::SetTimer function, not XPCOM timers.  So as far
    as I (and ere) can tell, the timer can fire any damn time it pleases (unlike
    XPCOM timers, which are proxied via the event loop).
5)  In particular, the timer can fire while we're in the middle of processing a
    drag event already, causing reentry of the drag service, etc.

Short term solution:  Use nsITimer for the timer.

Longer-term solution:  Figure out whether we can just remove this MouseTrailer code.

Note:  The code was checked in by kipp in rev 1.1 of nsToolkit.cpp, with the
comment "moved to pub".  So nothing useful there as to what this code is fixing
or trying to fix.
Comment 41 Boris Zbarsky [:bz] (Out June 25-July 6) 2005-02-25 14:01:01 PST
If someone with a Windows build or general windows knowledge could help out here
(on either the short-term or long-term solution mentioned in comment 40, that
would help a lot)...
Comment 42 Boris Zbarsky [:bz] (Out June 25-July 6) 2005-02-25 14:21:08 PST
Created attachment 175589 [details] [diff] [review]
Attempt at the short-term fix

Could someone with a Windows build test this?
Comment 43 Scott MacGregor 2005-02-25 15:24:22 PST
Created attachment 175599 [details] [diff] [review]
updated short term fix

Thanks Boris. I had to make some changes to your suggested short term fix to
get it to compile on windows. But once I did that your patch fixed the crash
and I was able to drag and drop again.
Comment 44 Bill Gianopoulos [:WG9s] 2005-02-25 18:30:18 PST
I built using the "updated short term fix" and was unable to make the browser
crash via drag and drop.

Unfortunately the second regression (the one mentioned in comment #37) still
exists.  It appears to be related to the speed at which you move the mouse off
of the item that causes the tooltip to appear.  If you move it slowly, all is
fine, if you move it too quickly the tooltip remains.  This is particualarly
annoying if you are using sage.  I often end up with part of the left side of
the news item being hidden by a tooltip.
Comment 45 Boris Zbarsky [:bz] (Out June 25-July 6) 2005-02-25 21:34:18 PST
Comment on attachment 175599 [details] [diff] [review]
updated short term fix

Scott, thanks for testing and fixing the patch! Requesting reviews...

For the tooltip issue, I suspect it really ties back to why we have this timer
code.  I'm guessing that somehow we don't properly detect mousesouts on
Windows, so we had this hack to force them to fire every so often.  But now we
intercept these MOUSE_EXIT events and convert them to mouse-move events, with
the ESM synthesizing the mouseout/mousein... That may be effectively canceling
out the hack.
Comment 46 Ere Maijala (slow) 2005-02-26 01:10:18 PST
Created attachment 175632 [details] [diff] [review]
Updated short term fix v1.1

The Windows timers are repeating and this one also needs to be. This patch only
changes the type to TYPE_REPEATING_SLACK and works great for me but others are
invited to test too.
Comment 47 Bill Gianopoulos [:WG9s] 2005-02-26 05:28:50 PST
(In reply to comment #46)
> Created an attachment (id=175632) [edit]
> Updated short term fix v1.1
> 
> The Windows timers are repeating and this one also needs to be. This patch only
> changes the type to TYPE_REPEATING_SLACK and works great for me but others are
> invited to test too.

Even with this patch I still get tooltips remaing all over the place.  It is
great to have the crash fixed, but the browser is still virtually unusable as my
primary browser.  The tooltips even persit if you open a new application and
obscure the new window as well.  I tried shortening the timer and that apepars
to be better, but even shortening it from 200 to 20 I still get the problem.

Comment 48 Ere Maijala (slow) 2005-02-26 09:30:15 PST
Comment on attachment 175632 [details] [diff] [review]
Updated short term fix v1.1

Ok, I was finally able to reproduce the problem. I thought before that the
timer change fixed it. Investigating.
Comment 49 Ere Maijala (slow) 2005-02-26 11:56:27 PST
Created attachment 175660 [details] [diff] [review]
Patch to patch v1.2

This is getting ugly. This patch makes sure mouseTrailer's timerProc gets
called at least once for a window. Works better, but there's still something
wrong somewhere and I think we should really do something about the trailer,
maybe get rid of it altogether.
Comment 50 Ere Maijala (slow) 2005-02-26 13:18:43 PST
For some reason all nsXULTooltipListeners are not getting the MouseOut properly.
This can cause for example the url bar tooltip to be displayed after entering
and address, pressing enter and moving the mouse to the content area. 
Comment 51 Ere Maijala (slow) 2005-02-26 13:51:00 PST
Comment on attachment 175660 [details] [diff] [review]
Patch to patch v1.2

I think we should get this in to stop the crashing or back out the original
patch.
Comment 52 Jerry Baker 2005-02-26 14:44:28 PST
See bug 283757.
Comment 53 Doug Halamay 2005-02-26 16:46:54 PST
(In reply to comment #51)
> (From update of attachment 175660 [details] [diff] [review] [edit])
> I think we should get this in to stop the crashing or back out the original
> patch. 
> 

I can confirm that this patch fixes, or at least reduces the severity, of the
tooltips problem.  They don't seem to appear all over the place and hang around
forever anymore.
Comment 54 Bill Gianopoulos [:WG9s] 2005-02-26 20:23:04 PST
I rebuilt with the v1.2 patch and it seems much better.  This should be fine as
an interim fix.  Fixes the crashes and I can't dplicate the tooltip issue either.
Comment 55 Scott MacGregor 2005-02-27 08:37:00 PST
emaijala's updated version of my updated version of Boris's original fix is
still working for me :)
Comment 56 Boris Zbarsky [:bz] (Out June 25-July 6) 2005-02-27 09:43:42 PST
Comment on attachment 175660 [details] [diff] [review]
Patch to patch v1.2

Er..  r+sr=bzbarsky, with nsnull instead of NULL.  I do think that we should
sort out why this MouseTrailer stuff is needed and fix the real bug we have
here...
Comment 57 Boris Zbarsky [:bz] (Out June 25-July 6) 2005-02-27 09:54:37 PST
One other note.  If we do decide this is the right fix going forward, I'd like
us to only call the TimerProc if the old window is not the same as the new
window.  As things stand, we'll fire MouseMove events twice on every mousemove,
as far as I see....  I'd make that change to the patch now, but I'm not in a
position to compile or test such changes, so....
Comment 58 Boris Zbarsky [:bz] (Out June 25-July 6) 2005-02-27 11:05:17 PST
I checked the patch in as-is for now, to fix the crashes....
Comment 59 Ere Maijala (slow) 2005-02-27 11:20:55 PST
Thanks for checking it in. I agree with all the things you said. 
Comment 60 neil@parkwaycc.co.uk 2005-02-27 12:52:45 PST
(In reply to comment #56)
>I do think that we should sort out why this MouseTrailer stuff is needed
As far as I can tell it's to make up for the lack of a native mouse exit event
(except when you're capturing the mouse, which should be true during a drag,
because you still receive mouse events after it leaves the window).
Comment 61 Boris Zbarsky [:bz] (Out June 25-July 6) 2005-02-27 14:48:13 PST
Ah, ok.  Still sounds like this would miss events if you move our and in faster
than in 200ms (which is not so hard)....
Comment 62 timeless 2005-02-27 21:31:15 PST
*** Bug 283693 has been marked as a duplicate of this bug. ***
Comment 63 Worcester12345 2005-02-28 06:44:21 PST
Requesting to block 1.1 as it makes email not able to move a message at all.
Comment 64 Scott MacGregor 2005-02-28 08:56:38 PST
sasquatch please don't nominate bugs that have already been fixed for a release.
that just generates unnecessary noise. 
Comment 65 Worcester12345 2005-02-28 11:14:02 PST
(In reply to comment #64)
> sasquatch please don't nominate bugs that have already been fixed for a release.
> that just generates unnecessary noise. 

I took a look here, and don't see that it is fixed. I am not sure what you mean.
Comment 66 Ere Maijala (slow) 2005-02-28 11:54:10 PST
It actually feels like we're only missing them if there is something else
happening at the same time (such as a page loading). That's what I'm seeing anyway. 
Comment 67 Boris Zbarsky [:bz] (Out June 25-July 6) 2005-02-28 13:27:34 PST
Sasquatch, see comment 58.  Did you even bother to test a build after that
checkin before commenting?
Comment 68 Worcester12345 2005-02-28 14:29:58 PST
(In reply to comment #67)
> Sasquatch, see comment 58.  Did you even bother to test a build after that
> checkin before commenting?

Yes. If I'm not mistaken, the Thunderbird bug was duplicated to this one, and I
was still getting trouble with email. See that bug for details.
Comment 69 Worcester12345 2005-02-28 14:31:43 PST
Addition to above comment: There have been so many bugs lately, that I may be
mistaken. I might have just scanned the top of the bug to see if it was fixed
yet. I think an "hourly" build of Thunderbird does seem to work. Thanks.
Comment 70 Bill Gianopoulos [:WG9s] 2005-03-01 04:17:51 PST
Should the bugs on all the fallout from the original check-in for this be closed?
This would be bugs 283478, 283757 and 283623.

Additionally, does it make sense to close this bug and open a new one:

Summary:  Windows mouse event handling code is ugly
Desc:     The Windows Mouse Event handling code is ugly.  The Mouse Trailer
stuff needs to go.  See bug 125386 for more details.
Comment 71 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-03-01 20:25:52 PST
So are the bugs here all fixed, so we can close this?

It looks like we could use TrackMouseEvent, although it's not clear whether it
works on Win95.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/userinput/mouseinput/mouseinputreference/mouseinputfunctions/trackmouseevent.asp
Comment 72 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-03-01 20:28:10 PST
This page has some interesting notes.

http://www.mvps.org/user32/setcapture.html
Comment 73 Boris Zbarsky [:bz] (Out June 25-July 6) 2005-03-01 21:20:37 PST
There is one outstanding issue: comment 57.  We could spin off a separate bug on
that one, though.
Comment 74 Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com] 2005-03-02 08:38:19 PST
Created attachment 176048 [details]
stack

I'm crashing... see the stack.
Comment 75 Boris Zbarsky [:bz] (Out June 25-July 6) 2005-03-02 09:40:19 PST
Just to clarify, CTho is using a build _with_ the patch that landed.

Since MouseTrailer::TimerProc doesn't do anything with fontmetrics, my first
guess is that the mousetrailer we're calling is already destroyed... but given
that it's a class static, I don't really see that happening.

Past that, I don't reallyt see what could possibly be going on here.
Comment 76 Dan M 2005-03-03 12:29:01 PST
"fix #2" caused bug 284664
Comment 77 OstGote! 2005-03-04 07:31:22 PST
With 2005030305 builds (i.e. with the patch) I crashed 2 times, not really
reproducable after a while. The CVS blame for the first stack line with a
function leads me to this bug.

TB4108752Z

0x0072016c
nsWindow::DispatchMouseEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 5506]
ChildWindow::DispatchMouseEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 5750]
nsWindow::WindowProc 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 1419]
USER32.dll + 0x124c (0x77e7124c)
Comment 78 David :Bienvenu 2005-03-04 07:55:49 PST
this crash seems to happen when I move the mouse over the new message alert
window. The mouse handler doesn't look obviously deleted (no dddd's or
deadbeef's) but the vtable for the iSupports is messed up, as if there was a bad
cast somewhere.
Comment 79 Worcester12345 2005-03-04 12:00:23 PST
(In reply to comment #63)
> Requesting to block 1.1 as it makes email not able to move a message at all.

I could have sworn I put in a ? to nominate this as a blocker, yet there is no ?
no + and no - sign. What happened?
Comment 80 James Ross 2005-03-04 12:53:09 PST
You did, but mscott@mozilla.org removed it, see comment 64. The bug was
RESO:FIXED at the time, but now it is reopen maybe it needs re-nominating? I'm
no expert on what should or should not block, though.
Comment 81 Boris Zbarsky [:bz] (Out June 25-July 6) 2005-03-04 13:15:43 PST
Created attachment 176311 [details] [diff] [review]
Possible fix for that crash?

Could someone test this?  This is the best guess we have so far as to what
could be going on...
Comment 82 Boris Zbarsky [:bz] (Out June 25-July 6) 2005-03-04 13:21:26 PST
I'm re-resolving this bug fixed, in hopes of stopping the noise and confusion on
the part of people who don't read _all_ the comments.  The bug as filed is
fixed.  The major regression is fixed (that should have been in a separate bug,
probably, instead of reopening this one).  The remaining issues (a weird very
hard to reproduce crash and comment 57) should go in separate bugs.
Comment 83 Frank Wein [:mcsmurf] 2005-03-05 16:53:38 PST
I filed Bug 284951 about that crash.
Comment 84 Boris Zbarsky [:bz] (Out June 25-July 6) 2005-03-06 09:19:34 PST
Bug 285000 filed on the "code isn't really right" issue.
Comment 85 José Jeria 2005-04-21 00:42:33 PDT
*** Bug 236925 has been marked as a duplicate of this bug. ***
Comment 86 Martijn Wargers [:mwargers] (not working for Mozilla) 2005-06-12 16:21:14 PDT
*** Bug 296189 has been marked as a duplicate of this bug. ***
Comment 87 José Jeria 2005-07-22 02:01:20 PDT
*** Bug 301684 has been marked as a duplicate of this bug. ***
Comment 88 Kevin Sacry 2005-09-29 15:57:41 PDT
when is this going to be fixed in
firefox????????????????????????????????????????????????????????????????????????????????????????????????????
Comment 89 Boris Zbarsky [:bz] (Out June 25-July 6) 2005-09-29 20:02:50 PDT
It's been fixed since February 2005.  Given your question and the wholly
excessive number of question marks in it, I have to assume that you're using a
1.0.x version of Firefox, which is code from April 2004 with some security
fixes.  I recommend you try a recent Firefox version (for example Deer Park
alpha 1 or the upcoming Firefox 1.5 beta) if you want to see what's been fixed
in Firefox in the last year and a half.
Comment 90 Kevin Sacry 2005-10-04 09:42:04 PDT
I don't mean to be rude, but when is the fix going to be in a version that
people accually use. It's nice that I can use the fix by downloading a beta
version, but no one visiting my web page can. They would all be using the latest
release 1.0.7. Is there any way I can figure out when this fix will be
implemented in the main stream firefox? Thanks
Comment 91 Boris Zbarsky [:bz] (Out June 25-July 6) 2005-10-04 14:48:42 PDT
It'll be in 1.5 whenever that ships.  I believe current plans are aiming for
sometime this fall.
Comment 92 Boris Zbarsky [:bz] (Out June 25-July 6) 2006-04-16 21:55:28 PDT
This caused bug 311558...

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