flyout menu disappears when mouse passes over scrollable div or iframe

RESOLVED FIXED

Status

()

Core
DOM: Events
--
major
RESOLVED FIXED
15 years ago
10 years ago

People

(Reporter: Richard P. Gnall, Assigned: roc)

Tracking

(Blocks: 1 bug, {testcase})

Trunk
x86
Windows 98
testcase
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.7.5 -
blocking1.8a4 -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(9 attachments, 4 obsolete attachments)

1.06 KB, text/html
Details
821 bytes, text/html
Details
877 bytes, text/html
Details
799 bytes, text/html
Details
1.78 KB, patch
jhp (no longer active)
: review+
Simon Fraser
: superreview+
Details | Diff | Splinter Review
5.52 KB, patch
Details | Diff | Splinter Review
5.03 KB, patch
Details | Diff | Splinter Review
1.20 KB, text/plain
Details
1.58 KB, patch
Details | Diff | Splinter Review
(Reporter)

Description

15 years ago
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
(Reporter)

Comment 1

15 years ago
Created attachment 69366 [details]
Flyout menu passing over scrollabe div
Robert, at first glance this looks like a view/viewmanager problem, could you
investigate?
Status: UNCONFIRMED → NEW
Component: DOM Style → DOM HTML
Ever confirmed: true
Yeah, looks like me. This should have been fixed by my recent changes. Hmm...
Assignee: jst → roc+moz
Created attachment 69699 [details]
new testcase

This testcase seems to show that the view manager is not at fault.
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.
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? 
Assignee: roc+moz → jst
nsEventStateManager belongs to joki, so reassigning to him, and nominating for
mozilla1.0
Assignee: jst → joki
Component: DOM HTML → DOM Events
Keywords: mozilla1.0, nsbeta1
QA Contact: ian → vladimire

Comment 8

15 years ago
nsbeta1- per ADT triage team.  Will reconsider if this can be demonstrated on a
top site.
Keywords: nsbeta1 → nsbeta1-

Updated

15 years ago
Target Milestone: --- → mozilla1.2
*** Bug 147087 has been marked as a duplicate of this bug. ***

Comment 10

15 years ago
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

15 years ago
Either related or a dupe of bug 136527. Are divs and scrollable iframes simular
in some way, in terms of implementation?

Updated

15 years ago
Keywords: mozilla1.0 → mozilla1.3

Updated

15 years ago
Blocks: 113492

Updated

15 years ago
Priority: -- → P2

Comment 12

15 years ago
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.

Updated

15 years ago
Blocks: 136527

Updated

14 years ago
Severity: normal → major

Updated

14 years ago
Keywords: mozilla1.3 → testcase

Comment 13

13 years ago
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

13 years ago
*** Bug 243843 has been marked as a duplicate of this bug. ***

Comment 15

13 years ago
*** Bug 208107 has been marked as a duplicate of this bug. ***

Comment 16

13 years ago
Created attachment 148755 [details]
Simplified testcase showing extent of problem

Updated

13 years ago
Flags: blocking1.7+

Updated

13 years ago
Summary: flyout menu disappears when mouse passes over scrollable div → flyout menu disappears when mouse passes over scrollable div or iframe

Comment 17

13 years ago
only drivers can set (+) blocking flags.  you can request (?) them.
Assignee: joki → events
Flags: blocking1.7+
Priority: P2 → --
QA Contact: vladimire → ian
Target Milestone: mozilla1.2alpha → ---

Comment 18

13 years ago
Bug 164302 seems to be a dupe of this one.

Updated

13 years ago
Blocks: 243843
Flags: blocking1.8a4?

Comment 19

13 years ago
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
No longer blocks: 243843

Comment 20

13 years ago
*** Bug 259598 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Flags: blocking1.8a4? → blocking1.8a4-

Updated

13 years ago
Flags: blocking1.7.5?

Updated

13 years ago
Flags: blocking1.7.5? → blocking1.7.5-

Comment 21

12 years ago
<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

12 years ago
*** Bug 281549 has been marked as a duplicate of this bug. ***
Assignee: events → peterv
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.
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?
Assignee: peterv → roc
Status: NEW → ASSIGNED
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.
Excellent. Thanks for testing it. I'll get reviews for my patch, you get reviews
for yours :-)
Comment on attachment 174015 [details] [diff] [review]
fix?

Apparently this patch alone fixes GTK2 and Windows, and Peter has an additional
fix for OSX...
Attachment #174015 - Flags: superreview?(bzbarsky)
Attachment #174015 - Flags: review?(bzbarsky)
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++) {
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?
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.
Attachment #174015 - Attachment is obsolete: true
Attachment #174320 - Flags: superreview?(bzbarsky)
Attachment #174320 - Flags: review?(bzbarsky)
Attachment #174015 - Flags: superreview?(bzbarsky)
Attachment #174015 - Flags: review?(bzbarsky)
Attachment #174052 - Flags: superreview?(sfraser_bugs)
Attachment #174052 - Flags: review?(jhpedemonte)

Comment 31

12 years ago
Comment on attachment 174052 [details] [diff] [review]
Additional fix on OS X

Gotta love those files with tabs.
Attachment #174052 - Flags: superreview?(sfraser_bugs) → superreview+
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.
Attachment #174320 - Flags: superreview?(bzbarsky)
Attachment #174320 - Flags: superreview+
Attachment #174320 - Flags: review?(bzbarsky)
Attachment #174320 - Flags: review+

Updated

12 years ago
Attachment #174052 - Flags: review?(jhpedemonte) → review+
(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.
Attachment 174052 [details] [diff] checked in.
checked in
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED

Comment 36

12 years ago
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.

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

12 years ago
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).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Updated

12 years ago
Blocks: 283478

Comment 39

12 years ago
This bug fix causes drag and drop operations to crash in Thunderbird. Please see
Bug #283693 for more details. 
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.
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)...
No longer blocks: 283478
Depends on: 283478, 283693
Created attachment 175589 [details] [diff] [review]
Attempt at the short-term fix

Could someone with a Windows build test this?

Comment 43

12 years ago
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.
Attachment #175589 - Attachment is obsolete: true
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 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.
Attachment #175599 - Flags: superreview?(brendan)
Attachment #175599 - Flags: review?(emaijala)

Comment 46

12 years ago
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.

Updated

12 years ago
Attachment #175599 - Attachment is obsolete: true
Attachment #175632 - Flags: superreview?(brendan)
Attachment #175632 - Flags: review+
(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

12 years ago
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.
Attachment #175632 - Attachment is obsolete: true
Attachment #175632 - Flags: superreview?(brendan)
Attachment #175632 - Flags: review-
Attachment #175632 - Flags: review+

Comment 49

12 years ago
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

12 years ago
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

12 years ago
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.
Attachment #175660 - Flags: superreview?(bzbarsky)
Attachment #175660 - Flags: review?(bzbarsky)

Comment 52

12 years ago
See bug 283757.

Updated

12 years ago
Blocks: 283757

Comment 53

12 years ago
(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.
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.
Blocks: 283942

Comment 55

12 years ago
emaijala's updated version of my updated version of Boris's original fix is
still working for me :)
Attachment #175660 - Flags: superreview?(bzbarsky)
Attachment #175660 - Flags: superreview-
Attachment #175660 - Flags: review?(bzbarsky)
Attachment #175660 - Flags: review-
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...
Attachment #175660 - Flags: superreview-
Attachment #175660 - Flags: superreview+
Attachment #175660 - Flags: review-
Attachment #175660 - Flags: review+
Attachment #175599 - Flags: superreview?(brendan)
Attachment #175599 - Flags: superreview-
Attachment #175599 - Flags: review?(emaijala)
Attachment #175599 - Flags: review-
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....
I checked the patch in as-is for now, to fix the crashes....

Comment 59

12 years ago
Thanks for checking it in. I agree with all the things you said. 

Comment 60

12 years ago
(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).
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

12 years ago
*** Bug 283693 has been marked as a duplicate of this bug. ***

Updated

12 years ago
Flags: blocking-aviary1.1?

Comment 63

12 years ago
Requesting to block 1.1 as it makes email not able to move a message at all.

Comment 64

12 years ago
sasquatch please don't nominate bugs that have already been fixed for a release.
that just generates unnecessary noise. 
Flags: blocking-aviary1.1?

Comment 65

12 years ago
(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

12 years ago
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. 
Sasquatch, see comment 58.  Did you even bother to test a build after that
checkin before commenting?

Comment 68

12 years ago
(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

12 years ago
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.
Blocks: 283623
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.

Updated

12 years ago
Blocks: 244385
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
Status: REOPENED → ASSIGNED
This page has some interesting notes.

http://www.mvps.org/user32/setcapture.html
There is one outstanding issue: comment 57.  We could spin off a separate bug on
that one, though.
Created attachment 176048 [details]
stack

I'm crashing... see the stack.
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

12 years ago
"fix #2" caused bug 284664

Comment 77

12 years ago
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

12 years ago
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

12 years ago
(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

12 years ago
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.
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...
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago12 years ago
Resolution: --- → FIXED
I filed Bug 284951 about that crash.
Bug 285000 filed on the "code isn't really right" issue.

Updated

12 years ago
Blocks: 286826

Comment 85

12 years ago
*** Bug 236925 has been marked as a duplicate of this bug. ***
*** Bug 296189 has been marked as a duplicate of this bug. ***

Comment 87

12 years ago
*** Bug 301684 has been marked as a duplicate of this bug. ***

Comment 88

12 years ago
when is this going to be fixed in
firefox????????????????????????????????????????????????????????????????????????????????????????????????????
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

12 years ago
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
It'll be in 1.5 whenever that ships.  I believe current plans are aiming for
sometime this fall.

Updated

12 years ago
Blocks: 311558
No longer blocks: 311558
Depends on: 311558
This caused bug 311558...

Updated

10 years ago
Depends on: 297080
You need to log in before you can comment on or make changes to this bug.