Confirmed in Chrome (76.0.3809.100) on macOS Mojave (10.14.6) in production.
Thu, Aug 15
When saving, I was not given the option to see or edit the section in the summary.
Wed, Aug 14
Mon, Aug 12
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.
Wed, Aug 7
Mon, Aug 5
@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.
Fri, Aug 2
Thu, Aug 1
Correct. Those prefixes must be added by whatever application is proxying our content.
Wed, Jul 31
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!
Tue, Jul 30
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.
Jul 4 2019
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=....
Jul 2 2019
In today's grooming ritual, we wondered aloud whether the MinervaPageActions config is actually needed – it was but is it still?
Jul 1 2019
Jun 27 2019
Following on from @DIKW_Pyramid's comment above:
Jun 25 2019
Jun 20 2019
Jun 19 2019
Jun 18 2019
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!
Jun 11 2019
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 ?
Jun 7 2019
… gIven that the bugs are minor.