iBet uBet web content aggregator. Adding the entire web to your favor.
iBet uBet web content aggregator. Adding the entire web to your favor.



Link to original content: https://phabricator.wikimedia.org/T306229
⚓ T306229 Prevent the edit, history, more tabs from dancing at lower resolutions
Page MenuHomePhabricator

Prevent the edit, history, more tabs from dancing at lower resolutions
Closed, ResolvedPublic2 Estimated Story Points

Description

Both legacy vector and vector 2022 use the collapsibleTabs.js plugin to animate the tabs to different positions at smaller viewport widths and when the tabs would otherwise overlap:

https://jmp.sh/OK8dlrU

The animation causes our visual regression tests to wait 1.5 seconds before taking a snapshot which slows down the tests and the animation can be relatively buggy.

The use of JavaScript and animating the tabs also means that the UI is unpredictable, for example if the history label is longer in German than English Wikipedia, the history icon will move to the more menu at a different resolution.

This ticket proposes that we eliminate the code from modern Vector and use CSS breakpoints to make the decision about when to collapse. This will make the UI more predictable at different breakpoints, and will reduce our UI complexity and associated risk of UI regressions across projects

Acceptance Criteria

  • Animation code continues to work in legacy Vector
  • In modern Vector, we will use a CSS only solution. Menu items will collapse into the more (pcactions) dropdown similar to the user menu at lower resolutions
  • In modern Vector, gadgets will not collapse into the more menu automatically. Gadgets will need to explicitly add them to the more menu with the collapsing class if this behaviour is needed.
  • In modern Vector, gadgets added to the p-views menu when there is no available space will instead be added to the more dropdown

QA steps

Scenario 1

Go to a page where the more menu is hidden. Edit tab is present. Resize browser to 700px
Expected: a more menu should be displayed. Clicking more button should reveal the edit tab

Scenario 2

Go to a page where the more menu is displayed (you may need an account with admin rights). Edit tab should be present on page load.

  • Click more button to reveal admin action e.g. move / delete
  • Resize browser to 700px.

Expected: The edit button should jump from the tabs into the more menu.

QA Results - Prod

ACStatusDetails
1T306229#7926194
2T306229#7926194

Event Timeline

nray renamed this task from Prevent dancing tabs from dancing if `prefers-reduced-motion` to Prevent dancing tabs from dancing if `prefers-reduced-motion` is `reduce`.Apr 15 2022, 12:19 AM

Change 784332 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/skins/Vector@master] Disable animations when user prefers reduced motion

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

Change 786404 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/skins/Vector@master] Disable animations: Part 2

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

Change 787063 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/skins/Vector@master] Remove dancing tabs

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

Change 786404 abandoned by Jdlrobson:

[mediawiki/skins/Vector@master] Disable animations: Part 2

Reason:

Taking a different approach now: https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/787063

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

Change 787063 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Remove dancing tabs with CSS only solution

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

bwang moved this task from Code Review to QA on the Web-Team-Backlog (Kanbanana-FY-2021-22) board.

@Jdlrobson I think the description and AC needs to be updated here with the new behavior

Jdlrobson renamed this task from Prevent dancing tabs from dancing if `prefers-reduced-motion` is `reduce` to Prevent dancing tabs from dancing.Apr 28 2022, 6:40 PM
Jdlrobson updated the task description. (Show Details)
Jdlrobson moved this task from QA to Code Review on the Web-Team-Backlog (Kanbanana-FY-2021-22) board.
Jdlrobson added a subscriber: Edtadros.
Jdlrobson renamed this task from Prevent dancing tabs from dancing to Prevent the edit, history, more tabs from dancing at lower resolutions.May 2 2022, 6:58 PM
Jdlrobson updated the task description. (Show Details)

This can now be tested on beta cluster and compared with production.

this looks like it's working as expected.

@ovasileva to clarify, this change means that for people with screens below 720px all of the tabs on the right will be collapsed into a menu:

above 720pxbelow 720px
Screen Shot 2022-05-04 at 3.03.11 PM.png (550×1 px, 321 KB)
Screen Shot 2022-05-04 at 3.03.32 PM.png (572×697 px, 286 KB)

i'm flagging this because of our recent conversations regarding editors using narrow screens. @Jdlrobson and I discussed the possibility of ensuring that certain tabs (e.g. Edit and History) are always visible.

cc @Quiddity

Related note: I recently learned about
https://meta.wikimedia.org/wiki/MoreMenu#Menus_jumping_on_page_load
which uses the code at
https://meta.wikimedia.org/wiki/MediaWiki:Gadget-MoreMenu-pagestyles.en.css (and for other languages)
to prevent the jumping. I've been fairly happily using that for the last few months.
I'm not sure if anyone else uses it, as a search seems to come up empty(??) and I load it via my user-CSS in a browser-addon (to get it on non-SUL wikis), but @MusikAnimal (author) may know more.

this looks like it's working as expected.

@ovasileva to clarify, this change means that for people with screens below 720px all of the tabs on the right will be collapsed into a menu:

above 720pxbelow 720px
Screen Shot 2022-05-04 at 3.03.11 PM.png (550×1 px, 321 KB)
Screen Shot 2022-05-04 at 3.03.32 PM.png (572×697 px, 286 KB)

i'm flagging this because of our recent conversations regarding editors using narrow screens. @Jdlrobson and I discussed the possibility of ensuring that certain tabs (e.g. Edit and History) are always visible.

+1 to this. We've gotten strong indication that editors use narrow screens fairly frequently and these tabs should be visible to them. @alexhollender_WMF , @Jdlrobson - what are our next steps here? Should we treat bringing the tabs back as part of this task or a follow-up ticket?

cc @Quiddity

Test Result - Prod

Status: ✅ PASS
Environment: enwiki
OS: macOS Monterey
Browser: Chrome
Device: MBP
Emulated Device:NA

Test Artifact(s):

QA Steps

@ovasileva , these look like a pass, but nothing really happens at 800px. Let me know if this is as expected.

Scenario 1
Go to a page where the more menu is hidden. Edit tab is present. Resize browser to 800px
✅ AC1: Expected: a more menu should be displayed. Clicking more button should reveal the edit tab

Screen Recording 2022-05-12 at 3.57.58 PM.mov.gif (834×798 px, 3 MB)

Scenario 2
Go to a page where the more menu is displayed (you may need an account with admin rights). Edit tab should be present on page load.

Click more button to reveal admin action e.g. move / delete
Resize browser to 800px.
✅ AC2: Expected: The edit button should jump from the tabs into the more menu.

Screen Recording 2022-05-12 at 3.59.18 PM.mov.gif (834×798 px, 3 MB)

Jdlrobson updated the task description. (Show Details)

Sorry @Edtadros there were bad QA steps. Try 700px instead of 800px.

Looks good, resolving!