Closed Bug 71807 Opened 24 years ago Closed 24 years ago

scaryviewmanager crashes after tooltip display ...

Categories

(Core :: Web Painting, defect)

x86
Windows NT
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 72055

People

(Reporter: dales, Assigned: roc)

References

()

Details

(Keywords: crash)

Attachments

(1 file)

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; 0.8.1) Gecko/20010312 BuildID: 2001031220 This is a problem that I have seen for some time and it's present in the build ID given above. When I go to the build summaries page off the main mozillazine.org page and point to one of the bugs mentioned a tooltip should appear giving a short description of that bug. Thus far all is well. But if (1) I go to another bug and pause long enough to display the tooltip OR (2) I pause for several seconds on the first bug displaying the tooltip for and extended period (a couple seconds maybe), Mozilla crashes with a quiet freeze and then a Dr. Watson dump occurs. This is on WinNT 5.0 SP5. I am running Mozilla with the Modern skin. I am running WindowBlinds, but I have disabled its application to MOzilla. That's pretty much it ... I can extract a Dr. Watson log if needed. Dale Reproducible: Always Steps to Reproduce: 1. Launch Mozilla 2. Go to <http://www.mozillazine.org> 3. Click on the "READ MORE" link in the build bar at the top. 4. Point to any of the bugs listed in the daily commentaries 5. Pause till a tooltip appears 6a. Move the pointer to another bug and hold till a tooltip displays OR 6b. Hold the pointer on the first bug for a few seconds OR (this is a newly discovered way) 6c. Point to one of the links in the Personal Toolbar and hold till a tooltip appears and continue holding for several seconds. 7. Mozilla crashes (freezes until Dr. Watson's dialog is dismissed and then Mozilla's window(s) disappear). Actual Results: Mozilla crashes Expected Results: Tooltips should display for as long as needed and should display as many as needed in a row.
Which version of WindowBlinds are you using? I know some of the earlier versions were pretty prone to crashing applications, and I think that's true whether or not it was enabled for the application.
Unable to duplicate this bug under Linux and 2001031305
As mentioned on #Mozillazine, I can confirm this bug under Windows NT4. I'm attaching a testcase which consistently causes a crash for me. You can mouse over two links without any problems, but the third causes a crash.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached file testcase to reproduce tooltip crasher (deleted) —
Re: Which version of WindowBlinds are you using? I have version 2.11 Build 8505 running. But I've done a check and WindowBlinds isn't the culprit this time ... I unloaded window blinds THEN launched Mozilla and pointed to first one then another of the links in my Personal Toolbar. The first tooltip displayed fine; the second went into deep freeze (i.e., crashed Mozilla). Re: The Test Case (Attachment id=27679) I tried this in the 2001031320 build of Mozilla. No different from yesterday and not expected to be. I do however crash on Link 2 ... but that doesn't seem to be a significant difference. Good to have a test case; the Personal Toolbar is also a good test case. Dale
I managed to track this down to a pref in prefs.js. If you delete this line: user_pref("nglayout.debug.enable_scary_view_manager", true); Then the crash no longer occurs. I can view the attached test case without any problems.
scary viewmanager => roc
Assignee: asa → roc+moz
Component: Browser-General → Views
Keywords: crash
QA Contact: doronr → petersen
Summary: Browser crashes after tooltip display ... → scaryviewmanager crashes after tooltip display ...
Blocks: 39621
Status: NEW → ASSIGNED
>I managed to track this down to a pref in prefs.js. If you delete this line: > >user_pref("nglayout.debug.enable_scary_view_manager", true); > >Then the crash no longer occurs. Confirmed here with WinNT 4 SP5. One additional itme. I checked the bug on my Mac w/ Mac OS 9.1. It was not present there, though I had that pref set TRUE just like this NT box was. Something's different with the Mac Mozilla. Dale
I'm pretty sure this is a duplicate of bug 72055. Marking as such. If the fix to 72055 doesn't fix this, please reopen this one. *** This bug has been marked as a duplicate of 72055 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: