Closed
Bug 172921
Opened 22 years ago
Closed 21 years ago
Window close, without printing.
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
FIXED
mozilla1.6alpha
People
(Reporter: email, Assigned: bryner)
References
()
Details
(Keywords: testcase)
Attachments
(2 files)
|
148 bytes,
text/html
|
Details | |
|
3.64 KB,
patch
|
john
:
review+
dbaron
:
superreview+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910
In my application, I'm using trick:
<body onLoad="window.print(); window.self.close();">
To print reports. It works well with my debian mozilla 1.0
But with mozilla 1.2a (binary from your site) running linux debian woody 3.0
(and on windows xp with same mozilla) browser close new window without printing
it or even showing print dialog.
Reproducible: Always
Steps to Reproduce:
1. create page with <body onLoad="window.print(); window.self.close();">
2. load this page
3. is your printer working or any dialog appears? ;)
Actual Results:
New window closes.
Expected Results:
Print window (with print dialog), then close it.
|
||
Comment 1•22 years ago
|
||
browser not engine ==> DOM 0
Mozilla 1.0 and 1.0.1 work
Mozilla 1.1alpha crashes when you hit print
Mozilla 1.1beta - trunk 20021004 closes the window, doesn't open the print dialog
marking NEW
Assignee: rogerl → jst
Status: UNCONFIRMED → NEW
Component: JavaScript Engine → DOM Level 0
Ever confirmed: true
QA Contact: pschwartau → desale
|
|
||
Comment 2•22 years ago
|
||
|
|
||
Comment 3•22 years ago
|
||
*** Bug 175604 has been marked as a duplicate of this bug. ***
|
||
Comment 4•22 years ago
|
||
Similar things happen with Mozilla 1.1 (Win98)
Situation seems as follows:
window.print() does not suspend JavaScript execution (possibly ok), but it
doesn't have any information of it's sorrunding page.
window.setTimeout('history.go(-2);',5000) showed up, that the page go(-2) is
printed, if you wait too long before submitting the print dialogue.
(I used it to print a partly filled out form with a special print layout and go
back to the form, I've used history.back, but go(-2) is better for testing)
Behavior of other browsers:
No matter when the print dialogue is submitted, the print layout is printed out
correctly (either it was displayed in background until "OK" or history.back()
was executed, but window.print knew its page)
Version String "Mozilla/5.0 (Windows; U; Win98; de-AT; rv:1.1) Gecko/20020826"
|
Assignee | |
Comment 6•22 years ago
|
||
*** Bug 180114 has been marked as a duplicate of this bug. ***
|
||
Comment 7•22 years ago
|
||
Testcase uploaded.
Click on Drucken after the page loads.
Note that this happens about 80-90% of the time.
Sometimes it works.
|
|
Assignee | |
Comment 8•22 years ago
|
||
After some investigation, I think we should probably just keep the window open
until the print operation completes. If we close the window while printing,
destroying the toplevel window tears down all of the presshells... which turns
out to be bad.
So, the way I wanted to do that was to use the DOMWindowClose event that we're
already firing to allow the document viewer to block window close if printing
is happening. Unfortunately, I don't think we can guarantee the firing order
of that listener and the listener installed by <tabbrowser>... and if
tabbrowser's listener were to remove the tab we'd be equally screwed.
Given that, I came up with this patch. It's not pretty. I'm open to
suggestions.
|
|
Assignee | |
Comment 9•22 years ago
|
||
Comment on attachment 130380 [details] [diff] [review]
one way to fix this
John, you're somewhat familiar with the printing code, right? Does this look
ok to you, or do you see a better way to handle this?
Attachment #130380 -
Flags: review?(john)
|
||
Comment 10•21 years ago
|
||
Comment on attachment 130380 [details] [diff] [review]
one way to fix this
This is fine, but I am a little queasy about the names here
("RequestWindowClose" specifically), but I can't think of a better one that
isn't really long.
I don't know much about the callers of GlobalWindowImpl::Close() either and
whether they require the window to be closed, but I bet that is OK.
Attachment #130380 -
Flags: review?(john) → review+
|
|
Assignee | |
Updated•21 years ago
|
Attachment #130380 -
Flags: superreview?(dbaron)
|
|
Assignee | |
Updated•21 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.6alpha
Comment on attachment 130380 [details] [diff] [review]
one way to fix this
This makes me quite nervous. I'll try to look at it more closely sometime, but
I think I'll want to spend a bit of time looking at it, so it may be a while.
Or is there a reason I should do it sooner rather than later?
Comment on attachment 130380 [details] [diff] [review]
one way to fix this
>@@ -3815,7 +3832,12 @@ DocumentViewerImpl::OnDonePrinting()
> }
>
> // We are done printing, now cleanup
>- if (mClosingWhilePrinting) {
>+ if (mDeferredWindowClose) {
>+ nsCOMPtr<nsIDOMWindowInternal> win = do_GetInterface(mContainer);
>+ if (win)
>+ win->Close();
>+ mDeferredWindowClose = PR_FALSE;
>+ } else if (mClosingWhilePrinting) {
> if (mDocument) {
> mDocument->SetScriptGlobalObject(nsnull);
> mDocument = nsnull;
I'd be a little happier if you set mDeferredWindowClose to false before calling
Close here (in case there could somehow be an additional print job), but other
than that sr=dbaron.
Attachment #130380 -
Flags: superreview?(dbaron) → superreview+
|
|
Assignee | |
Comment 14•21 years ago
|
||
checked in.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•