More info:
Once the article 'freezes' on one tab in Chrome, the download button does not appear to be functional at all – can no longer be invoked when on another article in a new tab. It only works again after force stopping and opening the Chrome app.

I suspect that this is a hugely memory intensive process... Making a PDF of the obama article is probably not something that Android engineered for ;)

I suspect that this is actually caused by the device taking time to enumerate printers before it shows the dialog rather than trying to generate a preview. This seems in line with the observation that the delay doesn't vary with the size of the page (though generating the preview once the dialog is open will!).

If this is the case, then we'll have to:

• Disable the button once the user has tapped it
  • ... and replace it with a spinner to give them feedback?
• Detect when the print dialog has closed and enable the button

The last part isn't as easy as it seems. In IE and Firefox, we can listen for the afterprint event; in other browsers, we might have to use window.matchMedia.

I suspect that this is a hugely memory intensive process... Making a PDF of the obama article is probably not something that Android engineered for ;)

haha yes.

Disable the button once the user has tapped it
... and replace it with a spinner to give them feedback?
Detect when the print dialog has closed and enable the button

I was going to suggest the same but then I realised soon we will be showing a loading spinner while we fetch images on the page. instead of disabling the button I would like to show a spinner irrespective of images. We're probably doing what you said anyways, show spinner and hide spinner afterprint

1. we either modify the task description here T180058 to always show spinner, and fetching images is async to it

2. modify this task description to make that change

for now, i changed this from a bug to a feature request, as the loading issue is not something we can solve, all we can do is show system status that something is happening and remove the button while something is happening to avoid queuing

What happens when you clock the native browser print. The same?

That would at least confirm the likely hypothesis that this relates to this being a memory intensive process.

We added a spinner this sprint. It currently hides before the window.print call

If we flip those calls and hide spinner after I would hope that would take care of this provided that method is synchronous. If not I'm not sure what we can do here right now..

Change 393651 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/skins/MinervaNeue@master] Clear spinner after window.print

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

Change 393651 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Clear spinner after window.print

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

@ovasileva I see the change in the proposed solution

Increase the time the spinner is available until from after we fetch all images T180058: Download all page images for printing, to when the print dialog appears

Good catch on the delay after fetching images but what will happen if there are no images to fetch? do we show the spinner? I guess we want to detach spinner for image fetching.

We can keep the spinner animation but it's tricky to detect when the print modal window gets visible or gets dismissed. We would need to do some hacks as not all browsers give us proper feedback.

just tested T180058 and it is solving most of the issues mentioned here

Just FYI this is now fixed on my testing device. I had this issue earlier but since we deployed the spinner, everything works fluently.

^ Can this task be resolved @ovasileva?

🎉🎉🎉