Closed
Bug 71807
Opened 24 years ago
Closed 24 years ago
scaryviewmanager crashes after tooltip display ...
Categories
(Core :: Web Painting, defect)
Tracking
()
People
(Reporter: dales, Assigned: roc)
References
()
Details
(Keywords: crash)
Attachments
(1 file)
(deleted),
text/html
|
Details |
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.
Comment 1•24 years ago
|
||
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.
Comment 2•24 years ago
|
||
Unable to duplicate this bug under Linux and 2001031305
Comment 3•24 years ago
|
||
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
Comment 4•24 years ago
|
||
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
Comment 6•24 years ago
|
||
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 ...
>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
Assignee | ||
Comment 9•24 years ago
|
||
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
Updated•6 years ago
|
Component: Layout: View Rendering → Layout: Web Painting
You need to log in
before you can comment on or make changes to this bug.
Description
•