Closed Bug 125386 Opened 23 years ago Closed 20 years ago

flyout menu disappears when mouse passes over scrollable div or iframe

Categories

(Core :: DOM: Events, defect)

Product:
Core
Component:
DOM: Events
Platform:
x86
Windows 98
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: rpgnall, Assigned: roc)

References

(
URL
)

Details

(Keywords: testcase)

Attachments

(9 files, 4 obsolete files)

Flyout menu passing over scrollabe div
1.06 KB, text/html
Details
new testcase
821 bytes, text/html
Details
Even better testcase
877 bytes, text/html
Details
Simplified testcase showing extent of problem
799 bytes, text/html
Details
Additional fix on OS X
1.78 KB, patch
jhpedemonte
: review+
sfraser_bugs
: superreview+
Details | Diff | Splinter Review
fix #2
5.52 KB, patch
bzbarsky
: review+
bzbarsky
: superreview+
Details | Diff | Splinter Review
Patch to patch v1.2
5.03 KB, patch
bzbarsky
: review+
bzbarsky
: superreview+
Details | Diff | Splinter Review
stack
1.20 KB, text/plain
Details
Possible fix for that crash?
1.58 KB, patch
Details | Diff | Splinter Review
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
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
Attached file new testcase —
This testcase seems to show that the view manager is not at fault.
Attached file 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
nsbeta1- per ADT triage team. Will reconsider if this can be demonstrated on a top site.
Keywords: nsbeta1 → nsbeta1-
Target Milestone: --- → mozilla1.2
*** Bug 147087 has been marked as a duplicate of this bug. ***
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.
Either related or a dupe of bug 136527. Are divs and scrollable iframes simular in some way, in terms of implementation?
Keywords: mozilla1.0 → mozilla1.3
Blocks: 113492
Priority: -- → P2
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.
Blocks: 136527
Severity: normal → major
Keywords: mozilla1.3 → testcase
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.
*** Bug 243843 has been marked as a duplicate of this bug. ***
*** Bug 208107 has been marked as a duplicate of this bug. ***
Flags: blocking1.7+
Summary: flyout menu disappears when mouse passes over scrollable div → flyout menu disappears when mouse passes over scrollable div or iframe
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 → ---
Bug 164302 seems to be a dupe of this one.
Blocks: 243843
Flags: blocking1.8a4?
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
*** Bug 259598 has been marked as a duplicate of this bug. ***
Flags: blocking1.8a4? → blocking1.8a4-
Flags: blocking1.7.5?
Flags: blocking1.7.5? → blocking1.7.5-
<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?
*** 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.
Attached patch fix? (obsolete) — — Splinter Review
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
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?
Attached patch fix #2 — — Splinter Review
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 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+
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.
checked in
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
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.
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 → ---
Blocks: 283478
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
Attached patch Attempt at the short-term fix (obsolete) — — Splinter Review
Could someone with a Windows build test this?
Attached patch updated short term fix (obsolete) — — Splinter Review
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)
Attached patch Updated short term fix v1.1 (obsolete) — — Splinter Review
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.
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 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+
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.
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 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)
See bug 283757.
Blocks: 283757
(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
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....
Thanks for checking it in. I agree with all the things you said.
(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)....
*** Bug 283693 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.1?
Requesting to block 1.1 as it makes email not able to move a message at all.
sasquatch please don't nominate bugs that have already been fixed for a release. that just generates unnecessary noise.
Flags: blocking-aviary1.1?
(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.
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?
(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.
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.
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
There is one outstanding issue: comment 57. We could spin off a separate bug on that one, though.
Attached file 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.
"fix #2" caused bug 284664
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)
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.
(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?
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.
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
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
I filed Bug 284951 about that crash.
Bug 285000 filed on the "code isn't really right" issue.
Blocks: 286826
*** Bug 236925 has been marked as a duplicate of this bug. ***
*** Bug 296189 has been marked as a duplicate of this bug. ***
*** Bug 301684 has been marked as a duplicate of this bug. ***
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.
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.
Blocks: 311558
No longer blocks: 311558
Depends on: 311558
This caused bug 311558...
Depends on: 297080
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: