Page MenuHomePhabricator

Lazy loaded images should appear in printed version of articles
Open, MediumPublic

Description

Our user research shows that many of our users workaround slow internet connections by saving webpages and sharing them with each other via Whatsapp.

We lazy load images on Wikipedia to save our users data.

Users typically print by using the browser print method.

When printing an article, any lazy loaded images are not present in the printed version of the page.

We would like to detect when a user is printing a webpage and load images via JavaScript.

Developer notes

Although it is not possible to download images during the print dialog, we can notify the user when images are not present in the article via a banner at the top of the page. The banner would be added on page load, positioned at the top of the page, but only displayed on print media. When all images are downloaded this banner would be removed.

Medium does this like so:

Note: Although not widely supported, architecture wise this should be expected to work on the Vector skin when useformat=mobile is applied given lazy loading is a "m. domain" concept, not a Minerva concept.

Design

To be completed by @alexhollender

Event Timeline

Restricted Application removed a project: Patch-For-Review. · View Herald TranscriptApr 6 2017, 10:33 PM

Change 343975 had a related patch set uploaded (by Jdlrobson):
[mediawiki/extensions/MobileFrontend@printstyles] Load all images when entering print mode

https://gerrit.wikimedia.org/r/343975

Jdlrobson updated the task description. (Show Details)Apr 7 2017, 12:21 AM
ovasileva raised the priority of this task from Medium to High.Apr 7 2017, 11:58 AM

I've split this out from the bigger task as it warrants its own conversation.

I think we may have hit an upstream browser bug/limitation with using matchMedia to detect entering print mode.

I've made a MTC
https://jdlrobson.com/dev/printbehavior.html

If you load this page and hit print the behaviour varies depending on the browser.

In Chrome, it triggers the loading of the images, but they may or may not show up in the resulting page. I guess it's because image loading is asynchronous.
In Firefox, it does nothing.
Safari nothing.

There is an open bug for Firefox here:
https://bugzilla.mozilla.org/show_bug.cgi?id=774398

I notice that when I try to print pages on https://medium.com articles images do not load there either, so this might have to be a limitation we live with... :/
I've emailed some people in Mozilla to get their thoughts on this.

If we can't resolve this way, unfortunately revisiting T160079 (and hurting first paint in the process) seems to be the only way forward.

(This was broken out of one of the bullets of the bigger task that we already committed to so should not have unplanned sprint work)

If we can't resolve this way, unfortunately revisiting T160079 (and hurting first paint in the process) seems to be the only way forward.

How about creating a dedicated print button that loads images and then triggers the print dialog?

@Jdlrobson Have you tried combining matchMedia with onbeforeprint?

Jdlrobson changed the task status from Open to Stalled.Apr 10 2017, 6:35 PM
Jdlrobson removed a project: Reading-Web-Sprint-95.
Jdlrobson moved this task from 2016-17 Q3 to Needs Prioritization on the Readers-Web-Backlog board.

The problem here is image loading is asynchronous. This appears to be a spec bug which is a little complicated as delaying a print action on asychronous actions could lead to poor user experience (or worse case inability to print if some promises never resolve). Early indications suggest the patch I've submitted will only help in the case of the 2nd print for Chrome users which is better than nothing, but as @bmansurov suggests a dedicated print button can help avoid this entirely at the expense off users who have trained themselves to use their browser print function.

I'm stalling this for the time being and de-scoping this for the current sprint as this requires some more thought.

Change 343975 abandoned by Jdlrobson:
Load all images when entering print mode

https://gerrit.wikimedia.org/r/343975

@Jdlrobson - I think for right now maybe the best way forward would be to implement the chrome solution only for the browser print. From the New Readers research, it seems users really liked the separate print button, so we'll be focusing on that later on

Jdlrobson reassigned this task from Jdlrobson to ovasileva.Apr 19 2017, 8:42 PM

Filed upstream for https://github.com/whatwg/html/issues/2532#issuecomment-294021096
@ovasileva there is not even a way to implement this in Chrome reliably. I advise @Nirzar and yourself to explore what a print button would look like as it seems our best bet now.

@Jdlrobson will create follow up task

Jdlrobson changed the task status from Stalled to Open.May 21 2017, 11:30 AM
Jdlrobson removed a project: Patch-For-Review.

@ovasileva FYI when we deploy print styles to mobile only images that have been loaded by the user will be shown.

@Nirzar did a follow up task get created?

Jdlrobson closed this task as Declined.May 21 2017, 12:12 PM

This is not possible. T163472 is proposal going forward.

Jdlrobson reopened this task as Open.Jun 6 2018, 10:11 PM

Medium has now worked out a solution for this and we should do it too:

ovasileva lowered the priority of this task from High to Medium.Jun 7 2018, 10:14 AM
Jdlrobson renamed this task from [subtask] Images should appear in printed version of articles to Images should appear in printed version of articles.Jun 11 2018, 6:21 PM
Jdlrobson renamed this task from Images should appear in printed version of articles to Lazy loaded images should appear in printed version of articles.
Jdlrobson updated the task description. (Show Details)
Jdlrobson updated the task description. (Show Details)
Jdlrobson added a subscriber: alexhollender.

@Jdlrobson ok, so I wonder if the copy should be more like "there was an error with ..... please close this dialog and press the download button again"? If we mention waiting for images to finish downloading there's no real way for the user to know when enough time has passed, other than just trying again and seeing if the error is still there, so maybe we don't even mention images loading at all and just tell them to try again?

@alexhollender that sounds good do you want to provide a mock?

ovasileva removed ovasileva as the assignee of this task.May 26 2020, 1:02 PM
Restricted Application added a subscriber: Masumrezarock100. · View Herald TranscriptMay 26 2020, 1:02 PM