Closed Bug 301560 Opened 19 years ago Closed 17 years ago

print() from modal dialog crashes browser [@ nsPrintEngine::ShowPrintProgress]

Categories

(Core :: Printing: Output, defect, P3)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: bugs, Assigned: smaug)

References

Details

(Keywords: crash, testcase)

Crash Data

Attachments

(4 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

print() crashes browser from modal dialogs.

Reproducible: Always

Steps to Reproduce:
1.open javascript console
2.type openDialog("http://www.krickelkrackel.de/testing/print.html","","modal")
3."evaluate"
4.say "OK" to print the document
5.the progress-window will NOT disappear.
6.close the progress-window -> crash
7.try the same with
openDialog("http://www.krickelkrackel.de/testing/print.html") -> no crash



Expected Results:  
no crash

Tested with WinXP SP2, but the browser will also crash under Fedora Core 3.
OS: Windows XP → All
I don't see a crash, trunk or branch, only an uncloseable Javascript Console.
I get a crash following those steps, using 20050720 trunk build:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB7697430H

nsPrintEngine::ShowPrintProgress 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/printing/nsPrintEngine.cpp,
line 1663]
nsPrintEngine::Print 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/printing/nsPrintEngine.cpp,
line 960]
DocumentViewerImpl::Print 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsDocumentViewer.cpp,
line 3337]
DocumentViewerImpl::LoadComplete 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsDocumentViewer.cpp,
line 1061]
nsDocShell::EndPageLoad 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/docshell/base/nsDocShell.cpp,
line 4644]
nsWebShell::EndPageLoad 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/docshell/base/nsWebShell.cpp,
line 667]
nsDocShell::OnStateChange 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/docshell/base/nsDocShell.cpp,
line 4570]
nsDocLoader::FireOnStateChange 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/uriloader/base/nsDocLoader.cpp,
line 1210]
nsDocLoader::doStopDocumentLoad 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/uriloader/base/nsDocLoader.cpp,
line 844]
nsDocLoader::OnStopRequest 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/uriloader/base/nsDocLoader.cpp,
line 665]
nsLoadGroup::RemoveRequest 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/netwerk/base/src/nsLoadGroup.cpp,
line 732]
PresShell::RemoveDummyLayoutRequest 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp,
line 7095]
DummyLayoutRequestEvent::HandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp,
line 6995]
SHELL32.dll + 0x520c24 (0x778b0c24)
Assignee: nobody → printing
Status: UNCONFIRMED → NEW
Component: General → Printing
Ever confirmed: true
Keywords: crash, testcase
Product: Firefox → Core
QA Contact: general
Version: unspecified → Trunk
Summary: print() from modal dialog crashes browser → print() from modal dialog crashes browser [@ nsPrintEngine::ShowPrintProgress]
I still crash with current trunk build.
This is what I get when stepping through the code.
It seems to recurse in:
PL_DHashStringKey (table=0x3fc9a8, key=0x5c090d0)
    at c:/mozilla/mozilla/xpcom/build/pldhash.c:104
104         h = 0;
(gdb) step
105         for (s = key; *s != '\0'; s++)
(gdb) step
106             h = (h >> (PL_DHASH_BITS - 4)) ^ (h << 4) ^ *s;
(gdb) step
105         for (s = key; *s != '\0'; s++)
(gdb) step
106             h = (h >> (PL_DHASH_BITS - 4)) ^ (h << 4) ^ *s;
(gdb) step
105         for (s = key; *s != '\0'; s++)
(gdb) step
106             h = (h >> (PL_DHASH_BITS - 4)) ^ (h << 4) ^ *s;

etc...
In any case, this would need to be retested once bug 326273 lands, I suspect...
Depends on: nsIThreadManager
Well, I have tested this with one of Darin's threadmanager builds, but in there, it still crashes.
Still crashing with

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070123 Minefield/3.0a2pre
Hmm, for me this is now worksforme, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070123 Minefield/3.0a2pre

Do you have a talkback ID of the crash?
(In reply to comment #9)
> Hmm, for me this is now worksforme, using:
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070123
> Minefield/3.0a2pre
> 
> Do you have a talkback ID of the crash?
>
 
TB28698455
Using a zip build fróm /pub/mozilla.org/firefox/nightly/latest-trunk
I have attempted to print from a modal dialog and it crashes on openSUSE and WinXP SP2 Home Edition.

Thanks,
Greg
(In reply to comment #11)
> I have attempted to print from a modal dialog and it crashes on openSUSE and
> WinXP SP2 Home Edition.

Is this a dialog you created yourself, or a toolkit window? And in a mailing list description, you say it only crashes when the dialog closes. Does it auto-close or do you have to click Ok or something similar?
It was a dialog I created myself. Also, it crashed when I close the print dialog by clicking the "X" in the top right of the print dialog.

Thank you and God Bless <><
Greg
By "print dialog" I am referring to the Mozilla dialog that appears once you hit the print button on the OS's printer select dialog. The dialog that I'm closing is not anything I created. So, it order to view the code for closing dialog, you would have to look at Mozilla code instead of my code.

Thank you,
Greg Marine
crashes are bad...
Flags: blocking1.9? → blocking1.9+
So here's what's happening:

 	gklayout.dll!nsPrintEngine::Destroy()  Line 258	C++
 	gklayout.dll!DocumentViewerImpl::OnDonePrinting()  Line 3992	C++
 	gklayout.dll!nsPrintCompletionEvent::Run()  Line 3114	C++
 	xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=0x00000001, int * result=0x0012cc24)  Line 491	C++
 	xpcom_core.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x0149c360, int mayWait=0x00000001)  Line 227 + 0x16 bytes	C++
 	appshell.dll!nsXULWindow::ShowModal()  Line 398 + 0xc bytes	C++
 	appshell.dll!nsContentTreeOwner::ShowAsModal()  Line 522	C++
 	embedcomponents.dll!nsWindowWatcher::OpenWindowJSInternal(nsIDOMWindow * aParent=0x071ef100, const char * aUrl=0x07260e20, const char * aName=0x0012d340, const char * aFeatures=0x0012d398, int aDialog=0x00000001, nsIArray * argv=0x060505f0, int aCalledFromJS=0x00000000, nsIDOMWindow * * _retval=0x0012d3f4)  Line 945	C++
 	embedcomponents.dll!nsWindowWatcher::OpenWindow(nsIDOMWindow * aParent=0x071ef100, const char * aUrl=0x07260e20, const char * aName=0x0012d340, const char * aFeatures=0x0012d398, nsISupports * aArguments=0x0605e140, nsIDOMWindow * * _retval=0x0012d3f4)  Line 418 + 0x2b bytes	C++
 	gklayout.dll!nsGlobalWindow::OpenInternal(const nsAString_internal & aUrl={...}, const nsAString_internal & aName={...}, const nsAString_internal & aOptions={...}, int aDialog=0x00000001, int aContentModal=0x00000000, int aCalledNoScript=0x00000001, int aDoJSFixups=0x00000000, nsIArray * argv=0x00000000, nsISupports * aExtraArgument=0x0605e140, nsIPrincipal * aCalleePrincipal=0x07238418, JSContext * aJSCallerContext=0x00000000, nsIDOMWindow * * aReturn=0x0012d538)  Line 6594 + 0x62 bytes	C++
 	gklayout.dll!nsGlobalWindow::OpenDialog(const nsAString_internal & aUrl={...}, const nsAString_internal & aName={...}, const nsAString_internal & aOptions={...}, nsISupports * aExtraArgument=0x0605e140, nsIDOMWindow * * _retval=0x0012d538)  Line 4659	C++
embedcomponents.dll!nsPrintProgress::OpenProgressDialog(nsIDOMWindowInternal * parent=0x071ef100, const char * dialogURL=0x02b93a08, nsISupports * parameters=0x07242840, nsIObserver * openDialogObserver=0x07239088, int * notifyOnOpen=0x0012d730)  Line 142 + 0x62 bytes	C++
 	embedcomponents.dll!nsPrintingPromptService::ShowProgress(nsIDOMWindow * parent=0x071ef100, nsIWebBrowserPrint * webBrowserPrint=0x07238014, nsIPrintSettings * printSettings=0x072424c0, nsIObserver * openDialogObserver=0x07239088, int isForPrinting=0x00000001, nsIWebProgressListener * * webProgressListener=0x0012d5f8, nsIPrintProgressParams * * printProgressParams=0x071ed538, int * notifyOnOpen=0x0012d730)  Line 247	C++
