Closed
Bug 669084
Opened 14 years ago
Closed 14 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•14 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•14 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: 14 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 5•14 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•14 years ago
|
||
Because then we enter printing and the added check cancels the loop.
Comment 7•14 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•14 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
•