Intent to Deprecate and Remove: window.print() during page dismissal

78 views
Skip to first unread message

Lucas Gadani

unread,
May 9, 2017, 4:26:22 PM5/9/17
to blink-dev, Daniel Cheng

Primary eng (and PM) emails

l...@chromium.org


Summary

Disallow window.print() during the beforeunload and unload handlers.

Motivation

The print dialog runs a nested message loop inside the renderer, which can lead to crashes and security bugs. Also, it's already broken in many situations:

In the beforeunload handler:
- works when doing an in-process navigation (such as clicking a link).
- doesn't work on cross-process navigations (such as typing a URL in the omnibox).
- doesn't work when closing the tab.

In the unload handler it never works properly.

The spec already allows the user agent to abort printing at any time: https://html.spec.whatwg.org/#printing .

Interoperability and Compatibility Risk

Edge: Works on the beforeunload handler; doesn't work on the unload handler.

Firefox: Firefox blocks print() on both beforeunload and unload handlers.

Safari: Not tested.


Alternative implementation suggestion for web developers

N/A.

Usage information from UseCounter

window.print is used in 0.01% of page visits: https://www.chromestatus.com/metrics/feature/timeline/popularity/953


We don't have information of how many of these calls are from the unload handlers.


OWP launch tracking bug

https://crbug.com/706319


Entry on the feature dashboard

N/A.


Requesting approval to remove too?

Yes.


Anne van Kesteren

unread,
May 10, 2017, 12:30:49 AM5/10/17
to Lucas Gadani, blink-dev, Daniel Cheng
On Tue, May 9, 2017 at 10:26 PM, Lucas Gadani <l...@chromium.org> wrote:
> The spec already allows the user agent to abort printing at any time:
> https://html.spec.whatwg.org/#printing .

I think an explicit issue would still be good, since it might be
worthwhile making the known dismissal cases interoperable, provided
other user agents agree with your plans (which I think they probably
would).


--
https://annevankesteren.nl/

Lucas Gadani

unread,
May 15, 2017, 3:13:33 PM5/15/17
to Anne van Kesteren, blink-dev, Daniel Cheng
Thanks for the feedback,  I've filed https://github.com/whatwg/html/issues/2683 to track this issue.


TAMURA, Kent

unread,
May 16, 2017, 1:56:54 AM5/16/17
to Lucas Gadani, Anne van Kesteren, blink-dev, Daniel Cheng
LGTM1.
Sounds interoperability risk is low.


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALQVofoLCY6zpf%3Dq2GtXdXw1GqQgscB8Q2UJssMSMnH_WDigSg%40mail.gmail.com.



--
TAMURA Kent
Software Engineer, Google


Chris Harrelson

unread,
May 16, 2017, 8:12:59 PM5/16/17
to TAMURA, Kent, Lucas Gadani, Anne van Kesteren, blink-dev, Daniel Cheng
LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqFFvYAu88mjLH%2B-sM_YC9Bsvua7-k-i7BKzBZseo9UO7g%40mail.gmail.com.

Rick Byers

unread,
May 19, 2017, 3:30:41 PM5/19/17
to Chris Harrelson, TAMURA, Kent, Lucas Gadani, Anne van Kesteren, blink-dev, Daniel Cheng
Thanks for pushing this Lucas.  I agree the compat risk is low, and aligning with Firefox is good for interop.  LGTM3

Reply all
Reply to author
Forward
0 new messages