1251028 - window.open(URL).print() ends up printing about:blank, instead of the opened URL

Status: NEW

(Core :: DOM: Core & HTML, defect, P3)

Description

[Kevin]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36

Steps to reproduce:

Trying to print
<a href="javascript:var page = window.open('/node/669/colorbox'); page.print();">Print this Coupon</a>

https://www.az.aaa.com/automotive/auto-repair-coupons%20

you may need 85209 for zip code validation


Actual results:

printed out blank page


Expected results:

printed the coupon

Comment 1

[Kevin]

used windows 7, firefox 32.0.2

Comment 2

[Loic]

https://www.az.aaa.com/node/1179/colorbox

It's because when you click on the "Print" link, the website loads a blank page before loading the coupon. You can see that because the print output has "about:blank" as title, not "https://www.az.aaa.com/node/1179/colorbox".

If you use the shortkey Ctrl+P to print, it's fine (or from the Firefox menu).

Comment 3

[Daniel Holbert [:dholbert]]

(In reply to Loic from comment #2)
> https://www.az.aaa.com/node/1179/colorbox
> 
> It's because when you click on the "Print" link, the website loads a blank
> page before loading the coupon.

(Technically, Firefox loads a blank page [as it does initially for all new tabs/windows] and then redirects to the coupon.)

Looks like the problem here is that window.print() doesn't wait until the page is loaded in Firefox, whereas it does in Chrome.  Not sure if that's specced anywhere, but it seems like a reasonable behavior, and apparently some sites (like this AAA site) depend on it.

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: (helper for testcase)

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Comment 6

[Daniel Holbert [:dholbert]]

This bug really belongs in DOM, I think (or wherever the "window.print()" API is implemented).

The Print Output here is correct for the document that we're actually printing (about:blank) -- the problem is that we're triggering the print operation too early.

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (one-liner)

(Here's a testcase with the JS condensed slightly, to just a single  window.open(URL).print() statement, matching this bug's summary.)

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: printed output from testcase 1 or testcase 2 (it's literally about:blank)

Comment 9

[Daniel Holbert [:dholbert]]

I just tried 'testcase 2' on Chrome 50 (on Linux), Edge 13 (on Win10) and Safari 9 (on OS X El Capitan).

They all seem to get this right -- they show a preview of the correct document (rather than a blank page) inside of their print dialog.

So, we seem to be the only browser that gets this wrong & prints a blank page.

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

We do have some code in DocumentViewer and/or nsDocShell to deal with cases when printing is tried to be done during loading. But obviously that can't kick in here, since the about:blank has already been loaded. Need to tweak something a bit.

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

What happens in other browsers when window.open is used to open cross-domain url.
The initial about:blank is in the same domain as the caller, but would print() then affect to the cross-domain page?

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

Looks like at least Chrome doesn't print cross-domain.

Comment 13

[Daniel Holbert [:dholbert]]

Attachment: testcase 3: cross-domain print() call (probably should not work)

Comment 14

[Daniel Holbert [:dholbert]]

On testcase 3 (cross-domain), Edge 13 & Safari 9 & Chrome 50 all simply open a new tab, and do not pop a print dialog.

Firefox (nightly 47) does pop up a print dialog after opening a new tab, though it only prints about:blank as with earlier testcases.

Comment 15

[Olli Pettay [:smaug][[e-mail]]]

Ok, thanks.
The relevant code is around http://mxr.mozilla.org/mozilla-central/source/layout/base/nsDocumentViewer.cpp?rev=5b9d0ccdf0dd#3625
Need to check somehow whether we're in process to load a new page I guess.


Hmm, another case to test. What happens if you open first a same origin page A (wait it to be fully loaded), then start loading same origin page B and immediately after that call print();

Comment 16

[Olli Pettay [:smaug][[e-mail]]]

So the fix for this is to not print the initial about:blank document if a new page is being loaded for override it, and copy the mPrintIsPending flag state from the about:blank content viewer to the newly created content viewer.

Comment 17

[Kevin]

Thanks for looking at this, would you happen to have an update?

Comment 18

[Olli Pettay [:smaug][[e-mail]]]

Sorry, I haven't had time to look at this more. I was hoping someone from tpe-dom team might want to take a look. This could be a fun bug to fix (at least what I might call fun :) ).

Comment 19

[Andrew Overholt [:overholt]]

I don't know any more than Olli but I'll ask around to see if someone wants to fix it.

Comment 20

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

Jocelyn thinks this is fun, too. ;) She is working on another bug but will be switching to this after that. Thanks, Jocelyn!

Comment 21

[Jocelyn Liu [:jocelyn] [:joliu]]

Done some experiments on docShell.mBusyFlags today in the print function.
http://mxr.mozilla.org/mozilla-central/source/layout/base/nsDocumentViewer.cpp?rev=5b9d0ccdf0dd#3629

case 1) click in test case2: mBusyFlags = 3 (BUSY and BEFORE_PAGE_LOAD)
case 2) use window.open() to open a zip file and call print(): mBusyFlags = 0
case 3) open a new tab and print the about:blank directly: mBusyFlags = 0
All three cases print about:blank at this moment.

