Deploy print to PDF button for Chrome on Android
Closed, ResolvedPublic3 Story Points

Description

Background

In T179529: [Spike] Can we detect browsers where the window.print function simply doesn't work? we determined that the print to PDF button only works for google chrome. We would like to deploy the button to Chrome on Android with the goal of:

  • providing the button to a large set of users
  • collecting data on the usage that the button gets
NOTE: Deployment date should be Nov 15 to allow time to communicate the change to community members via Village pump and wikitech-l

Acceptance Criteria

Developer Notes

  1. We'll need to enable the feature flag in the production config
  2. While there is an browser#isIOS function, there aren't #isAndroid and/or #isChrome function. These'll have to be added.

Related Objects

There are a very large number of changes, so older changes are hidden. Show Older Changes
phuedx renamed this task from Deploy print to PDF button for Chrome to Deploy print to PDF button for Chrome on Android.Nov 7 2017, 11:14 AM
phuedx updated the task description. (Show Details)
ovasileva updated the task description. (Show Details)Nov 7 2017, 5:09 PM
phuedx updated the task description. (Show Details)Nov 7 2017, 5:12 PM
ovasileva set the point value for this task to 3.Nov 7 2017, 5:13 PM
phuedx updated the task description. (Show Details)Nov 7 2017, 5:14 PM
Restricted Application added a subscriber: Dereckson. · View Herald TranscriptNov 7 2017, 5:51 PM

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

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

@ovasileva remember... images will not appear in the printed version of mobile (history in T162414).
Are we rolling out without addressing this problem? If not, we need a task for that first.

@Jdlrobson - for now, we're okay with downloads without images. That said, I was under the impression that it would be very difficult to tackle. What are our options in terms of adding images? Do we have any straightforward way of doing this, or should we start with a spike?

ovasileva updated the task description. (Show Details)Nov 9 2017, 11:19 AM
Tbayer added a subscriber: Tbayer.Nov 9 2017, 5:24 PM

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

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

ovasileva updated the task description. (Show Details)Nov 13 2017, 3:57 PM

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

Prior to rolling out, make sure email is sent to wikitech

Why? What is the purpose of the email?

NOTE: Deployment date should be Nov 15

Why? Why not today to allow us more time to revert if needed?

Change 391041 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[operations/mediawiki-config@master] Enable the download icon on all wikis

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

Why? What is the purpose of the email?
Why? Why not today to allow us more time to revert if needed?

This is a large change and we want to make sure the community is informed before deploying. More detail can be found under the CL task T180114: Notify community of upcoming PDF button deployment. We will be sending the update Nov 14 (tomorrow) and can go forward with the deployment on the 15th.

ovasileva updated the task description. (Show Details)Nov 14 2017, 10:46 AM
Tbayer updated the task description. (Show Details)Nov 14 2017, 6:55 PM

Clarified the intention of the last checkbox item per today's standup.

^ This can't be done until Wednesday, 15th, right?

Jdlrobson updated the task description. (Show Details)Nov 15 2017, 5:38 PM

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

Stashbot added a subscriber: Stashbot.

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)

Change 391041 merged by jenkins-bot:
[operations/mediawiki-config@master] Enable the download icon on all wikis

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

