In T208980#5082522, @Jdlrobson wrote:

Does this need QA/QA steps?

My inclination is #1, given the relatively well-known complexity of #2 and the unknown-but-presumably-vast complexity of #3.

My understanding is that tags can't be looked up by their translated name so existing references to "mobile web edit" would have to stay. Is that correct? For example, I only see messages being looked up for display purposes in https://github.com/wikimedia/mediawiki/blob/master/includes/changetags/ChangeTags.php (see ChangeTags::tagDescription and ::tagLongDescription).

Maintenance of the Wikipedia portals is our responsibility. That being said, I don't believe we've had the discussion as to whether the portals are frozen. If not, then this work is no different from our other work (prioritisation and estimation and an eventual commitment).

Ping @santhosh and @Jdrewniak.

In T216063#5074754, @Milimetric wrote:

We are leaning towards filtering out events coming from non-wikimedia domains.

☝️ If necessary, we could break out migrating from using the unload event to using the pagehide event into another task.

In T208980#4954751, @nray wrote:

In T208980#4954700, @phuedx wrote:

@nray: See @Krinkle's detailed explanation here: T208980#4792762

Thank you, I didn't read that closely enough. Sounds like in addition to the unload event not firing in common scenarios on mobile devices the beforeunload event wouldn't fire either.

Background/motivation: A limitation of the current ReadingDepth data is that the pageUnloaded event may not be fired if the page is terminated by the browser/system before unload. On mobile, this actually happens in a majority of cases and biases our data especially when comparing reading times on desktop and mobile ( https://meta.wikimedia.org/wiki/Research_talk:Reading_time/Work_log/2018-11-02 ).

High because the debt is in an area that we're actively working on and it's both a UX problem and a resource consumption problem.

@Jdlrobson: T217814#5062730 doesn't have a lot of context (e.g. it may've been a comment written in haste during a meeting). Can you advise whether this task should be split up or reestimated?

I kicked off a build and it passed: https://integration.wikimedia.org/ci/view/Reading-Web/job/selenium-MinervaNeue/905/

Ping @ovasileva and @alexhollender for prioritization.

Growth-Team are marked as the stewards for MediaWiki-extensions-FlaggedRevs on https://www.mediawiki.org/wiki/Developers/Maintainers.

A data point (may or mayn't be related): SauceLabs had an incident yesterday: https://status.us-west-1.saucelabs.com/incidents/gywtsd27cq06

How should this be QA'd? What are the steps that should be taken to prove that this works?

Each item on the menu will be tracked in the same schema where main menu tracking occurs

Since all the subtasks are resolved, can this be resolved?

If the code for QuickSurveys loads AFTER MobileFrontend, the hook will be registered too late and the survey will never show.

The task that led to the introduction of the mobile.betaoptin event: T111188

• Data for clicks to all new links can be collected using https://meta.wikimedia.org/wiki/Schema:MobileWebMainMenuClickTracking

@Jdlrobson: Would changing the message require that any existing workflows are updated or would folk still have to refer to the tag by its name when querying the DB or specifying it as an argument for the tagfilter parameter in an MW API call, for example? That is, would the tag look like it was called "mobile web action" but still actually be called "mobile web edit"?

As for on-wiki uses by the general public:

Would replacing the textarea with a div if the page is protected work? This would be cleaner than manipulating the DOM in JS IMO.

In T217526#5024391, @Jhernandez wrote:

@ovasileva This is probably a bug on mobile web too?

This appears to have been fixed in https://en.wikipedia.org/w/index.php?title=Calculus&type=revision&diff=887407355&oldid=886050145, which is the fix that @Tacsipacsi proposed in T217526#5012719.

@mforns: I'm pretty sure this is deployed and (re)started as there are log lines appearing in Kibana for the following query: https://logstash.wikimedia.org/goto/36329f5fd2348e181177ff879800d9c0

In T217142#4997724, @Ottomata wrote:

Unless we have a generic schema for client error logs! :) Might not be a bad idea.

CC @LarsWirzenius per https://lists.wikimedia.org/pipermail/engineering/2019-February/000689.html :)

Also CCing @dr0ptp4kt

CC @Jhernandez, @Tgr, @faidon, @fgiunchedi, @herron for visibility. My apologies in advance for the description churn, y'all.

1. Nice find, @Jdlrobson!
2. Should we discard surveys that required CentralNotice to be loaded if it isn't?

@Tbayer pointed me at this task during our 1:1 yesterday.

@nray: See @Krinkle's detailed explanation here: T208980#4792762

@ovasileva: This is in Triaged but Future in our backlog but doesn't appear to have a priority.

Following @Tbayer's advice, I did a little digging in wmf.webrequest:

In T216063#4953716, @phuedx wrote:

AFAICT the function that should be decoding and parsing the QSON (Querystring-encoded JSON) string is expecting that character to not be encoded but it is (it's the %3B at the end of the raw event).

The "Extra data:" error is raised by json.loads as it encounters the ; character at the end of the JSON string:

@Edtadros and I worked through testing the 4th 5th acceptance criterion together during our 1:1 today.

In T215477#4949367, @Jdlrobson wrote:

I guess such a generic hook for log events would need to run inside $logEntry->insert()?

In T210652#4948279, @phuedx wrote:

@ovasileva: Could you update https://phabricator.wikimedia.org/project/profile/2960/ accordingly?

I've removed this from our (Readers Web's) kanban board as Proton has been handed over to Readers Infrastructure.

In T214444#4946376, @Edtadros wrote:

1. Are you expecting an HTTP 204 status in the last QA step for the requests that appear after filtering?

@ovasileva: Could you update https://phabricator.wikimedia.org/project/profile/2960/ accordingly?

Per our (@Jhernandez, @Tgr, @pmiazga, and me) conversation in last Thursday's Audiences Platform Sync, Proton has officially been handed over to Readers Infrastructure for ongoing maintenance. I'll follow up with an email to readers-web-team@wikimedia.org and ri-team@wikimedia.org to confirm this.