Will continue to look into this issue tomorrow.
Need to look more codes around to see if we could use BEFORE_PAGE_LOAD to decide to print the page later.
Also need to see how to prevent printing in case 2.

Comment 22

[Jocelyn Liu [:jocelyn] [:joliu]]

Attachment: [WIP] Bug 1251028 Postpone printing operation if docshell is busy.

It's just an experimental WIP patch, probably terrible.

Tweak the condition in nsDocumentViewer::Print() and queue print operations whenever docshell's mBusyFlags & BUSY_FLAGS_BUSY is true.
Then copy the printIsPending flag to new content viewer.

Test Result:
 - attached testcase 1-3: Print the actual page, maybe we shouldn't print the page for cross origin cases, might need to open a follow up bug for fixing this.
 - run window.open("xxx.zip").print() in web console: no print window prompted.

My main concern for this approach is, it seems to me that Print() might possibly be called when we haven't start to load the actual page (before https://dxr.mozilla.org/mozilla-beta/source/docshell/base/nsDocShell.cpp#7297 is called), this approach won't work for this case.

Olly, could you give me some hints here?
Is my concern reasonable?
How does this approach look so far, does this direction looks reasonable to you?

Thanks,
Jocelyn

Comment 23

[Jocelyn Liu [:jocelyn] [:joliu]]

Comment on attachment 8751266 [details] [diff] [review]
[WIP] Bug 1251028 Postpone printing operation if docshell is busy.

It turned out that if we open a complex website (ex: https://yahoo.com), this WIP patch will copy the printIsPending flag for many subresource requests and pop many print dialog for each one...
I guess we should check if the new viewer is the target one before copying mprintIsPending flag.

Comment 24

[Jocelyn Liu [:jocelyn] [:joliu]]

Attachment: [WIP-v2] Bug 1251028 Postpone printing operation if docshell is busy.

This revision fixes the multiple print dialogs for opening webpages with sub-resource like yahoo.com (Comment 23) by only copying mIsPrintPending when SetupNewViewer is called on root docshell.

As I mentioned in Comment 22, my concern is that IMO Print() might possibly be called when we haven't start to load the actual page (before https://dxr.mozilla.org/mozilla-beta/source/docshell/base/nsDocShell.cpp#7297 is called), this approach won't work for this case.

Olly, could you give me some feedback here?
Is my concern reasonable?
How does this approach look so far, does this direction looks reasonable to you?

Note that this revision is still an experimental WIP for one possible direction, for instance, mPrintCachedSettings is not copied yet.

Thanks,
Jocelyn

Comment 25

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8752685 [details] [diff] [review]
[WIP-v2] Bug 1251028 Postpone printing operation if docshell is busy.

Yeah, I think something like this should work.
Perhaps we wouldn't need to check root docshell, but parent (same type) docshell should be enough, right?

And I think case 1 is the one to fix, possibly also case 2.

I'm not sure what case 3) is about. Is it
var w = window.open(); // no params
w.print();

Comment 26

[Olli Pettay [:smaug][[e-mail]]]

Jocelyn, could you explain what you mean with case 3.
If it is about 
var w = window.open(); // no params
w.print();
then we should print about:blank, right?

and case (1) is the most important one to fix.
case (2) is probably very rare, and definitely an edge case.

Comment 27

[Jocelyn Liu [:jocelyn] [:joliu]]

(In reply to Olli Pettay [:smaug] from comment #26)
> Jocelyn, could you explain what you mean with case 3.
> If it is about 
> var w = window.open(); // no params
> w.print();
> then we should print about:blank, right?
> 
> and case (1) is the most important one to fix.
> case (2) is probably very rare, and definitely an edge case.

Hi Olly,

Yes, sorry for not making that clear.
In this case the busy flag would be 0, so print will be processed right away.

The result of WIP2 for cases in Comment 21 looks fine from my local end.
1) open html: print the actual page
2) open zip: won't prompt print dialog
3) window.open().print(): print about:blank

What I was worried and wasn't sure about is that in case 1, we might possibly call into Print() before the actual page hasn't been start to load at https://dxr.mozilla.org/mozilla-beta/source/docshell/base/nsDocShell.cpp#7297.
I'll have to dig more about this and update later.

Comment 28

[Jocelyn Liu [:jocelyn] [:joliu]]

Attachment: [WIP-v3] Bug 1251028 Postpone printing operation if docshell is busy.

- copy cachedPrintSettings and cachedWebProgressListener

Comment 29

[sebastiancrs97]

Hello, I read the entire forum and I have the same case. I have a pdf and I am opening it in a new window and I want the option to print to also open. I am doing this in mozilla firefox and with javascript

Comment 30

[Edgar Chen [:edgar]]

Not actively working on this.