@alexhollender Any thoughts on how the text should behave here (e.g. ellipsis vs. hidden vs. wrapping, etc)?

@phuedx https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikimediaEvents/+/668530 has been updated to handle the private salt. I'm putting this back in code review for your review

Per your thread on Slack, AIUI you'll need to add a config variable to MediaWiki-extensions-WikimediaEvents, e.g. $wgWMEVectorPrefDiffSalt and use it where you're currently using $wgSecretKey. If you're happy with the suggested name, then we can ask in #wikimedia-sre to get the value generated and the variable added to the private repo.

Update on the status of this ticket:

Thank you for the update @ovasileva!

Congratulations @cjming! Usually once the ticket has been merged, you'd ensure QA steps have been written and move the ticket to the "Needs QA" column for Edward to review but since this patch involves minimal risk, I think this can be safely moved to the sign off column instead

^^ lol Sorry for the spam on this ticket. Was demonstrating the gerrit workflow to Clare :)

While estimating today, we decided we need to clarify with Megan if we are only tracking number of clicks or do we also need to know the number of users clicking the links (and therefore a user identifier becomes important)

@Volker_E @ovasileva Any preference on what the title attribute should say? I'm thinking this might be a good task for Clare or Bernard

Assigning this to @cjming since it will get her more familiar with the WVUI project (including its setup) and the gerrit workflow

@Edtadros There was a patch on this ticket that was reverted, modified, and then merged again so please follow the same QA steps you did in https://phabricator.wikimedia.org/T218835#6912461 to make sure everything is still working

In T261842#6929759, @Krinkle wrote:

PrefUpdate only emitted when a preference is changed. When a new user is created or when a user is using a wiki day-to-day where a default was changed, this would not emit PrefUpdate just as much as it would not emit this new instrumentation, right? So by being emitted that seems like it is the signal you're looking for. If it changes "back" to the default then you know it is a choice and not the default-default since in that case there would not be an event.

@Mholloway Sorry for the delay on that, I will for sure review it today after I get done with meetings

@MNeisler @ovasileva and I had a meeting this week in which we decided to drop the proposed "defaultState" field, in favor of only sending the initial and final state of the skin in each event. An example of such event would look like (please note the before and after fields that log the skin state and vector2 denoting a switch from latest vector to minerva):

This error may have spiked back up according to the latest graphs:

Thank you for your interest! It looks like this issue is reproducible in our WVUI repository and can be seen with the TypeaheadSearch component on Storybook although I had to manually change the .sb-typeahead-search container to width: 200px in order to see it:

I didn't see any significant red flags in the QA results so I'm moving this to sign off. To whoever signs this off, the following comment might help recap the work that was done on this ticket:

Thank you for looking at this @Edtadros . I've had a good time looking at your provided JSON profiles, and it looks like the discrepancies between your results (where most of the Vue metrics are faster than legacy) and the dashboard (where Vue metrics are slower than legacy) could be explained by network fluctuations and the timing of the "a" keypress:

This might be a good task for Clare or Bernard to work on

Sorry, forgot to assign to @MNeisler yesterday

Moving this to blocked per my question above (https://phabricator.wikimedia.org/T261842#6899225) regarding whether A is sufficient in which we would always send the current state of the config for each event (the easiest option) or whether we should pursue B

@MNeisler Thank you for clarifying! That helped clear up a lot for me.

Moving to QA but as mentioned in the QA steps, this one is probably best done by a dev

This is ready for qa, I just need to write qa steps

@MNeisler I'm still fuzzy on what is desired with this ticket and was hoping you could shed some light on the following questions I have:

@Mholloway From my understanding, I think at least part of the problem is that the default setting for the property we are interested in, VectorSkinVersion, is dependent on context and is not static like most other user properties. That is, its default value is dependent on whether the user is a newly created user or an existing user and the values of two related config variables in Vector - VectorDefaultSkinVersionForExistingAccounts and VectorDefaultSkinVersionForNewAccounts [1].

^^ New patch points tests to frwiki since it is a production wiki with wvui search enabled and because beta has (oddly) stopped showing search suggestions unless an exact match has been typed

To recap the work that was done in this ticket which might aid in sign off:

• Chores are updated to include the new dashboards