[CRASH] Tooltips crash when mouse enters tip

VERIFIED FIXED in M9

Status

()

Core
XUL
P1
normal
VERIFIED FIXED
19 years ago
19 years ago

People

(Reporter: Michael La Guardia, Assigned: joki (gone))

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: no fix in hand for linux- win and mac ok)

(Reporter)

Description

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

Updated

19 years ago
Assignee: trudelle → pinkerton
Priority: P3 → P1
Target Milestone: M8

Comment 1

19 years ago
reassigning to pinkerton as p1 for m8
Status: NEW → ASSIGNED
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.

Comment 4

19 years ago
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?

Comment 5

19 years ago
*** Bug 9593 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 6

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

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 7

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

Updated

19 years ago
Status: RESOLVED → REOPENED
OS: Windows 95 → All

Updated

19 years ago
Resolution: FIXED → ---

Comment 8

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

Updated

19 years ago
Whiteboard: no fix in hand for linux- win and mac ok

Comment 9

19 years ago
need some help from ramiro on the linux problem.

Updated

19 years ago
Target Milestone: M8 → M9

Comment 10

19 years ago
Setting to M9 for Linux fix.
(Assignee)

Comment 11

19 years ago
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 ago19 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.

Comment 13

19 years ago
mike, is there a bug open on this linux problem, or should we use this bug to
track it?

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 14

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