Firefox crashes when click the spinarrow button to increment and then decrement [@ nsButtonBoxFrame::DoMouseClick]

VERIFIED FIXED in mozilla1.9.2a1



10 years ago
10 months ago


(Reporter: htoshi73, Assigned: smaug)


(4 keywords)

1.9.0 Branch
crash, testcase, verified1.9.0.14, verified1.9.1
Bug Flags:
wanted1.9.1.x +
blocking1.9.0.14 +
wanted1.9.0.x +
in-testsuite ?

Firefox Tracking Flags

(blocking1.9.1 .2+, status1.9.1 .2-fixed)


(Whiteboard: [sg:critical?], crash signature)


(2 attachments)



10 years ago
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: 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.

Comment 1

10 years ago

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
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


10 years ago
Duplicate of this bug: 496190
Severity: normal → critical

Comment 3

10 years ago
Same in Firefox 3.0.11 (the new official version):

Comment 4

10 years ago
New Version, same problem (v3.5) and still unconfirmed :/
Report for v3.5
Confirming. qawanted: can someone confirm this?
Ever confirmed: true
Flags: wanted1.9.1.x?
Flags: wanted1.9.0.x?
Keywords: qawanted
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:

Comment 7

10 years ago
I can click the arrows (from the cache) down from 1 to 0 and than it crash.

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

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

10 years ago
I found the failure...
With Noia2.0 (extreme) Theme = Crash
With normal standard Theme = no crash

Omg ^^
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
Created attachment 386470 [details]

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
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;
146	  // Execute the oncommand event handler.
(gdb) p mContent
$1 = (class nsIContent *) 0xdddddddd
(gdb) p *mContent
Cannot access memory at address 0xdddddddd
Olli, would you have time to have a look at this?
Keywords: qawanted
Flags: blocking1.9.1.1?
Flags: blocking1.9.0.13?
Assignee: nobody → Olli.Pettay
Group: core-security
Can't reproduce on linux. Testing now on OSX.
Created attachment 386487 [details] [diff] [review]

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+
Last Resolved: 10 years ago
Resolution: --- → FIXED
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?]
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
Flags: in-testsuite?
Keywords: testcase-wanted → testcase
Target Milestone: --- → mozilla1.9.2a1
Flags: wanted1.9.1.x?
Flags: wanted1.9.1.x+
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.13? → blocking1.9.0.13+
Not for, but we'll block on this for
Flags: blocking1.9.1.1?
Whiteboard: [sg:critical?] → [sg:critical?][]
blocking1.9.1: --- → .2+
status1.9.1: --- → wanted
Is this ready to land? If so, can we get it on mozilla-1.9.1?
Comment on attachment 386487 [details] [diff] [review]

Applies to branches with some fuzz.
Attachment #386487 - Flags: approval1.9.1.2?
Attachment #386487 - Flags: approval1.9.0.12?
Comment on attachment 386487 [details] [diff] [review]

Approved for a=ss for release-drivers

(We'll be back to approve for
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?
Comment on attachment 386487 [details] [diff] [review]

Approved for, a=dveditz for release-drivers
Attachment #386487 - Flags: approval1.9.0.13? → approval1.9.0.13+
Verified fixed on 1.9.1 with builds on all platforms like Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20090729 Shiretoko/3.5.2pre (.NET CLR 3.5.30729) ID:20090729045022
Keywords: verified1.9.1
Whiteboard: [sg:critical?][] → [sg:critical?]
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
Keywords: fixed1.9.0.14
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: Gecko/2009081004 GranParadiso/3.0.14pre ID:2009081004
Keywords: fixed1.9.0.14 → verified1.9.0.14
Group: core-security
Crash Signature: [@ nsButtonBoxFrame::DoMouseClick]
Moving to Core:XUL per
Component: XP Toolkit/Widgets: XUL → XUL
You need to log in before you can comment on or make changes to this bug.