Page MenuHomePhabricator

[Spike] Can we detect browsers where the window.print function simply doesn't work?
Closed, ResolvedPublic

Description

The following browsers are failing on Android. Tested on a simulator and with real devices (Pixel w/ Android 8.0 and Nexus 4 w/Android 5.1.1):

  • Opera
    • window.print is available and click handler is bound but doesn't do anything.
    • It works on desktop
    • setTimeout doesn't help
    • No print option in browser menu
    • When investigating it was suggested tha window.print might not actually work until the document has fully loaded however when I tried this still didn't work. Even doing an unconditional window.print a window load event has no effect

A MTC to make it easier to identify browsers which programmatic printing is possible is here:
http://jdlrobson.com/dev/window.print/index.html

On a large share of browsers clicking the button is a no-op ie. nothing happens.

Note that

Open questions

  • Can we feature detect whether calling window.print will do nothing? NO. In some cases we can detect when it's failed though.
  • If we decide to browser detect, can we reliably filter out Android versions of Opera, Dolphin etc... What are their user agents?

Outcomes

  • We have a list of browsers that we can reliably target on-wiki.
  • Document ^ and other updates to mobile PDFs

Per T179529#3738918, we will whitelist Chrome on Android. Doing so will enable us to collect some data around usage before rolling it out to a wider number of devices.

Event Timeline

Jdlrobson renamed this task from Fix or Blacklist print button on certain browsers where window.print doesn't work to Print button displayed but unusable on certain browsers where window.print doesn't work (needs investigation).Nov 1 2017, 7:39 PM
Jdlrobson updated the task description. (Show Details)

Do we get the same behavior for all these browsers? A brief message saying what exactly the issue is with each browser would be helpful and appreciated.

Firefox is working on desktop as well.

Jdlrobson renamed this task from Print button displayed but unusable on certain browsers where window.print doesn't work (needs investigation) to Print button displayed but unusable on certain browsers in Android where window.print doesn't work (needs investigation).Nov 2 2017, 3:15 PM

I've clarified that this only impacts Android... I've also updated notes that the button is inactive on those browsers.

For the Opera part of this bug: window.print might not actually work until the document has fully loaded.

This is confirmed in a number of different SO answers but there are no links to an actual Opera bug.

After looking into this a fair bit, the sad conclusion i have come to is that there is little to do except sniff user agents. This is likely to be difficult and we'll need to spend some time researching and pinning down which are the appropriate user agents to block, especially given this feature works fine on desktop browsers.

There is no indication that window.print has failed, no JavaScript exception is thrown and the window.print function is always callable.

Regretfully, we may even want to restrict this to Google Chrome only, but that seems problematic from a movement POV since it would be clearly favouring a given browser....

giphy.gif (227×274 px, 318 KB)

Would our next step here be a spike? I spoke about this briefly with @atgo and we think it would be best to fix this for all browsers (Opera and UC Browser in particular) before deploying.

This task already seems spikish. I wouldn't want to split analysis between two tasks at this point (@Jdlrobson's already done a bunch above).

phuedx renamed this task from Print button displayed but unusable on certain browsers in Android where window.print doesn't work (needs investigation) to [Spike] Can we detect browsers where the window.print function simply doesn't work?.Nov 3 2017, 11:54 AM
phuedx added a project: Spike.

Did we read https://phabricator.wikimedia.org/T179529#3731208 ..?

What is missing? (To be clearer this is unfixable in opera mobile and uc mobile)

Did we read https://phabricator.wikimedia.org/T179529#3731208 ..?

What is missing? (To be clearer this is unfixable in opera mobile and uc mobile)

I think looking into the levels of unfixable and getting some more detail would be really important. Opera and UCBrowser are two of the most-used browsers for our target audience for this feature.

Think looking into the levels of unfixable and getting some more detail would be really important.

I'm not sure what more details I can offer you. The browsers do not make the native browser print function accessible. We could talk to these browser vendors about future plans if we have contacts, but right now there's nothing we can work with in the present.

To provide some kind of download functionality for these browsers we would either have to wait for the PDF rendering service that we are trying to build out, or we'd need to explore other means of downloading - e.g. generating downloadable HTML files.

The browsers do not make the native browser print function accessible.

This is Opera Mobile and UC Browser, right? Is the window.print function still available in those browsers? If so, then you're right: we'll have to sniff UAs.

Opera, at least, provide decent documentation about how to detect Opera Mini: https://dev.opera.com/articles/opera-mini-and-javascript/

Is this really a spike? It seems clear to me and ready to be estimated and worked on.

Rather than thinking about which browsers to blacklist I think actually this is a rare case where a whitelist makes a lot more sense - at least until we want to roll this out on a wider scale. Do we know any mobile browsers other than Chrome where this is supported (@ABorbaWMF I guess you'd know best)? Obviously limiting this to Chrome mobile will mean the feature doesn't work on desktop browsers, but this doesn't seem like a problem given the purpose of this roll out (collecting data).

Side note: I made http://jdlrobson.com/dev/window.print/index.html to test this. If clicking the button on a mobile browser shows the print interface it means printing is possible.

@Jdlrobson Chrome is the only 'working' browser that I know of.

Is this really a spike? It seems clear to me and ready to be estimated and worked on.

Yes. T179529#3738918 is the outcome. I'll update the description of the task.

Has the "Enable the button for Chrome on Android" task been created yet @ovasileva? We could probably line that up for the next sprint… thing…

This task can be resolved once any follow-on tasks have been created 🎉🎉🎉

I can set it up. Just to make sure we have everything aligned:

  • we will reach out to Firefox to see what the issue currently is. It would also be good to note that there's two ways of creating a PDF on Firefox mobile (page - print - PDF, page- Save as PDF)
  • @phuedx, @Jdlrobson - would the next task be the deployment task for Chrome or do we need a separate task for separating the functionality by user agent?

I can set it up. Just to make sure we have everything aligned:

  • we will reach out to Firefox to see what the issue currently is. It would also be good to note that there's two ways of creating a PDF on Firefox mobile (page - print - PDF, page- Save as PDF)
  • @phuedx, @Jdlrobson - would the next task be the deployment task for Chrome or do we need a separate task for separating the functionality by user agent?

@Jdlrobson's done #1 already and the deployment task LGTM.

phuedx claimed this task.

Per the discussion in the Backlog grooming - all team edition meeting, this is D.O.N.E.

How many hours did we spend on this? 4?

Change 389747 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/skins/MinervaNeue@master] Limit download button to Google Chrome

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

So the conversation isn't lost on how we reach the decision - I'd prefer to associate the patch with this conversation.

^ Per @Jdlrobson's point in T179529#3742078, we haven't actually documented this conversation (or the research) on the project page.

Actually, all the mobile PDF info currently lives here: https://www.mediawiki.org/wiki/Reading/Web/Projects. I need to create a separate page for mobile PDFs.

Change 389747 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Limit download button to Google Chrome

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

Change 391040 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/skins/MinervaNeue@wmf/1.31.0-wmf.7] Limit download button to Google Chrome

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

Change 391040 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@wmf/1.31.0-wmf.7] Limit download button to Google Chrome

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

Mentioned in SAL (#wikimedia-operations) [2017-11-15T19:16:13Z] <catrope@tin> Synchronized php-1.31.0-wmf.7/skins/MinervaNeue/resources/skins.minerva.scripts/init.js: Limit download button to Google Chrome (T179529, T179914) (duration: 00m 49s)