Current active users (iOS/Android)
New users per month (iOS/Android)
Wed, Jul 29
Tue, Jul 28
Definitely worth doing if/when we revisit onboarding, but not worth keeping captured as a separate ticket
Unable to repro on 6.6.2, iPhone X
Mon, Jul 27
So we are all on the same page this will *reduce* the number of pageviews, see plot. For 2020/07/24 data for IOS the reduction is about 8% on data marked now as 'user'
Confirmed, that's expected given that we're now excluding requests to save for offline viewing and requests from versions older than 6.6.2.
Wed, Jul 22
Recreating it is an option. It'd probably be easier to recreate than downloading to a laptop.
Hi @Andrew, 1 wouldn't be a problem. For 2 would the data be restored or would I need to recreate it from scratch?
Tue, Jul 21
@Jdlrobson in the last 30 days, 94% of sessions were on versions of the iOSapp that no longer require MobileView. @JMinor is there a particular % of sessions or some other metric you'd like to hit before we say this is resolved?
@Tgr good point - If we go the PHP route, I don't think it needs to be an action API instead of a REST API. I'll update the description to clarify.
Declining this until there's a decision on T258485
Mon, Jul 20
We re-export the strings from the source code, and our export doesn't preserve the comments. To fix, it would need to read the comments on the file before this line and re-add them to the newly written file.
The app should be showing this page to mobile web in a webview, not mobile-html. Is this showing in mobile-html?
Might need to trigger a recalculation of the collection view layout on viewWillAppear
Sounds good - @Charlotte, @JMinor, and @SNowick_WMF can help determine when we should switch to only counting pageview=1 requests. It might be feasible to make this switch fairly soon instead of trying to separate out by version. For code review, our tech leads @Tsevener (iOS) and @Dbrant (Android) can help
Fri, Jul 17
It looks like the crash is on webView.becomeFirstResponder() in ArticleViewController+ArticleWebMessageHandling. It was added in this commit but I don't recall why. Removing it doesn't seem to affect the W icon popover display. It's possible we can remove that line entirely.
Thu, Jul 16
In mobile-html, removing this rule from base.css fixes it:
Tue, Jul 14
@JMinor would it be OK if to fix this issue we reset everyone's explore feed cache? So instead of having up to 30 days of explore feed history cached, when users upgrade to 6.7, they would have to reload from the network. It would simplify things a lot to not have to do a migration from the legacy format to the new one for the explore feed
Mon, Jul 13
It looks like the tag exists in the Parsoid output
This was resolved as part of the theme work in this patch: https://gerrit.wikimedia.org/r/c/mediawiki/services/mobileapps/+/604823
Fri, Jul 10
@Charlotte @JMinor @SNowick_WMF the Android app release that added the X-Analytics: pageview=1 header added it to all mobile-html requests, not just when the page is loaded into an article view. So when a user syncs reading lists, or saves an article for offline, the header is included. This is how pageviews were counted previously. I assumed that in adding the header, we would limit it to requests made by the article view when the user views a page. That was the intent of this ticket, apologies if that wasn't clear. The iOS version we have staged for release with this fix only adds it when the user loads the page in an article view, not with offline requests. We should resolve this discrepancy before the iOS app goes out.
Thu, Jul 9
That makes sense, thanks so much for pulling the data! We'll be able to use this to ensure we have a complete fix for the problem.
Wed, Jul 8
Thank you for flagging these issues before re-processing the data and for providing the additional context and evidence.
Tue, Jul 7
There's at least one bug with the updated definition and it's my fault. The iOS app is sending the wrong User-Agent on pageview requests. When reviewing the patch that updated the server-side definition, I verified the User-Agent matched, but only before the request was handed off to the system web view. The web view changes the User-Agent to it's internal one, which is something along the lines of:
Mozilla/5.0 (iPhone; CPU iPhone OS 13_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148
And not the app default of:
WikipediaApp/22.214.171.124 (iOS 12.4; Phone)
Works for me
@Nuria sounds good, I'd happy to talk about that. I set up a meeting to discuss.
Jul 1 2020
I think unless the cache duplication is causing an issue, we should keep the contract of the API and go with option (1). We have plans to lazy-load content, which would require those pieces of content to exist in the offline-resources endpoint