Mentioned in SAL (#wikimedia-operations) [2017-11-15T19:34:14Z] <catrope@tin> Synchronized wmf-config/InitialiseSettings.php: Enable Minerva download icon on all wikis (T179914) (duration: 00m 48s)

Jdlrobson added a comment.EditedNov 15 2017, 8:36 PM

There was quite a big jump over the lunch break after deploying (which happened around 11.30am) but it's now calmed down a little
https://grafana.wikimedia.org/dashboard/db/eventlogging-schema?orgId=1&var-schema=Print
I'm now seeing double the rate before the deploy.


Not sure what happened between 9 and 12:40 (but a similar no events and spike happened on Popups https://grafana.wikimedia.org/dashboard/db/eventlogging-schema?orgId=1&from=now-24h&to=now&var-schema=Popups)

Jdlrobson updated the task description. (Show Details)Nov 15 2017, 8:36 PM

cc @mforns - any idea why i'm seeing that several hours of no events?!

atgo added a comment.Nov 15 2017, 8:44 PM

@Jdlrobson I'm surprised that there's no jump between last week and this
week, given the button.

Jdlrobson assigned this task to Tbayer.Nov 16 2017, 12:18 AM

@atgo currently looking at the data for 24hr period [1] collected so far there seems to be a bump in traffic from Chrome (non iOS) on "minerva" (mobile skin) which can probably be attributed to the button, but desire to print on mobile appears to still be tiny compared to desktop so it's not really impacting the events per minute that we see in the graph.

Far too early to draw any conclusions as will take time for users to notice/understand/determine value and adopt usage of any new interface element.

15th Nov:
minerva 1301
vector 19424

14th Nov:
minerva 817
vector 19125

@Tbayer any checks you want to run before this gets signed off?

[1] select event_skin, count(*) from Print_17199246 where userAgent LIKE "%Chrome%" AND userAgent NOT LIKE "%iOS%" AND timestamp LIKE "20171115%" group by event_skin

This is a bit late in the game, but did we ever test the Schema:Print instrumentation for mobile/Minerva?
Recall that there had been a bit of confusion at T169730: Define and implement instrumentation for printing on desktop web, which (as the task name still says) was initially intended for desktop only, but came to be extended to mobile later. However, that was only after @bmansurov and I had done our testing rounds.

Or to put it differently: Has someone checked that the onBeforePrint/ matchmedia event (cf. T171162#3457776 ) behaves as expected for Chrome mobile on Android?

...


Not sure what happened between 9 and 12:40 (but a similar no events and spike happened on Popups https://grafana.wikimedia.org/dashboard/db/eventlogging-schema?orgId=1&from=now-24h&to=now&var-schema=Popups)

I followed up on #wikimedia-analytics; this was caused by yesterday's migration of the EventLogging master database.

...

I followed up on #wikimedia-analytics; this was caused by yesterday's migration of the EventLogging master database.

...and I understand the timestamps in the actual EventLogging table (in MySQL) are not affected, i.e. should not show that gap; Grafana instead reflects the time when the events were processed internally later in the pipeline (and in that sense is always a bit less accurate, even when the pipeline is not stopped entirely as in this case).

@Jdlrobson, @atgo - possibly could be lower than expected due to caching as well, although I'm still not seeing a very large increase. Perhaps we should double-check the schema as @Tbayer suggested

Or to put it differently: Has someone checked that the onBeforePrint/ matchmedia event (cf. T171162#3457776 ) behaves as expected for Chrome mobile on Android?

I don't see any specific record of us testing Chrome on mobile (I don't actually see much QA on T169730), but we did implement matchMedia per suggestion of @bmansurov specifically for Chrome.Llooking at the data, I am seeing events from Android Chrome on Minerva on the mobile domain. We wouldn't be getting any events if that wasn't working.

I think we should still do a manual check that the events are being sent in correctly as a part of signoff by going through the events. Do we have a good way of doing this from a phone?

Seems like we would need a separate task to set up a debug parameter and then try testing it manually

You can manually test this already for increased confidence.
To do so put the following code in your user minerva.js to force on bucketing:

mw.storage.session.set('mwuser-sessionId',15);

You will then be able to see the results in the database after waiting 5 mins or so.

select * from Print_17199246 where event_sessionToken = '15'

Test with that as you wish, but given the wide spread of Android versions (4-10) and families (Samsung, Nexus, Asus, Moto G...) in the data we are already collecting for Android [1] I see no need to be worried this is not working correctly. @Tbayer is there anything specific that's making you doubt the data?

[1] select * from Print_17199246 where userAgent LIKE "%Chrome%" AND userAgent NOT LIKE "%iOS%" AND timestamp LIKE "20171115%" and event_skin = 'minerva'

Jdlrobson added a comment.EditedNov 16 2017, 6:34 PM

I should note that usage seems a little higher today on Minerva (4x already) and already has surpassed yesterday's usage (1301 events) despite it being only 6pm UTC time:
minerva 4187
This fits a hypothesis of HTML caching/discoverability of a new feature.

It's still very low compared to desktop though (19424 events)

Or to put it differently: Has someone checked that the onBeforePrint/ matchmedia event (cf. T171162#3457776 ) behaves as expected for Chrome mobile on Android?

I don't see any specific record of us testing Chrome on mobile (I don't actually see much QA on T169730),

There was quite a bit of testing, see e.g. the link in my previous comment. But only on desktop, as far as I'm aware. Hence the question.

but we did implement matchMedia per suggestion of @bmansurov specifically for Chrome.Llooking at the data, I am seeing events from Android Chrome on Minerva on the mobile domain. We wouldn't be getting any events if that wasn't working.

"some data is arriving" is not the same as "correct data is arriving".

You can manually test this already for increased confidence.
To do so put the following code in your user minerva.js to force on bucketing:

mw.storage.session.set('mwuser-sessionId',15);

You will then be able to see the results in the database after waiting 5 mins or so.

select * from Print_17199246 where event_sessionToken = '15'

Thanks for these instructions!

Test with that as you wish, but given the wide spread of Android versions (4-10) and families (Samsung, Nexus, Asus, Moto G...) in the data we are already collecting for Android [1] I see no need to be worried this is not working correctly. @Tbayer is there anything specific that's making you doubt the data?

I'm surprised to see that kind of logic put forward, given all the past data problems the team has experienced due to instrumentation bugs that could have been easily avoided with some direct testing before deployment. Specifically in the case of this schema (see e.g. T169730#3471912 ) and more generally in recent months (we also discussed this for a while at last month's offsite) we have been resolving that direct testing is needed, and it has already started to pay off.

Anyway, since this task is about deploying the feature per se, I'm going to close it now, having verified that the increase in events did not break EventLogging, i.e. the last AC. I have added a point about instrumentation testing to T179915 instead.

Tbayer closed this task as Resolved.Nov 21 2017, 4:52 PM
Tbayer updated the task description. (Show Details)