>	gklayout.dll!nsPrintEngine::ShowPrintProgress(int aIsForPrinting=0x00000001, int & aDoNotify=0x00000001)  Line 974 + 0x77 bytes	C++
 	gklayout.dll!nsPrintEngine::DoCommonPrint(int aIsPrintPreview=0x00000000, nsIPrintSettings * aPrintSettings=0x072424c0, nsIWebProgressListener * aWebProgressListener=0x00000000)  Line 696	C++
 	gklayout.dll!nsPrintEngine::CommonPrint(int aIsPrintPreview=0x00000000, nsIPrintSettings * aPrintSettings=0x072424c0, nsIWebProgressListener * aWebProgressListener=0x00000000)  Line 417 + 0x14 bytes	C++
 	gklayout.dll!nsPrintEngine::Print(nsIPrintSettings * aPrintSettings=0x072424c0, nsIWebProgressListener * aWebProgressListener=0x00000000)  Line 713	C++

Basically, we're displaying the print progress dialog, then processing events and getting a printing done event ,at which point the code unconditionally destroyes the printengine -- which is being referenced in nsPrintingPromptService::ShowProgress . 

Cc'ing Eli here, as dbaron says he knows this code better than most.  Any idea what's going on here?  In DocumentViewerImpl::OnDonePrinting there's a GetIsPrintPreview() thing that causes us to avoid calling Destroy() on mPrintEngine -- should there be another check?  What should the other check do?

How does this work when a modal dialog isn't involved?
So the thing is that nsPrintProgress::OpenProgressDialog is just opening a window, parented to the window being printed.

When that happens, and the parent window is modal, we make the child window modal.  Which means that instead of opening it up under nsPrintEngine::DoCommonPrint, setting up the remaining printing stuff, and returning, we put up the dialog and block.  This is why the progress window just sits there.

Now the thing is that when the print progress window finishes setting itself up (usually asynchronously), it calls nsPrintProgress::DoneIniting, which calls nsPrintEngine::Observe and kicks off the printing process and in particular sets up the nsPagePrintTimer.  This timer happily fires every so often, and eventually prints the last page, and then calls DonePrintingPages(), which posts the nsPrintCompletionEvent.  Then we process that event and get the stack that vlad just posted.

I don't see an obvious way to make this stuff _work_ to print modal windows.  But one obvious way to not crash would be to make the Observe() call set some member to an error and throw if we haven't returned from ShowPrintProgress() yet.

If we can detect a modal window, perhaps we could just skip the progress dialog thing if the parent is modal and print without showing progress.  That seems like the best option.  I'm not sure we can detect that, however.
Priority: -- → P3
Assignee: printing → nobody
QA Contact: printing
I take this for now. At least we should fix the possible crash.
Assignee: nobody → Olli.Pettay
Attached patch possible patchSplinter Review
Bz, asking review from you because this is based on your idea.
Just don't show the progress dialog if printing something modal.
Attachment #288053 - Flags: superreview?(bzbarsky)
Attachment #288053 - Flags: review?(bzbarsky)
Comment on attachment 288053 [details] [diff] [review]
possible patch

r+sr=bzbarsky if you reverse all those checks.  That is, only show the dialog if you are absolutely sure the window is not modal.
Attachment #288053 - Flags: superreview?(bzbarsky)
Attachment #288053 - Flags: superreview+
Attachment #288053 - Flags: review?(bzbarsky)
Attachment #288053 - Flags: review+
Attached patch checks reversedSplinter Review
Using the same coding style as in the method. if (!expr) return;
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Verified fixed, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007111404 Minefield/3.0b2pre
Status: RESOLVED → VERIFIED
Crash Signature: [@ nsPrintEngine::ShowPrintProgress]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: