Closed
Bug 490196
Opened 15 years ago
Closed 15 years ago
Firefox crashes when click the spinarrow button to increment and then decrement [@ nsButtonBoxFrame::DoMouseClick]
Categories
(Core :: XUL, defect)
Tracking
()
VERIFIED
FIXED
mozilla1.9.2a1
People
(Reporter: htoshi73, Assigned: smaug)
References
Details
(4 keywords, Whiteboard: [sg:critical?])
Crash Data
Attachments
(2 files)
11.27 KB,
text/plain
|
Details | |
794 bytes,
patch
|
roc
:
review+
roc
:
superreview+
samuel.sidler+old
:
approval1.9.1.2+
dveditz
:
approval1.9.0.14+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.0.9) Gecko/2009040821 Firefox/3.0.9 Firefox crashes when remember visited pages is set to 0 Reproducible: Always Steps to Reproduce: 1. Go to Tool->Option->Privacy setting page. 2. In the history area "Remember visited pages for the last xxx days", click the up-arrow button to increment the value, and decrement it. When the value decreased to "0", Firefox crashes. I have sent 2 crash reports. http://crash-stats.mozilla.com/report/index/be096666-7fee-49d6-aa67-0038f2090425 http://crash-stats.mozilla.com/report/index/57c34c31-3365-4c85-87bb-35dfe2090425
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/xul/base/src/nsButtonBoxFrame.cpp&rev=1.45&mark=142#138 UUID 57c34c31-3365-4c85-87bb-35dfe2090425 Crash Address 0x0 nsButtonBoxFrame::DoMouseClick mozilla/layout/xul/base/src/nsButtonBoxFrame.cpp:143 nsAutoRepeatBoxFrame::Notify mozilla/layout/xul/base/src/nsScrollBoxFrame.cpp:191 nsAutoRepeatBoxFrame::Notify mozilla/layout/xul/base/src/nsScrollBoxFrame.cpp:89 nsRepeatService::Notify mozilla/layout/xul/base/src/nsRepeatService.cpp:116 nsTimerImpl::Fire mozilla/xpcom/threads/nsTimerImpl.cpp:443 ... nsXULWindow::ShowModal mozilla/xpfe/appshell/src/nsXULWindow.cpp:401 nsContentTreeOwner::ShowAsModal mozilla/xpfe/appshell/src/nsContentTreeOwner.cpp:524 xul.dll@0x2fe363 nsWindowWatcher::OpenWindowJS mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp:484 some frame things null check mContent, this file doesn't,
Component: Preferences → XP Toolkit/Widgets: XUL
Keywords: crash
Product: Firefox → Core
QA Contact: preferences → xptoolkit.xul
Summary: Firefox crashes when remember visited pages is set to 0 → Firefox crashes when click the spinarrow button to increment and then decrement [@ nsButtonBoxFrame::DoMouseClick]
Version: unspecified → 1.9.0 Branch
Updated•15 years ago
|
Severity: normal → critical
Comment 3•15 years ago
|
||
Same in Firefox 3.0.11 (the new official version): http://crash-stats.mozilla.com/report/index/cd7ec7f4-713c-41ac-8ac6-b53fe2090611
Comment 4•15 years ago
|
||
New Version, same problem (v3.5) and still unconfirmed :/ Report for v3.5 http://crash-stats.mozilla.com/report/index/55e0f49f-f7b8-4b18-8985-3698c2090701
Comment 5•15 years ago
|
||
Confirming. qawanted: can someone confirm this?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted1.9.1.x?
Flags: wanted1.9.0.x?
Keywords: qawanted
Comment 6•15 years ago
|
||
Achim, normally the down arrow should be disabled after you clicked it and the box has a value of 1. Don't you see that? Can you please further run Firefox in Safe Mode? So we can check if an extension is causing this crash: http://support.mozilla.com/kb/Safe+Mode
Comment 7•15 years ago
|
||
I can click the arrows (from the cache) down from 1 to 0 and than it crash. Safe-Mode: I started Firefox in Safe-Mode and didn't disable anything at the start. Result: No crash when i lower the cache with the arrows to 0 MB Normal-Mode: Lowering the cache with the arrows to 0MB -> Crash Lowering the cash with Mouse and Keybord (not the arrows) to 0 MB -> No Crash
Comment 8•15 years ago
|
||
I found the failure... With Noia2.0 (extreme) Theme = Crash With normal standard Theme = no crash Omg ^^
Comment 9•15 years ago
|
||
Thanks Achim! That looks good and I'm able to reproduce the crash. Let's see what is causing this crash. I'll come up with an analysis shortly.
OS: Windows XP → All
Hardware: x86 → All
Comment 10•15 years ago
|
||
The member mContent is somehow warped and points to an invalid address: gdb) frame 0 #0 0x1338b360 in nsButtonBoxFrame::DoMouseClick (this=0x1d3645a8, aEvent=0x0, aTrustEvent=221) at /data/build/shiretoko/layout/xul/base/src/nsButtonBoxFrame.cpp:142 142 if (mContent->AttrValueIs(kNameSpaceID_None, nsGkAtoms::disabled, (gdb) l 137 138 void 139 nsButtonBoxFrame::DoMouseClick(nsGUIEvent* aEvent, PRBool aTrustEvent) 140 { 141 // Don't execute if we're disabled. 142 if (mContent->AttrValueIs(kNameSpaceID_None, nsGkAtoms::disabled, 143 nsGkAtoms::_true, eCaseMatters)) 144 return; 145 146 // Execute the oncommand event handler. (gdb) p mContent $1 = (class nsIContent *) 0xdddddddd (gdb) p *mContent Cannot access memory at address 0xdddddddd
Assignee | ||
Updated•15 years ago
|
Flags: blocking1.9.1.1?
Flags: blocking1.9.0.13?
Assignee | ||
Updated•15 years ago
|
Assignee: nobody → Olli.Pettay
Assignee | ||
Updated•15 years ago
|
Group: core-security
Assignee | ||
Comment 12•15 years ago
|
||
Can't reproduce on linux. Testing now on OSX.
Assignee | ||
Comment 13•15 years ago
|
||
a bit tricky to debug, but simple fix.
Attachment #386487 -
Flags: superreview?(roc)
Attachment #386487 -
Flags: review?(roc)
Attachment #386487 -
Flags: superreview?(roc)
Attachment #386487 -
Flags: superreview+
Attachment #386487 -
Flags: review?(roc)
Attachment #386487 -
Flags: review+
Assignee | ||
Comment 14•15 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/8a3cfb3a4c21
Assignee | ||
Updated•15 years ago
|
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Comment 15•15 years ago
|
||
Even though the initial description would not amount to a "critical" bug (manual UI fiddling with non-default theme) I'm guessing this could be reproduced with the right web content. We'll want a crashtest for the regression-testing suite and verifying on branches anyway.
Keywords: testcase-wanted
Whiteboard: [sg:critical?]
Comment 18•15 years ago
|
||
Verified fixed on trunk with builds on OS X and Windows: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090703 Minefield/3.6a1pre
Status: RESOLVED → VERIFIED
Flags: in-testsuite?
Keywords: testcase-wanted → testcase
Target Milestone: --- → mozilla1.9.2a1
Updated•15 years ago
|
Flags: wanted1.9.1.x?
Flags: wanted1.9.1.x+
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x+
Updated•15 years ago
|
Flags: blocking1.9.0.13? → blocking1.9.0.13+
Comment 19•15 years ago
|
||
Not for 1.9.1.1, but we'll block on this for 1.9.1.2.
Flags: blocking1.9.1.1?
Whiteboard: [sg:critical?] → [sg:critical?][1.9.1.2+]
Updated•15 years ago
|
blocking1.9.1: --- → .2+
status1.9.1:
--- → wanted
Comment 20•15 years ago
|
||
Is this ready to land? If so, can we get it on mozilla-1.9.1?
Assignee | ||
Comment 21•15 years ago
|
||
Comment on attachment 386487 [details] [diff] [review] patch Applies to branches with some fuzz.
Attachment #386487 -
Flags: approval1.9.1.2?
Attachment #386487 -
Flags: approval1.9.0.12?
Comment 22•15 years ago
|
||
Comment on attachment 386487 [details] [diff] [review] patch Approved for 1.9.1.2. a=ss for release-drivers (We'll be back to approve for 1.9.0.13.)
Attachment #386487 -
Flags: approval1.9.1.2?
Attachment #386487 -
Flags: approval1.9.1.2+
Attachment #386487 -
Flags: approval1.9.0.13?
Attachment #386487 -
Flags: approval1.9.0.12?
Assignee | ||
Comment 23•15 years ago
|
||
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/3e2dbb587075
Comment 24•15 years ago
|
||
Comment on attachment 386487 [details] [diff] [review] patch Approved for 1.9.0.13, a=dveditz for release-drivers
Attachment #386487 -
Flags: approval1.9.0.13? → approval1.9.0.13+
Comment 25•15 years ago
|
||
Verified fixed on 1.9.1 with builds on all platforms like Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.2pre) Gecko/20090729 Shiretoko/3.5.2pre (.NET CLR 3.5.30729) ID:20090729045022
Keywords: verified1.9.1
Whiteboard: [sg:critical?][1.9.1.2+] → [sg:critical?]
Assignee | ||
Comment 26•15 years ago
|
||
Checking in layout/xul/base/src/nsScrollBoxFrame.cpp; /cvsroot/mozilla/layout/xul/base/src/nsScrollBoxFrame.cpp,v <-- nsScrollBoxFrame.cpp new revision: 1.78; previous revision: 1.77 done
Keywords: fixed1.9.0.14
Comment 27•15 years ago
|
||
Verified on 1.9.0 with builds on Windows and OS X like: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.14pre) Gecko/2009081004 GranParadiso/3.0.14pre ID:2009081004
Keywords: fixed1.9.0.14 → verified1.9.0.14
Updated•15 years ago
|
Group: core-security
Updated•13 years ago
|
Crash Signature: [@ nsButtonBoxFrame::DoMouseClick]
Comment 28•6 years ago
|
||
Moving to Core:XUL per https://bugzilla.mozilla.org/show_bug.cgi?id=1455336
Component: XP Toolkit/Widgets: XUL → XUL
You need to log in
before you can comment on or make changes to this bug.
Description
•