| Tks4Fish | |
| Jan 27 2022, 5:43 PM |
| F34933310: zFZC.webm | |
| Jan 27 2022, 6:43 PM |
List of steps to reproduce: Try to delete any page on a wiki at .19 using old Vector
What happens?: The user is taken to new Vector, even if they were using the old one
What should have happened instead?: The user should stay on old vector
Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc.: 1.38.0-wmf.19, testwiki. Not reproduced at ptwiki (.18), Chrome. Screen capture at testwiki provided by @Urbanecm https://ctrlv.tv/zFZC
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | BUG REPORT | None | T300278 [regression] Deleting a page on old Vector takes you to new Vector | ||
| Resolved | Jdlrobson | T299927 Deploy new Vector skin to all projects | |||
| Resolved | Jdlrobson | T300052 Vector-2022-view-history message changed |
This is a very noticeable (and disruptive) regression in Vector (the most used skin as-of today, I think). Tentatively triaging as train blocker, feel free to remove if you don't think that's required.
This is not reproducible (as described) on MediaWiki.org (1.38.0-wmf.19) which should be same version as the Test wiki.
I'd say if all it does is make the UI look a bit strange after page deletion, there's no need to block the train.
Apologies I missed this in the shuffle earlier. I think I agree this shouldn't block the train today if it's only a single-pageview weirdness without other consequences, but it does seem like it'd be ideal to backport a fix.
I'm removing this as a blocker for now; if I'm mistaken and this is more disruptive to workflows than I think, please re-add.
Yes this shouldn't block the train. This might be related to the current skin migration I'm working on (T299927) so I'll look into this. Do we have any reports outside test wikipedia?
Note T299927 will be completed next week, so a backport is not likely urgent unless we hear that this is happening on a production wiki.
I can replicate this on test wikipedia but not locally.
My guess is that there is something going wrong with the user object in the deletion workflow on test.wikikipedia as this is only possible if a lookup on the 'VectorSkinVersion' fails.
The relevant code (simplified for readability is):
$userOptionsLookup->getOption( RequestContext::getMain()->getUser(), 'VectorSkinVersion', $config->get( 'VectorDefaultSkinVersionForExistingAccounts' ) // this is '2' for test.wikipedia.org );
Does test wikipedia have any hooks which interfere with RequestContext::getMain()->getUser() or any preferences set on it that are not running on the beta cluster ?
The good news is this will be fixed by next Thursday without any changes due to T299927.
This kind of corruption of global state is likely to have the same, or similar kind of, cause as T288113: Legacy Vector preferences not respected on pages that include special pages (eg. Special:PrefixIndex).