Asynchronous print events to load deferred images

[jdlrobson]

At Wikimedia, we've discovered many of our users are working round slow internet connections by saving web pages and sharing them with each other via Whatsapp and other tools. Users typically print by using the browser print method. As a result, we've been trying to improve the printed experience for all our mobile web pages.

We've hit a problem with showing images in the printed versions of our pages as we lazy load images on Wikipedia to save our users data [1].
When printing an article, any lazy loaded images are not present in the printed version of the page.

This is not a unique problem to us, many other websites lazy load images e.g. try hitting print on any medium.com article with images.

Ideally we'd like to be able to subscribe to something akin to an onbeforeprint or event on MediaQueryList event and load images.

Obviously, making this event asynchronous leaves open potential abuse - it could mean the print function freezes altogether (unless a timeout is present) or is slow (imagine an event that downloads a 1gb file before allowing a print), but it should provide some support in loading of additional resources.

Any thoughts?

[1] https://blog.wikimedia.org/2016/09/19/mobile-web-improvements/

[domenic]

To be clear, the beforeprint event already exists. I guess it just doesn't allow you to arbitrarily delay printing, in the current design.

If implementers are up for this, I think the spec work would be relatively easy; we'd probably reuse service worker's ExtendableEvent. And it seems well-motivated. I'll try to poke people.

[Zirro]

Looking at this issue, I felt that there may be a larger question around lazy loading images which can be addressed. I've created issue #2534 to discuss a way to tell user agents that an image is lazy loaded, allowing it to adjust its behaviour in contexts such as printing.

[jdlrobson]

To be clear, the beforeprint event already exists. I guess it just doesn't allow you to arbitrarily delay printing, in the current design.

Exactly. It doesn't allow you to run asynchronous JavaScript.

And it seems well-motivated. I'll try to poke people.
Awesome!

[jdlrobson]

Any thoughts aaround this? Anything I can do to help make this happen?

[domenic]

Unfortunately this hasn't really seen any implementer response, which is what we need to move forward. If you have any contacts on browser teams, asking them to chime in here would be the best thing to do.

[smaug----]

I do support work to be done here, since the platform clearly lacks some needed features.

[Malvoz]

Isn't the behavior of how to handle deferred content under certain circumstances in the intereset of web API implementors?

Similarly to how one may expect deferred images to load in for printing, lazily loaded content should preferrably load in to be cached for offline experiences (e.g. user presses "Add to home screen"). This is what Chromium intends to do: https://bugs.chromium.org/p/chromium/issues/detail?id=905432

[jdlrobson]

Native lazy loading images [1] would make the need here obsolete, but in its absence, having some way to say "wait! before you go print do these things!" is missing.

[1] (https://calibreapp.com/blog/native-lazy-load/)

[housseindjirdeh]

Unfortunately as of current, native lazy loading doesn't solve the problem. Here's a demo that shows how it's technically possible with a custom print button, but not with the native print action.

There's an open bug on Chromium for this, but allowing for an async operation on print would also solve the problem (and provide anyone with the capability to use it for things that need to complete asynchronously aside from lazy load).

[openmindculture]

The bug has been fixed in Chrome according to bugs.chromium.org/p/chromium/issues/detail?id=875403#c40.

[nicolo-ribaudo]

This would also solve a problem with fonts.

I have some fonts that are only used inside a @media print block. However, font loading from CSS is asynchronous, so they are not ready by when window.print() synchronously takes the sanpshot.

I originally reported this as a Chrome bug (https://issues.chromium.org/issues/394760808), but I believe it might be a spec limitation that this issue would fix.