Page MenuHomePhabricator

Build collapsible sidebar and sidebar button
Closed, ResolvedPublic8 Estimated Story Points

Assigned To
Authored By
ovasileva
Feb 28 2020, 9:33 AM
Tokens
"Like" token, awarded by Jdlrobson.

Description

Background

We would like to give users the ability to collapse the sidebar. This task will contain the building of the sidebar and sidebar buttons.

Acceptance criteria

NOTE: this task will involve building the button and collapsing the sidebar only. Expected behavior here would be for the width to expand to the full size of the screen. We will follow this task up with T247038: Design spec for collapsible sidebar where we will be building the fixed width. In addition, requirements for sidebar persistence for logged-in users are tracked in T246427: [Spike 8hrs] Decide how to persist state of collapsible sidebar across sessions for logged-in users, logged-out users

Note on default states

INITIAL STATE: sidebar is default on for all users
EVENTUAL STATE: sidebar is default off for anons, default on for all other users

Designs & prototype

sidebar closedsidebar open
image.png (760×1 px, 526 KB)
image.png (760×1 px, 565 KB)
Prototypes

https://people.wikimedia.org/~jdrewniak/dip/p3.html#/en/wiki/Main_Page
http://patchdemo.wmflabs.org/wikis/24b6fd1f6a50fc53846f92f943ce79a4/w/ (Code: GitHub - commits of layout | GitHub - usermenu | Gerrit - squash)

Persistence of of open/closed sidebar state
  • For all users sidebar state should persist across pageviews (i.e. if I go from one article/page to another, in the same browser tab)
  • For logged-in users sidebar state should also persist across sessions (i.e. if I close the browser tab, and then open a new one)
  • For logged-out users every session should start with the sidebar closed
Sticky/fixed sidebar

To begin with the sidebar will not be fixed/sticky alongside the content, because doing so creates a slightly more complicated two column interface and we don’t want to make access to language links more difficult. Once we’ve moved language links we can revisit this behavior.

Open/close trigger/icon

TBD based on closer review of feedback, however considering something like

sidebar closed (hamburger icon)sidebar open (<< icon)
image.png (400×520 px, 72 KB)
image.png (400×520 px, 90 KB)

Icon svg: [coming soon!]

Requirements

  • Don't break Korean Wikipedia. Maybe we can expose the skin version preference and only run the collapsible gadget if mw.config.get( 'vectorSkinVersion' ) !== '2'. We should document how we approach this so we don't accidentally break any API exposed.
  • We could use the logic in Popups for NavigationPopups existence and default to old Vector when the gadget is enabled.

References

Developer notes

Use of CSS checkbox hack seems preferable here as it requires HTML + CSS only changes.

POC implementation

Pure css with the checkbox trick: GitHub - latest | Gerrit - old

Preliminary QA

Explore sidebar functionality on the beta cluster and confirm functions in the following circumstances:

  • a variety of screen sizes
  • a variety of browsers
  • at least one rtl language
  • the history page
  • the recent changes page
  • an article page

QA Results - Beta

QA Results - Prod

Details

SubjectRepoBranchLines +/-
mediawiki/skins/Vectormaster+5 -0
oojs/uimaster+14 -0
mediawiki/coremaster+295 -0
mediawiki/skins/Vectormaster+2 -2
mediawiki/skins/Vectormaster+53 -7
mediawiki/skins/Vectormaster+272 -14
mediawiki/skins/Vectormaster+17 -34
mediawiki/skins/Vectormaster+14 -11
mediawiki/skins/Vectormaster+1 -1
mediawiki/skins/Vectormaster+4 -2
mediawiki/skins/Vectormaster+4 -5
mediawiki/skins/Vectormaster+39 -27
mediawiki/skins/Vectormaster+25 -5
mediawiki/skins/Vectormaster+77 -3
mediawiki/skins/Vectormaster+7 -7
mediawiki/skins/Vectormaster+6 -0
mediawiki/skins/Vectormaster+29 -14
mediawiki/skins/Vectormaster+8 -11
mediawiki/skins/Vectormaster+47 -49
Show related patches Customize query in gerrit

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Change 596533 merged by jenkins-bot:
[mediawiki/skins/Vector@master] [dev][Legacy] split sidebar Mustache and Less

https://gerrit.wikimedia.org/r/596533

Chatted with Alex. Here are the initial interests for a button: grey hover, blue focus, no checked state.

