Closed
Bug 669084
Opened 13 years ago
Closed 13 years ago
Crash [@ nsPrintEngine::DoCommonPrint][@ nsDeviceContext::GetDeviceSurfaceDimensions] with onbeforeprint="window.print"
Categories
(Core :: Printing: Output, defect)
Tracking
()
VERIFIED
FIXED
mozilla8
Tracking | Status | |
---|---|---|
firefox5 | --- | unaffected |
firefox6 | --- | affected |
firefox7 | --- | affected |
firefox8 | --- | fixed |
status2.0 | --- | unaffected |
status1.9.2 | --- | unaffected |
status1.9.1 | --- | unaffected |
People
(Reporter: martijn.martijn, Assigned: smaug)
References
Details
(Keywords: crash, regression, testcase, Whiteboard: [sg:dos] null deref)
Crash Data
Attachments
(2 files)
37 bytes,
text/html
|
Details | |
1.43 KB,
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
See testcase, when trying to print or print preview that page, pressing cancel will open a new print dialog (annoying). When you press "Ok", Mozilla crashes. I guess a regression from bug 307258. https://crash-stats.mozilla.com/report/index/bp-eae7ca28-6d3a-4b37-ad70-c62072110703 0 xul.dll nsDeviceContext::GetDeviceSurfaceDimensions gfx/src/nsDeviceContext.cpp:515 1 xul.dll nsPrintEngine::ReflowPrintObject layout/printing/nsPrintEngine.cpp:1914 2 xul.dll nsPrintEngine::ReflowDocList layout/printing/nsPrintEngine.cpp:1860 3 xul.dll nsPrintEngine::SetupToPrintContent layout/printing/nsPrintEngine.cpp:1669 4 xul.dll nsPrintEngine::DocumentReadyForPrinting layout/printing/nsPrintEngine.cpp:1501 5 xul.dll nsPrintEngine::Observe layout/printing/nsPrintEngine.cpp:3344 6 xul.dll nsPrintProgress::DoneIniting embedding/components/printingui/src/win/nsPrintProgress.cpp:222 7 xul.dll NS_InvokeByIndex_P xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:102 8 xul.dll XPC_WN_CallMethod js/src/xpconnect/src/xpcwrappednativejsops.cpp:1592 9 mozjs.dll js::Invoke js/src/jsinterp.cpp:656 10 mozjs.dll js::Interpret js/src/jsinterp.cpp:4085 11 mozjs.dll js::RunScript js/src/jsinterp.cpp:613 12 mozjs.dll js::Invoke js/src/jsinterp.cpp:686 https://crash-stats.mozilla.com/report/index/493aa9a8-b55d-4079-9a56-f393a2110703 0 xul.dll nsPrintEngine::DoCommonPrint layout/printing/nsPrintEngine.cpp:654 1 xul.dll nsPrintEngine::CommonPrint layout/printing/nsPrintEngine.cpp:444 2 xul.dll nsPrintEngine::Print layout/printing/nsPrintEngine.cpp:759 3 xul.dll DocumentViewerImpl::Print layout/base/nsDocumentViewer.cpp:3679 4 xul.dll nsGlobalWindow::Print dom/base/nsGlobalWindow.cpp:5175 5 xul.dll nsGlobalWindow::Print dom/base/nsGlobalWindow.cpp:5140 6 xul.dll NS_InvokeByIndex_P xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:102 7 xul.dll XPC_WN_CallMethod js/src/xpconnect/src/xpcwrappednativejsops.cpp:1592 8 mozjs.dll CallCompiler::generateNativeStub js/src/methodjit/MonoIC.cpp:813 9 mozjs.dll js::mjit::ic::NativeCall js/src/methodjit/MonoIC.cpp:1031 10 mozjs.dll js::mjit::EnterMethodJIT js/src/methodjit/MethodJIT.cpp:686 11 mozjs.dll js::mjit::JaegerShot js/src/methodjit/MethodJIT.cpp:733 12 mozjs.dll js::RunScript js/src/jsinterp.cpp:610 13 mozjs.dll js::Invoke js/src/jsinterp.cpp:686
Assignee | ||
Comment 2•13 years ago
|
||
Let's fix this in the simple way.
Comment on attachment 543905 [details] [diff] [review] patch Review of attachment 543905 [details] [diff] [review]: -----------------------------------------------------------------
Attachment #543905 -
Flags: review?(roc) → review+
Assignee | ||
Comment 4•13 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/6f1642e856e9 The patch fixes the crash, but the loop - if cancel is pressed - is of course still there. That is just a loop in the js code.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 5•13 years ago
|
||
Verified fixed. Thanks for fixing. One question, though. I don't get a loop when I press Ok for printing? Why is that?
Status: RESOLVED → VERIFIED
Assignee | ||
Comment 6•13 years ago
|
||
Because then we enter printing and the added check cancels the loop.
Comment 7•13 years ago
|
||
The stack from comment 0 is a null deref. Are there cases where it won't be? If this isn't a security problem we should un-hide the bug. If it is we need to decide whether it's worth fixing for Firefox 6 and 7. Given the user-interaction required this is probably sg:moderate at worst; a null deref would be sg:dos.
status1.9.1:
--- → unaffected
status1.9.2:
--- → unaffected
status2.0:
--- → unaffected
status-firefox5:
--- → unaffected
status-firefox6:
--- → affected
status-firefox7:
--- → affected
status-firefox8:
--- → fixed
Whiteboard: null deref?
Target Milestone: --- → mozilla8
Updated•13 years ago
|
Group: core-security
Whiteboard: null deref? → [sg:dos] null deref
You need to log in
before you can comment on or make changes to this bug.
Description
•