This now is live!
Try it out:
https://reading-web-staging.wmflabs.org/w/index.php?title=Pharmacovigilance&mobileaction=toggle_view_mobile&minerva-issues=b

The code is live on staging
http://reading-web-staging.wmflabs.org/wiki/Pharmacovigilance?debug=true
Config is set to

#eaecf0 is live on https://reading-web-staging.wmflabs.org/

Does mobile domain include users using desktop on mobile? I would like to know the answer to
"which special pages are users using on a mobile phone that they feel the need to use desktop site for?"

In T204609#4601837, @Tbayer wrote:

OK, let's look at the article https://lv.m.wikipedia.org/wiki/Filozofija , which currently is tagged as lacking references and receives between 20-80 pageviews per day.

However, it hasn't generated any PageIssues events so far:

SELECT COUNT(*) FROM event.pageissues 
WHERE year >0 
AND event.pageTitle = 'Filozofija';

_c0
0
1 row selected (58.149 seconds)

Interestingly, the top entry (on Pepin the Short) doesn't contain any visible page issues - rather, it seems there is an ambox class coming from this hidden infobox template: https://lv.wikipedia.org/wiki/Veidne:Infokaste%2B

@Jdrewniak @Niedzielski @nray and myself discussed and estimated this today.

In T204609#4602883, @alexhollender wrote:

Not sure if this is relevant or not, but ~half the time I load the page I do see the page issue appear, with the treatment that is currently on production. Whereas other times it doesn't present itself at all:

whereas with other pages on the list, e.g. Ropažu sporta centrs, it alternates between the new and current version as expected:

That wouldn't surprise me. Parsoid has no concept of the mobileformatter and I'm guessing the mobile content service doesn't optimise the page as android do not render the main page at all?

I didn't realise we were excluding all of Safari. That seems a bit extreme imo given we have seen this issue only on 11.1.1 on desktop and we could just exclude that user agent.

Marking this as resolved.
I've submitted a patch for removing the HTML validator. Let's open new tasks as necessary, given precommit hook support now exists.
https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/MobileFrontend/+/461497 Remove validate HTML dev-script

This can skip QA and design review as it's removing dead code.

I'm seeing 0.015 events per second. Little impact on ReadingDepth.
@Tbayer can you look at the data coming in and see if there's anything that's not expected?

I keep hitting this one in the wild, a constant reminder this bug is still open. Here's a recent example I saw today:

This looks done and I think this can skip QA. I'll let @Jdrewniak confirm and assign me and I'm happy to sign off when that's the case.

Does a workaround exist? I'm hitting this a few times today.

(the todo column was empty, I believe we informally agreed that it should never be empty)

That's not added by Minerva and doesn't show for me. I believe that's the gadget - "Add map popups to coordinates in the mobile website" so nothing readers web design had anything to do with, thus probably not a good comparison with the language button which we spent a whole quarter thinking about, designing and testing.

@Nuria so I completely agree with everything your saying.

In T204839#4598418, @Niedzielski wrote:

@Jdlrobson, should we always show the map button in a disabled state for pages without maps?

I don't have anything to add to what @Krinkle says... that's my understanding too.

I still can't replicate this (even now trying Safari), can you please provide more information per https://phabricator.wikimedia.org/T204627#4596374 as maybe this is due to my browser/operating system combo?

These logs seem to be intentional and were added in 456264d8 by @pmiazga
I'm guessing they should they go to a different logger channel? https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/includes/specials/SpecialMobileLanguages.php#L95

@aborrero if we don't hear from Sumit, i suggest we remove this instance, however I'm not sure what the protocol and grace period is for doing so.

Okay, some wires got crossed then :). I thought @Nirzar had approved the black color... :)

I chatted with @nray after standup and we feel like the remaining work is captured in T204786, which we will discuss on Monday as a group (and then later estimate/tackle as deemed necessary).

I'm guessing this is not something trivial we can fix?
Is there another task I should be following relating to this?

Since there is only one page with timeout issues in the whole of our projects I'm marking this as low.
All solutions seem kinda risky right now.

but that changes the colour of the search bar as well as the status bar, which seems a bit extreme.

It doesn't seem more extreme to me than adding several lines of CSS that apply everywhere except iOS. The fact the status bar is no longer black (as you mentioned it was before) seems like a regression.

The easiest thing to do here is just turn off the transform on the talk namespace and then re-evaluate. I'm guessing this is not going to be a problem on real world articles as they'd be too slow to load and would be unusable.

Nope, an RFC has not been drafted. I'm happy to be a coauthor of an RFC, but given I'm primarily a frontend engineer, I would like some help with the technical PHP side of things and/or support from someone who has experience in writing RFCs.

Swatting at 4pm PST

Swatting at 4pm PST