Open Bug 1214805 Opened 6 years ago Updated 4 years ago

Navigation not working while printing (onafterprint)

Categories

(Core :: DOM: Navigation, defect)

41 Branch
defect
Not set
normal

Tracking

()

REOPENED

People

(Reporter: mozilla, Assigned: smaug)

References

Details

(Keywords: regression)

Attachments

(4 files)

Attached file test.html
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36

Steps to reproduce:

When printing a document, the events triggered in onafterprint are not working.

See attached HTML file.  

I tried on Linux (v40) and OSX (v40 and v44), same result.

This is happening regardless of the print.always_print_silent config flag.


Actual results:

When calling window.print(), then if I choose to print, the click event triggered in onafterprint is discarded, without any error message.
If I choose not to print (i.e. cancel the print dialog), then the click event triggered in onafterprint is processed as it should.


Expected results:

- Both actually printing the document and cancelling the print dialog must have the same behaviour.
- There should be a way to detect when the browser will be available again to process events after printing, or else the event should be delayed.
I stand corrected, I meant v41 instead of v44 in the description above.
Version: 44 Branch → 41 Branch
I can reproduce this bug on the newest build of nightly and FF 42.0.
Status: UNCONFIRMED → NEW
Component: Untriaged → Printing: Output
Ever confirmed: true
Product: Firefox → Core
See Also: → 1298942
this should be Document Navigation issue.
click event is prevented because it's a page load.

If I use this input instead, the message is shown in the console.
    <input type="button" id="mybutton" value="Go" onclick="console.log('foo')" />

Here's regression range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c0f88b376e33&tochange=c18776175a69

Bug 1116977 sounds related.
https://hg.mozilla.org/mozilla-central/rev/ef538bd60b1c

Gijs, is this intentional behavior?
Component: Printing: Output → DOM: Events
Flags: needinfo?(gijskruitbosch+bugs)
See Also: → 1116977
wrong component :P
Component: DOM: Events → Document Navigation
Navigation is blocked while printing or in print preview. This has been the case for a long time (e.g. history.back() would have been blocked since Firefox 1.0, see http://searchfox.org/mozilla-central/rev/d11bc710a8ed383524ab4ae8b021598443cfc64e/docshell/base/nsDocShell.cpp#2637-2643, lines which are from ~2002), but there were loopholes, and bug 1116977 closed one of the loopholes. The same code is used for beforeunload and friends, and people abuse it to "take people hostage" on a page (see the 'eviltraps' tracker bug for more examples of that type of behaviour).

I'm not really sure why print preview / printing block navigation. Maybe because the print process won't complete successfully if the user navigates away during printing? Maybe the "we're printing" flag should just be cleared before the 'afterprint' event fires? Mike, do you know?
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(mconley)
Summary: JS click event not working while printing (onafterprint) → Navigation not working while printing (onafterprint)
These days the only reason to block navigation is plugins, since print/printpreview still access the original plugin to do printing for those.
Otherwise we clone the document and everything in it, including images and iframes and what not.
We should certainly not be firing afterprint until after we exit printing state.  The problem is that this exiting happens async and can take quite a while for a long document.  :(

Maybe we can exit printing state immediately after cloning if there are no plugins or something?
Yes, we should be able to exit printing state immediately after cloning (if there are no plugins), and cloning should happen before afterprint. We should stay in print state only in the print document.
Let me investigate
Assignee: nobody → bugs
The question is whether we can delay afterprint in the plugin case until after we exit print state.
In case of print preview especially, that might mean delaying for quite some time. Perhaps that is ok.
*Backs out slowly*
Flags: needinfo?(mconley)
The spec is a tad vague and before/afterprint aren't implemented in blink (and I think not in webkit either, IIRC)
But I am a bit worried about that change.
https://html.spec.whatwg.org/multipage/webappapis.html#printing kind of hints sync dispatching

So, I guess better to clear the print flag earlier.
See Also: 1298942
Duplicate of this bug: 1298942
Keywords: regression
https://treeherder.mozilla.org/#/jobs?repo=try&revision=bb7a72f72963

This is about the best we can easily do here. Pages without plugins work well, and with plugins you get afterpaint async.
Not sure if this is too scary change. Gut feeling is that it isn't.
Attachment #8787440 - Flags: review?(bzbarsky)
oh, and this doesn't change "block loading being broken for print preview". That would be a separate thing, if wanted. But no one has complained about that during the past 7 years when that bug was introduced.
But this does still delay afterprint the same way in print preview case too.
(and we need to rely on DOM tree and not frame tree since frame tree for printing is created later, async)
Comment on attachment 8787440 [details] [diff] [review]
afterprint_2.diff

>+++ b/dom/base/nsIDocument.h

Blank line before "protected", please.

r=me
Attachment #8787440 - Flags: review?(bzbarsky) → review+
Pushed by opettay@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/e0a69d89f773
allow navigating when afterprint event is dispatched, r=bz
The change is tiny bit risky and regression prone, so definitely shouldn't be landed to branches.
https://hg.mozilla.org/mozilla-central/rev/e0a69d89f773
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
Depends on: 1305309
Backed out in bug 1305309.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla51 → ---
See Also: → 1430910
You need to log in before you can comment on or make changes to this bug.