Here are the initial interests for a button: grey hover, blue focus, no checked state.

Will be new patch. Not done yet.

All other feedback addressed. Thanks, @Jdlrobson and @Volker_E!

Here are the initial interests for a button: grey hover, blue focus, no checked state.

Not done yet.

All other feedback addressed.

Change 597312 had a related patch set uploaded (by Niedzielski; owner: Stephen Niedzielski):
[mediawiki/skins/Vector@master] [button] add hover state to menu button

https://gerrit.wikimedia.org/r/597312

@alexhollender, latest is now on labs. Patch is pending your approval.

@alexhollender, latest is now on labs. Patch is pending your approval.

My apologies for not bringing this up when we chatted the other day but the icons are rendering too large. Currently they are 24x24px but should be 20x20px. Also the hover area doesn't quite match what we have in Minerva (highlight color and shape).

Minervastaging
Screen Shot 2020-05-20 at 12.08.36 PM.png (158×282 px, 3 KB)
Screen Shot 2020-05-20 at 12.11.14 PM.png (123×135 px, 4 KB)

@alexhollender all icons in desktop are 24x24 as we never upstreamed the changes we made for Minerva to Vector. Doing that is a little risky as it impacts everything using icons in Vector. Let's check in with @Volker_E but I suggest tackling the 24x24 > 20x20 icon change as a separate patchset.

@alexhollender all icons in desktop are 24x24 as we never upstreamed the changes we made for Minerva to Vector. Doing that is a little risky as it impacts everything using icons in Vector. Let's check in with @Volker_E but I suggest tackling the 24x24 > 20x20 icon change as a separate patchset.

I'm seeing various sizes, including 20x20px, in Vector

Screen Shot 2020-05-20 at 12.24.09 PM.png (137×335 px, 24 KB)
Screen Shot 2020-05-20 at 12.23.57 PM.png (103×328 px, 12 KB)
Screen Shot 2020-05-20 at 12.24.25 PM.png (199×317 px, 27 KB)
Screen Shot 2020-05-20 at 12.24.18 PM.png (66×146 px, 10 KB)
In T246419#6152946, @alexhollender wrote:

@alexhollender all icons in desktop are 24x24 as we never upstreamed the changes we made for Minerva to Vector. Doing that is a little risky as it impacts everything using icons in Vector. Let's check in with @Volker_E but I suggest tackling the 24x24 > 20x20 icon change as a separate patchset.

I'm seeing various sizes, including 20x20px, in Vector

Screen Shot 2020-05-20 at 12.24.09 PM.png (137×335 px, 24 KB)
Screen Shot 2020-05-20 at 12.23.57 PM.png (103×328 px, 12 KB)
Screen Shot 2020-05-20 at 12.24.25 PM.png (199×317 px, 27 KB)
Screen Shot 2020-05-20 at 12.24.18 PM.png (66×146 px, 10 KB)

Sorry I should have qualified that better - OOUI icons and custom icons are not impacted, however icons with the mw-ui-icon class are 24x24. We can't use ooui here (too much of a performance penalty) and we're trying to be good mediawiki citizens by not adding to technical debt by making yet another custom icon.

Sorry I should have qualified that better - OOUI icons and custom icons are not impacted, however icons with the mw-ui-icon class are 24x24. We can't use ooui here (too much of a performance penalty) and we're trying to be good mediawiki citizens by not adding to technical debt by making yet another custom icon.

I see. Can you show or tell me where those 24x24px icons are in Vector? I'm not able to find them.

Thankfully doesn't look like too many of the icons are inconsistent, given low usage of this library outside mobile. Looks like the following are inconsistent.

Hover in Popups:

Screen Shot 2020-05-20 at 11.57.44 AM.png (672×894 px, 177 KB)

https://en.wikipedia.org/wiki/File:Flag_of_Spain.svg

Screen Shot 2020-05-20 at 11.58.13 AM.png (270×1 px, 42 KB)

Change 589692 merged by jenkins-bot:
[mediawiki/core@master] mediawiki.page.ready: add checkbox hack JavaScript

https://gerrit.wikimedia.org/r/589692

Collapse icon with lowered precision, yet perfect rendering:

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" width="20" height="20" viewBox="0 0 20 20">
	<title>
		collapse
	</title>
	<path d="M9 2l1.3 1.3L3.7 10l6.6 6.7L9 18l-8-8 8-8zm8.5 0L19 3.3 12.2 10l6.7 6.7-1.4 1.3-8-8 8-8z"/>
</svg>

Change 597312 abandoned by Niedzielski:
[button] add hover state to menu button

Reason:
Folded into preceding commit Ic9d54de7e19ef8d5dfd703d95a45b78c0aaf791a

https://gerrit.wikimedia.org/r/597312

@Niedzielski wow, looking awesome! Nice job with the spacing : ) Where are you getting the background color for the hover state from? In Minerva it looks like we're using background-color: rgba(0,0,0,0.03);, which looks good to me.

background-color: rgba(0,0,0,0.03);

This is from OOUI / wikimedia-ui-base, @background-color-frameless--hover / @wmui-color-base90 and is rgba( 0, 24, 73, 7/255 ).

Latest is up on Labs.

ovasileva updated the task description. (Show Details)

Change 584694 merged by jenkins-bot:
[mediawiki/skins/Vector@master] [feature] add menu button to toggle panel visibility

https://gerrit.wikimedia.org/r/584694

This is the status quo in positioning:

image.png (862×1 px, 152 KB)
The icon should be vertically-aligned with the sidebar contents what I can see in the screens, but also be a lil bit further up IMO. @alexhollender?!

Change 599151 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/skins/Vector@master] Vertically align menu icon with sidebar contents

https://gerrit.wikimedia.org/r/599151

Change 599151 merged by jenkins-bot:
[mediawiki/skins/Vector@master] Horizontally and vertically align menu icon to design templates

https://gerrit.wikimedia.org/r/599151

Change 599431 had a related patch set uploaded (by Niedzielski; owner: Stephen Niedzielski):
[mediawiki/skins/Vector@master] [fix][Less] disable sidebar animations on page load

https://gerrit.wikimedia.org/r/599431

Sorry, my bad. Went missing in an unrelated merge.

@margin-top-header comes from @import './layout.less'; – we make a difference in these two paths, comparing @import 'checkboxHack.less'; We use @margin-top-header and @height-logo-icon from Sidebar.less

@Volker_E Yes, I've renamed it to @padding-top-header in the personal menu vertical alignment patch, that better suits theming (user styles), which issue I've explained in great length. Different file (Sidebar.less) was changed, so there was no hint of the inconsistency and I didn't notice in the diff.

@Niedzielski for accessibility reasons a few users set the browser font-size to big values, like 150% or even 200% of the default 16px. For them the sidebar icon looks like this:

sidebar-icon-2em-squashed.png (245×492 px, 17 KB)

The icon is squashed vertically. The following CSS rule demonstrates it: body { font-size: 2em; }
The Logo is also disproportionate, that's a different topic: T246170

@Niedzielski - following up on the defaults - so currently, the default is sidebar off for both logged-in and logged-out users. We'd want it to be default on, as per the acceptance criteria (with the possibility for different defaults when logged-in/logged-out). Maybe we should pull this out into a separate task?

Change 599938 had a related patch set uploaded (by Niedzielski; owner: Stephen Niedzielski):
[mediawiki/skins/Vector@master] [fix][a11y][Less] use pixel dimensions for sidebar button

https://gerrit.wikimedia.org/r/599938

Change 599939 had a related patch set uploaded (by Niedzielski; owner: Stephen Niedzielski):
[mediawiki/skins/Vector@master] [config] Change the sidebar's default state to open

https://gerrit.wikimedia.org/r/599939

Thanks for updating the AC. Just to make sure I got this right, on = visible, off = hidden?

Legacy mode:

  • No change

Latest mode:

  • INITIAL STATE: sidebar is default visible for all users
  • EVENTUAL STATE: sidebar is default hidden for anons, default visible for all other users

If so, I need to quickly flip the default state. Patch is here.

(with the possibility for different defaults when logged-in/logged-out). Maybe we should pull this out into a separate task?

Yes, please.


For the broader Legacy vs Latest mode, I'm aware of this detail on a per wiki basis:

  • Logged in
    • New account initialization state (saved as a preference, once it is set for a given account, we can't unset it)
    • Existing account defaults (not saved as a preference, just a default at runtime)
  • Anonymous

Additionally:

  • No support built in for bucketing users into different default states.
  • If a user sets a global preference, I believe it will have effect on all wikis whether the experience is intended to be deployed there or not.
  • The presentation of the user preference for skin version can be controlled per wiki independently of the user's preference state.

For the collapsible sidebar specifically:

  • If the default skin is vector and the default skin version is Latest on a given wiki, the user preference for skin version doesn't matter but the collapsible sidebar state still does depending on the persistence approach taken.
  • Collapsible sidebar only works in Latest mode. If the default state for a wiki isn't Latest, the sidebar is unavailable for anons regardless of the persistence approach taken.
  • The sidebar impacts page content width behavior (T246420) depending on screen size but screen size never impacts sidebar state.
  • I think everything else is currently accounted for in @Jdrewniak's deck.

Is any of this surprising or incorrect?


Other work:

  • There's a patch to fix a known animation bug in Chrome we had hoped wouldn't occur but Nick, Volker, and Edward can all repro.
  • The icon sizing is incorrect for different browser font sizes (T246419#6175184). I've pushed a patch to use pixel values instead. There's history here so I'll need @Volker_E or @Jdrewniak to advise.

Have replied on patch, we want to ensure that icons are user-scalable. Have to provide further guidance on MediaWiki and the Design Style Guide, but it's a pretty clear guidance when to rely on ems and when not – everything that leads to recognizability should be scalable, distances etc. can be set in px.

With the patch overhauled the result

image.png (558×2 px, 129 KB)
Also clearly indicating how the old behaviour is hurting folks with user text increase preference

Thank you, @Volker_E and @Demian. I didn't notice it before but I think the dropdown mehr arrow should be larger too.

This is outside of the current ticket but I just want to say that I think describing what not to do and why can be invaluable context, especially given the status quo. I don't know if you agree but I think it could be added as supplemental information to the Design Style Guide.

Change 600012 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/skins/Vector@master] Fix misconception on icon coloring

https://gerrit.wikimedia.org/r/600012

Change 599938 merged by jenkins-bot:
[mediawiki/skins/Vector@master] [fix][a11y][Less] use percentage for sidebar button icon size

https://gerrit.wikimedia.org/r/599938

Change 599939 merged by jenkins-bot:
[mediawiki/skins/Vector@master] [config] Change the sidebar's default state to open

https://gerrit.wikimedia.org/r/599939

Test Result - Beta

Status: ⬜ In Progress
*Environment: beta
OS: macOS Catalina
Browser: Chrome, Safari, Firefox
Device: MBP
Emulated Device:** NA

Test Artifact(s):

QA steps

Execute the tests for each of the following scenarios

  • a variety of screen sizes: Screen size didn't appear to have an effect.
  • a variety of browsers: Tested on Safari, Chrome, and Firefox
  • at least one rtl language
  • the history page
  • the recent changes page
  • an article page

AC1: For all users, sidebar state should persist across pageviews (i.e. if I go from one article/page to another, in the same browser tab)
✅ Screen size didn't appear to have an effect.
✅ Tested on Safari, Chrome, and Firefox with no noticeable difference.
❌ Tested on Hebrew. RTL failed when Sidebar was collapsed.

ויקיפדיה.gif (480×566 px, 3 MB)

❌ The History page did not work for when the Sidebar was collapsed
ezgif.com-optimize (1).gif (480×566 px, 2 MB)

❌ The recent changes page
ezgif.com-optimize (2).gif (480×566 px, 2 MB)

✅ an article page

AC2: For logged-in users sidebar state should also persist across sessions (i.e. if I close the browser tab, and then open a new one)
In progress

AC3: For logged-out users every session should start with the sidebar closed
In progress

Change 601548 had a related patch set uploaded (by Niedzielski; owner: Stephen Niedzielski):
[mediawiki/skins/Vector@master] [fix][RTL] flip menu collapse button icon

https://gerrit.wikimedia.org/r/601548

❌ Tested on Hebrew. RTL failed when Sidebar was collapsed.

That was a big bug on my part. Thank you for catching this before it became an issue I've proposed an RTL icon collapse icon fix in this patch.

❌ The History page did not work for when the Sidebar was collapsed

I was able to reproduce this page on Dog. It was a caching issue caused by the recent flip of the default sidebar state (see T246419#6177744). I resolved it by purging https://en.wikipedia.beta.wmflabs.org/wiki/Dog?action=purge. Can you try once more, please? If you see it on another page, you may need to purge it too. It is a very good reminder that we don't want to change the default state in prod for anons. Persistence is covered by T246427.

❌ The recent changes page

Is this the persistence issue you're noting? That's T246427.

AC2: For logged-in users sidebar state should also persist across sessions (i.e. if I close the browser tab, and then open a new one)

That's T246427 and not part of this task AFAIK.

AC3: For logged-out users every session should start with the sidebar closed

I think this is for a future task? The task also says "INITIAL STATE: sidebar is default visible for all users".

Thank you, @Edward!

@Niedzielski regarding your note on the History page above I tried the following (all as anon) on the Hooded Skunk page.

Navigating with the sidebar expanded without purging.

  • The sidebar collapses (as you expected)
  • The sidebar expands when I view history

Selenium Echo mention test 0.764427149542747 - Wikipedia, the free encyclopedia.gif (388×458 px, 3 MB)

Navigating with the sidebar expanded and with purging.

  • sidebar stays expanded when I view the article
  • sidebar stays expanded with I view History

I am on the _Selenium mobile watched page test 1560966488476 - Wikipedia.gif (388×458 px, 2 MB)

Navigating with the sidebar collapsed and with purging.

  • sidebar gets expanded at the purge prompt
  • sidebar stays expanded when I view the article
  • sidebar stays expanded with I view History

BeforeEach-name-0.8389990794104814-Iñtërnâtiônàlizætiøn - Wikipedia, the free encyclopedia.gif (358×448 px, 2 MB)

As far as AC2 and AC3, I went based on the task description. @ovasileva thoughts?

As far as AC2 and AC3, I went based on the task description. @ovasileva thoughts?

What Stephen said - there's a note for this in the description, but reading it again, I can see that it's a bit confusing. I think we're good for now. Thank you!

@Niedzielski - sorry for the late reply - yes, this is all correct - details/thoughts per line below. TLDR: the only use case we want to account for is logged-in/logged-out at this time with the caveat for new accounts that we can use later on if necessary.

Thanks for updating the AC. Just to make sure I got this right, on = visible, off = hidden?

Legacy mode:

  • No change

Latest mode:

  • INITIAL STATE: sidebar is default visible for all users
  • EVENTUAL STATE: sidebar is default hidden for anons, default visible for all other users

If so, I need to quickly flip the default state. Patch is here.

Yup - just needs a flip. This was actually always in the acceptance criteria, but I see that it might have been a bit unclear - I bolded it to make it more apparent and added the additional comment ;)

(with the possibility for different defaults when logged-in/logged-out). Maybe we should pull this out into a separate task?

Yes, please.

Will do.

For the broader Legacy vs Latest mode, I'm aware of this detail on a per wiki basis:

  • Logged in
    • New account initialization state (saved as a preference, once it is set for a given account, we can't unset it)
    • Existing account defaults (not saved as a preference, just a default at runtime)
  • Anonymous

Additionally:

  • No support built in for bucketing users into different default states.
  • If a user sets a global preference, I believe it will have effect on all wikis whether the experience is intended to be deployed there or not.

This is expected, but leaving a note that perhaps we should add to QA to verify that it is happening.

  • The presentation of the user preference for skin version can be controlled per wiki independently of the user's preference state.

Yup. Noting that this is a bit confusing because theoretically you have a setting on every wiki but it actually sets it globally, but it's not a major concern.

For the collapsible sidebar specifically:

  • If the default skin is vector and the default skin version is Latest on a given wiki, the user preference for skin version doesn't matter but the collapsible sidebar state still does depending on the persistence approach taken.
  • Collapsible sidebar only works in Latest mode. If the default state for a wiki isn't Latest, the sidebar is unavailable for anons regardless of the persistence approach taken.
  • The sidebar impacts page content width behavior (T246420) depending on screen size but screen size never impacts sidebar state.
  • I think everything else is currently accounted for in @Jdrewniak's deck.

Is any of this surprising or incorrect?

Correct on all counts :)

Change 600012 merged by jenkins-bot:
[mediawiki/skins/Vector@master] Fix misconception on icon coloring

https://gerrit.wikimedia.org/r/600012

Change 602192 had a related patch set uploaded (by Niedzielski; owner: Stephen Niedzielski):
[mediawiki/skins/Vector@master] [fix][dev] use "skin" module for JavaScript, not "Vector"

https://gerrit.wikimedia.org/r/602192

@ovasileva is the testing in T246419#6183825 and T246419#6183578 sufficient for Beta? If so I'll document and test in a prod wiki.

Change 601548 merged by jenkins-bot:
[mediawiki/skins/Vector@master] [fix][RTL] flip menu collapse button icon

https://gerrit.wikimedia.org/r/601548

@ovasileva is the testing in T246419#6183825 and T246419#6183578 sufficient for Beta? If so I'll document and test in a prod wiki.

Yup, sounds good.

So far as I know, this is the last patch needed for this task. The patch works around a six year old Chrome bug wherein the drawer flickers on every pageview (although I think this only happens when the default state is closed so it may not currently be visible on the Beta-Cluster).

@ovasileva, this patch has had thoughtful feedback from @nray, @Jdrewniak, @Volker_E, and @Jdlrobson each which so far as I know boils the options down to:

  1. Merge this patch and commit to prioritizing the work identified in T254399.
  2. Abandon the patch and accept the flicker issue.
  3. Postpone the patch and start on T254399.

So far as I know, this is the last patch needed for this task. The patch works around a six year old Chrome bug wherein the drawer flickers on every pageview (although I think this only happens when the default state is closed so it may not currently be visible on the Beta-Cluster).

@ovasileva, this patch has had thoughtful feedback from @nray, @Jdrewniak, @Volker_E, and @Jdlrobson each which so far as I know boils the options down to:

  1. Merge this patch and commit to prioritizing the work identified in T254399.

Since we already have the patch and the follow-up task created, it seems this is the most reasonable way forward that also gives us an intermediate fix

Change 599431 merged by jenkins-bot:
[mediawiki/skins/Vector@master] [fix][Less] disable sidebar animations on page load

https://gerrit.wikimedia.org/r/599431

@Edtadros, remaining QA work so far as I know is:

Test Result - Beta

Status: ✅ PASS
Environment: beta
OS: macOS Catalina
Browser: Chrome, Firefox, Safari
Device: MBP
Emulated Device: NA

Test Artifact(s):

QA steps

✅ AC1: a variety of screen sizes: See T246419#6183578
✅ AC2: a variety of browsers: See T246419#6183578
✅ AC3: at least one rtl language

en.wikipedia.beta.wmflabs.org_wiki_Hooded_skunk_useskinversion=2&uselang=he(iPad Pro).png (2×2 px, 1 MB)

✅ AC4: the history page: The persistence issues in T246419#6183825 are covered by this task→ T246427.
✅ AC5: the recent changes page: The persistence issues in T246419#6183578 are covered by this task→ T246427.
✅ AC6: an article page
en.wikipedia.beta.wmflabs.org_wiki_Conflict-title-0.0018239960460395555-I%C3%B1t%C3%ABrn%C3%A2ti%C3%B4n%C3%A0liz%C3%A6ti%C3%B8n_useskinversion=2(iPad Pro).png (2×2 px, 519 KB)

Test Result - Prod

Status: ✅ PASS
Environment: enwiki/hewiki
OS: macOS Catalina
Browser: Chrome, Firefox, Safari
Device: MBP
Emulated Device: NA

Test Artifact(s):

QA steps

✅ AC1: a variety of screen sizes
✅ AC2: a variety of browsers: Verified on Chrome, Safari, and Firefox
✅ AC3: at least one rtl language

he.wikipedia.org_wiki_%D7%9E%D7%99%D7%A9%D7%9C_%D7%90%D7%95%D7%91%D7%9E%D7%94_useskinversion=2&uselang=he(iPad Pro).png (2×2 px, 1 MB)

✅ AC4: the history page
en.wikipedia.org_w_index.php_title=Hooded_skunk&action=history&useskinversion=2(iPad Pro).png (2×2 px, 1 MB)

✅ AC5: the recent changes page: The persistence issues in T246419#6183578 are covered by this task→ T246427.
en.wikipedia.org_wiki_Special_RecentChanges_hidebots=1&hidecategorization=1&hideWikibase=1&limit=50&days=7&urlversion=2&useskinversion=2(iPad Pro).png (2×2 px, 1003 KB)

✅ AC6: an article page
en.wikipedia.org_wiki_Twinings_Museum_useskinversion=2(iPad Pro).png (2×2 px, 1 MB)

ovasileva updated the task description. (Show Details)

All acceptance criteria is met - this feels ready to close

Change 602192 abandoned by Jdlrobson:
[fix][dev] use "skin" module for JavaScript, not "Vector"

Reason:
I would prefer to go down the route of https://gerrit.wikimedia.org/r/#/c/mediawiki/core/ /605641 - if that's merged I'll do the required follow up in Vector.

https://gerrit.wikimedia.org/r/602192