Confirmed in Chrome (76.0.3809.100) on macOS Mojave (10.14.6) in production.

In T225768#5402985, @nray wrote:

Padding is restored

When saving, I was not given the option to see or edit the section in the summary.

In T228794#5413723, @phuedx wrote:

Unfortunately, I can find no such API.

In T228794#5412294, @Jhernandez wrote:

• There is no structured diff data API because of performance reasons. The diffing modules used in production are C++ code that generates HTML directly. Fun times.

In T229875#5396278, @Jdlrobson wrote:

We shouldn't add <meta name="viewport" content="width=device-width, user-scalable=no, initial-scale=1, shrink-to-fit=no"> to Vector. When Monobook did that it annoyed a lot of people and I wouldn't advise it as it seems many users use Vector on their mobile devices exactly because they don't want a responsive layout.

In T225213#5394727, @Jdlrobson wrote:

for non-JS users requires an extra page load.

Remember menu usage is very low (https://grafana.wikimedia.org/d/000000566/overview?panelId=22&fullscreen&orgId=1 logs events for 50% of all page views). Most people don't interact with the main menu. They want to read the article.

Firstly, forgive the lateness of my reply and also if I've missed any discussion of this task (or the more general topic) while I've been away.

I'm not against disabling the instrumentation for now (but keeping the dataset per T229042#5370440), given the… alarmingly high event rate. To be clear, disabling the instrumentation must include not sending it to the client.

Per T220016#5385166 and T228681#5388069.

@Jdlrobson's change above will need to be merged, deployed to the Beta Cluster, and deployed to the production servers. Since we're confident that this is effectively a NOOP change (the new instrumentation is working as expected – see T228681#5388069 above), the change can be deployed at any time provided that this is communicated in #wikimedia-operations.

In T229399#5385954, @alexhollender wrote:

@Jdlrobson @phuedx I just checked production in Safari/MacOS and I can't reproduce this issue. Would it make sense to spend our time elsewhere? I feel like we're over investing in a very minor bug.

Correct. Those prefixes must be added by whatever application is proxying our content.

In T216063#5328423, @Milimetric wrote:

These failures are expected, though, the spec does not account for such prefixes, it just expects an encoded JSON blob. Is this something the client has no control over somehow? Actually, yeah, how are these URLs even generated?

Note also that the above might fix T229399: [Bug] [AMC] 1px gap at bottom of page actions without download icon (due to font size usage) too.

This looks great to me 💪 Excellent work everyone!

In T214540#5354758, @alexhollender wrote:

As you suggest, I agree it'd be a great idea to persist that styling while the menu is open, cc @Jdrewniak. I will create a task for that.

LGTM 💪 I tested this on the BC as did @Edtadros in T228278#5378507. The patch will be deployed to group0 wikis tomorrow.

LGTM 💪

The changes and the QA LGTM and I'd be happy to sign this off. However, the changes will be deployed to enwiki this Thursday so I'm inclined to wait and double-check the page in production.

Per T220016#5377322. Alternatively, I'm happy to sign this off and create an "enable the instrumentation" task.

I clarified with @pmiazga that it's expected that we're not sending seen events for UI elements yet. That is, we're tracking UI element interactions as we were before.

@Edtadros has started working on this here (viewable by those with a @wikimedia.org email address).

I did some digging on this task during today's chores. Here's what I think I know:

In the last 24 hour period, 11 more ReadingDepth events with odd URLs have caused processing errors. See https://logstash.wikimedia.org/goto/dbe9713837e22a6d5a0d64f09fae1ec2. For these events, the QSON is terminated as we expect but it's prefixed with either iorg_domain_internal=... or operator_user=....

In T226164#5300813, @Jdlrobson wrote:

Noise in EventLogging should be considered a high priority to fix as it creates problems for all people working with our infrastructure, so I suggest we fix this sooner rather than later.

In today's grooming ritual, we wondered aloud whether the MinervaPageActions config is actually needed – it was but is it still?

In T221695#5298411, @Jdlrobson wrote:

@phuedx @JoeWalsh it would be great if we could determine some kind of process for making these change requests with support from community liasons to get them to the correct people.

In T217142#5295424, @Tgr wrote:

• tags (which contain lots of useful information such as MediaWiki version, language, skin...) are handled extremely poorly by kibana in their current format. They should be converted into top-level properties (preferably with field names matching those in PHP errors so that Kibana visualisations / saved searches can be reused). Not sure what's the right place for that: client, EventGate, logstash filter? (The last one has its own domain language so it would be the most painful to maintain.)

Following on from @DIKW_Pyramid's comment above:

In T220558#5217741, @Niedzielski wrote:

Can we use MediaWiki API caching instead and drop the cache?

Could we also consider moving the Wikimedia-specific instrumentation for the main menu into the WikimediaEvents extension?

As I mentioned in today's grooming, there's a whole bunch of (now overly-complicated) machinery that we created in order to defer the parsing/DOM construction for the main menu as it's the very top element in #mw-mf-viewport. I think that reevaluating this machinery is well worth it!

I think this could be as simple as adding the following rules:

Is the level of specificity of some of the example CSS rules required, e.g. .mw-rcfilters-ui-filterTagMultiselectWidget-views-select-widget.oo-ui-widget.oo-ui-widget-enabled.oo-ui-selectWidget.oo-ui-selectWidget-unpressed.oo-ui-selectWidget-depressed.oo-ui-buttonSelectWidget ?

… gIven that the bugs are minor.