Overview Description: Moving the cursor between the back and forward buttons and bringing up tooltips crashes seamonkey Steps to Reproduce: 1) Open seamonkey 2) mouse over Back and Forward buttons waiting for the "Go Back, Jo Jo" tooltip to appear each time 3) After just a few passes, Seamonkey will crash Build Date & Platform Bug Found: Build #1999070108, Win95 p166, 32 MB RAM Additional Information: There are at least three talkback reports from me on this.
Assignee: trudelle → pinkerton
Priority: P3 → P1
Target Milestone: M8
reassigning to pinkerton as p1 for m8
I'll look into this, but fyi, i pulled the tooltips from back and forward. Now there is only one on the "dayplanner" button at the bottom. Hopefully no one will notice that one. accepting bug.
Assignee: pinkerton → joki
Status: ASSIGNED → NEW
Summary: [CRASH] Tooltips on back and forward crash Seamonkey → [CRASH] Tooltips crash when mouse enters tip
Reassigning to joki. hyatt and I think this is an eventStateManager bug. The problem only happens when the mouse enters the tooltip itself. This generates a "mouse out" event of the button that spawned the tooltip and causes the code to delete the tooltip (which is the behavior we want). However, we think that since the mouse entered the tooltip, the eventstateManager is confused, forgets to reset itself when the tooltip goes away, and then crashes some time later.
dbarron noticed after moving to dayplanner... http://bugzilla.mozilla.org/show_bug.cgi?id=9593 joki, any idea on the time table for fixing this in m8?
*** Bug 9593 has been marked as a duplicate of this bug. ***
Okay, I have some more info on this one anyway. A mousemove is being generated by the new tooltip window. Durnig processing of this mousemove we delete the tooltip window. However, since the event isn't cancelled we then merrily try to let Window's do its regular processing on the event. The hWnd is null, crash-o-rama. I have a couple possible fixes. Need to talk to widget guys about them. Also, I'm getting a bunch of asserts from RDF stuff when it does try to bring up the window. Not sure what those are. Either way we can resolve this today.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
Okay, fix checked in. For verification, keep in mind that this bug was that we *crash* on tooltips, not that they don't work. We still get debug assertions in tooltips which apparently there is another bug for, but we should stop crashing.
this apparently was a cross platform bug. it still occurs on linux, so i'm reopening. the procedure to recreate is the same (using the dayplanner button). reproducable crash occurs every time on: 1999-07-13-08 RedHat Linux 5.2 kernel 2.2.9 crash does not occur on: 1999-07-13-10 WinNT 4.0 sp4 1999-07-13-09 MacOS 8.51
need some help from ramiro on the linux problem.
Setting to M9 for Linux fix.
Still need linux help to fix this. Don't know the likelihood of it making M9. Not sure whether to just reassign without any input but I know I'm not actually doing anything with it.
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago → 19 years ago
Resolution: --- → FIXED
closing this bug, as 10016 covers it with the correct stack trace. This is now just a linux problem that has to do with resize events coming in after the window is closed.
mike, is there a bug open on this linux problem, or should we use this bug to track it?
verified fixed on 1999-08-13-08 RedHat Linux 6.0 (GNOME/enlightenment) 1999-08-13-08 WinNT 4.0 sp5 1999-08-13-08 MacOS 8.51
You need to log in before you can comment on or make changes to this bug.