Closed
Bug 51096
Opened 25 years ago
Closed 25 years ago
Changing the mousewheel settings twice, then using the wheel, crashes the browser
Categories
(Core :: XUL, defect, P3)
Tracking
()
VERIFIED
FIXED
M18
People
(Reporter: jcarpenter0524, Assigned: bryner)
Details
(Keywords: crash, Whiteboard: [nsbeta3+])
Attachments
(1 file)
|
1.78 KB,
text/plain
|
Details |
Overview Description:
On Windows platforms only, entering prefs and changing the mousewheel setting,
exiting, and then doing it again, will cause the browser to crash the next time
you use the mousewheel.
Steps to Reproduce:
- Edit prefs
- Under Advanced/Mousewheel change the setting to any other setting
- Save/exit prefs (mousewheel works fine)
- Repeat above, and change mousewheel setting to something else
- Save/exit prefs and use mousewheel
Actual Results:
Browser crashes
Build Date & Platform Bug Found:
2000-09-01-11-M18 : Win32
Additional Builds and Platforms Tested On:
2000-09-01-10-M18 : Linux (worked fine, no crash)
Additional Information:
Attaching Talkback report: 16705902
| Reporter | ||
Comment 1•25 years ago
|
||
| Reporter | ||
Updated•25 years ago
|
Priority: P3 → P2
Comment 3•25 years ago
|
||
reassigning to bryner, nominating for nsbeta3. How likely is this scenario?
How critical are these prefs?
Assignee: trudelle → bryner
Keywords: nsbeta3
| Assignee | ||
Comment 4•25 years ago
|
||
Here is the relevant section of code from that build:
781 bryner 1.188 nsCOMPtr<nsIScriptGlobalObject> ourGlobal;
782
gLastFocusedDocument->GetScriptGlobalObject(getter_AddRefs(ourGlobal));
783 vidur 1.199 nsCOMPtr<nsIDOMWindowInternal> rootWindow;
784 bryner 1.188 nsCOMPtr<nsPIDOMWindow> ourWindow =
do_QueryInterface(ourGlobal);
785 NS_ENSURE_TRUE(ourWindow, NS_ERROR_FAILURE);
It looks to me like the crash at line 784 could really only happen if
'ourGlobal' was garbage. cc'ing saari to see if he knows how this could happen.
Status: NEW → ASSIGNED
Comment 5•25 years ago
|
||
saari is on vacation this week. Do we need to interrupt him for this?
| Assignee | ||
Comment 6•25 years ago
|
||
No, I don't think so.
One obvious thing I could try is simply a null check on ourGlobal. I'm not sure
this would fix the problem but it certainly wouldn't hurt. Should I go ahead
and check that in?
Comment 7•25 years ago
|
||
If that will prevent the crash, and not just relocate it, then I'd take it.
Comment 8•25 years ago
|
||
nsbeta3+/P3, just to stop the crash.
Priority: P2 → P3
Whiteboard: [nsbeta3+]
Target Milestone: --- → M18
| Assignee | ||
Comment 9•25 years ago
|
||
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Comment 10•25 years ago
|
||
Jan, can you verify this? (I am mousewheel-deprived ...)
QA Contact: jrgm → janc
You need to log in
before you can comment on or make changes to this bug.
Description
•