Can I ask that an outcome of this epic be well-written documentation about how to author new overlays both within and without the MobileFrontend/MinervaNeue codebases?

This is currently blocked on a privacy review.

☝️ /cc @Pchelolo @mobrovac

Very neat, @Krinkle! That approach'll require a fair bit of explanation in the QuickSurveys documentation for future developers (covered by AC 3)

I removed the duplicate information from the description but should clarify the following:

The client-side error rate has since fallen to its previous level: https://grafana.wikimedia.org/d/000000566/reading-web-dashboard?orgId=1&panelId=15&fullscreen&from=1547035200000&to=now&refresh=5m

In T209882#4869179, @bmansurov wrote:

@Jdlrobson thanks for spotting this. I wonder what a proper fix would be. There's got to be a way of removing that config. Hopefully the fix reduces the errors.

AIUI the service runner running Proton is firejailed. Is that correct @pmiazga, @Pchelolo?

☝️ Formalizing T212959#4867678.

Here's the GettingStarted extension's implementation of edit tags: https://github.com/wikimedia/mediawiki-extensions-GettingStarted/blob/ae9542e45f722c5f700ed4434dca47d561394794/Hooks.php#L328-L363

Thanks for the ping, @charlotteportero. This can safely be declined for now as the Marvin project is being archived.

Do note that this task focusses on making the change in our application code, which is made possible by restricting AMC to logged-in users (who are always served by the application servers). It may be prudent to home all of our X-Analytics-related logic in the Varnish VCL's themselves.

There was a lot of back and forth between an 8 and a 13 with good discussion about:

In T212330#4849302, @Ottomata wrote:

We don't want to collect this data at all, right?

I think the original change was a good one – constraining a very loose API is a Good Thing™. However, while the ContribsPager API was very loose (a number of member variables were created in the constructor that happily defaulted to public!), I have to ask: should the public member variables have been formally deprecated?

In T212771#4849357, @kostajh wrote:

Alright, shall we just make it a public property for now?

@thiemowmde @Umherirrender: I've subscribed you both as you authored and merged the change I mentioned, respectively.

I take it back. Correlation doesn't imply causation and all that…

👍

It looks like this introduced a regression in the automated browser tests (N.B. the failures started on 22nd December as they were run 2 hours prior to T200927#4840811): https://integration.wikimedia.org/ci/job/selenium-MobileFrontend/

Being bold.

className is always passed to the parent constructor rather than set as a property

To be clear, that's 1 second after the page preview is shown, which occurs no less than 700 ms after the user hovers over the link, i.e. the user has to dwell on the link for >= 1.7 seconds prior to the beacon being sent. I grant that some of these beacons could be the result of accidental hovers but, from experience, it's unlikely.

Points 1 and 2 were addressed in https://gerrit.wikimedia.org/r/478488. It'd be good to see a follow-on change to add tests for the class.

@Jdlrobson: I believe that https://gerrit.wikimedia.org/r/481181 should allow us to mark the first AC as done so that we can resolve this task.

If a class extends View and defines className and isBorderBox these have no impact
No deprecation notices can be shown in the console under any circumstances

isBorderBox is always passed to the parent constructor rather than set as a property

className is always passed to the parent constructor rather than set as a property

(Emphasis on should)

The beacon should be being sent 1 second after the page preview is shown. This is also reflected in the AC for T184793: [EPIC] Instrument page interactions and in the description of the VirtualPageview schema itself.

My guess is that this is Normal to High. We should try to reproduce it with Proton and if we can, then it should be escalated.

In T208980#4833034, @Jdlrobson wrote:

What reading web products using statsv that might be impacted?

How long does it take on average for pages to load?

Thank you, @D3r1ck01!

Being bold.

Code Coverage has gone up to 100%

Being bold.

Code Coverage has gone up to 100%

In T208980#4829781, @Jdlrobson wrote:

Can you expand the problem statement here? Does this relate to ReadingDepth or something else? It would be great to tie this back to our products and any bugs we're seeing.

In T209647#4829799, @Jdlrobson wrote:

Using a tried and tested alternative e.g. Preact was quite popular and we're going to explore that a little more.

@JTannerWMF: I'm the Sam you're looking for 🙂

☝️ From at the current AC for T210553: Deploy page issues to all wikipedias (except enwiki):

In T209708#4817463, @Esanders wrote:

I suspect there may be a distinction between processes we expect to complete quickly (e.g. <500ms) and long processes like loading VE, which can take a few seconds. A design which works for one may not be optimal for the other.

In T197883#4818045, @phuedx wrote:

Unfortunately, both the staging server and the Beta Cluster no longer have the Page Previews testing pages present. I'll try and dig out the corpus and re-import it to both of those servers.

@nray: As discussed, here's the list of all Page Previews test cases that @ovasileva and @ABorbaWMF created. As you can see, it's long. I would suggest that you use your discretion about how many cases you run through (e.g. we have browser tests covering previews appearing/disappearing when you interact with a link).

This first step will be determining where the overlay is used, followed by design review and discussion.

I can conceive of a situation where you'd define a view with some default click event handler but an extending class wants to define its own click handler. In this instance, I'd expect both event handlers to be bound rather than one. Is this the intended behaviour?

Being bold.

In T208920#4813708, @phuedx wrote:

This change affects the call to action shown to an anonymous user when they click the watchstar and affects the reference drawer so both of those should be tested.

This change affects the call to action shown to an anonymous user when they click the watchstar and affects the reference drawer so both of those should be tested.

• Record progress

Coverage should be 100%. If not, and there is a reason, please make a note on the table. If coverage is not 100% push this back to needs more work to find out why.

Not sure why I assigned this to myself…

Approved.

In T207862#4788643, @Gilles wrote:

Doesn't work, I see nothing in hive and this happens a bunch:

• Making the toggle a link maximises the number of users that we support (all browsers can follow a hyperlink).
• When investigating whether we can fetch the content of the talk page via an API (making it more a tab switch than a link follow), please consider that the mobileview API is intended to be deprecated (see T186627: Remove the MobileView API)
• What happens to the talk overlay in this treatment?

/cc @Tbayer