Page MenuHomePhabricator

Fix anchored links in new mobile preferences design
Open, MediumPublic

Description

User Story

As a mobile-first editor, I want anchored links to take me straight to the relevant section of Special:Preferences, so that I don't waste time finding the linked preference.

Description

In various places in the MediaWiki interface anchored links are used to link to specific preference sections and settings. One example is the Growth editor help panel, which links to https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-personal-homepage on the English Wikipedia. This takes users to a specific section and highlights the relevant preference.

This functionality is broken in the new mobile interface, and should be reinstated. The relevant section should open, with highlighting as in the desktop interface.

An example that should work in Patch Demo is Special:Preferences#mw-prefsection-editing-preview

Technical information

Desktop anchor navigation is provided by resources/src/mediawiki.special.preferences.ooui/tabs.js which we're skipping in mobile.
Essentially, that code:

  • grabs the location hash ( such as #mw-prefsection-editing-preview)
  • feeds it to a function, which
    • opens the appropriate tab (which is a top-level prefs section), then
    • scrolls to correct subsection within the tab

Other considerations:

  • The structure of the form and the way we navigate between sections is currently under development (for example T317106: Present Preferences submenus as full-screen modals), so for effective use of our time this task should happen after we have greater confidence that the form structure is settled.
  • We should do an accessibility check on the mobile form, which might also impact the form structure. In my exploratory work (https://gerrit.wikimedia.org/r/c/mediawiki/core/+/845048/), where I noodled around with the idea of updating our mobile form structure to match the desktop closely enough for the code to work. I noticed that we're using fieldsets differently from desktop (which impacts navigation) and that's what brought up this question in my mind.

Possible Approaches:

  • update our form and the existing tabs.js code so that desktop and mobile navigation code is in one place.
    • This is the jason-preferred approach for separation of concerns and maintainability, and might help us ask the right questions about what we're doing (such as the above accessibility concerns) ahead of full rollout
  • implement separate navigation functionality for mobile
    • This would be a lighter lift in the near term

Files in play

  • mobile form markup includes/specials/forms/PreferencesFormOOUI.php
  • current anchor navigation js resources/src/mediawiki.special.preferences.ooui/tabs.js
  • mobile js (if we decide to implement mobile-specific nav code) resources/src/mediawiki.special.preferences.ooui/mobile.js
  • init.js (if we decide to always load navigation js) resources/src/mediawiki.special.preferences.ooui/init.js

Testing and QA steps

  • Log in to a Wikipedia account
  • Navigate to the sidebar and select Settings
  • Turn on Advanced mode
  • Click 'Open preferences' in Settings
  • Create and select a link which navigates you to Special:Preferences#mw-prefsection-editing-preview
  • The Editing submenu should open, scrolling you to the 'Preview' heading.

Acceptance criteria

  • Clicking a link to an anchored preference from a mobile device/account using the new Preferences design should take you to that specific submenu and preference

Event Timeline

Samwalton9 triaged this task as Medium priority.Oct 20 2022, 4:46 PM
Samwalton9 moved this task from Preferences to Kanban on the Moderator-Tools-Team board.

this functionality is provided by resources/src/mediawiki.special.preferences.ooui/tabs.js which we're mostly skipping in mobile. I'm investigating the best approach to navigate our pref sections the same way.

Change 845048 had a related patch set uploaded (by Jsn.sherman; author: Jsn.sherman):

[mediawiki/core@master] [WIP] Special:Preferences fix mobilelayout anchors

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

Test wiki created on Patch demo by JSherman (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/3914adebe9/w

Samwalton9 updated the task description. (Show Details)

Realised I gave an unhelpful example link, since it relies on an extension. I believe Special:Preferences#mw-prefsection-editing-preview should work on a new install, e.g. in Patch Demo.

Update with a little more context of what I've been thinking about on this task:

the name tabs.js is a bit misleading. Really, that module is responsible for supporting navigation of the preferences form, which used to only contain a tabpanel layout. The code there is complex, but is really designed around ooui layouts where we have plain html elements in the stacked layout. I've been reworking the structure of our vertical menu to allow tabs.js to meet the needs of both layouts as much as possible.
Our mobile.js code for preferences is handling things like swapping sections in and out of display, and registering event listeners as native js. OOUI provides multiple options for managing the visibility of elements, and also provides listeners at various points in the lifecycle. If we can use them, I think it will be good for @eigyan and I to look at this and T317106: Present Preferences submenus as full-screen modals together.

jsn.sherman changed the task status from In Progress to Stalled.Oct 31 2022, 2:54 PM

Setting to stalled until we've had a look at how we need to restructure preferences to support T317106.

jsn.sherman updated the task description. (Show Details)
jsn.sherman moved this task from In Progress to Ready on the Moderator-Tools-Team (Kanban) board.
jsn.sherman added a subscriber: jsn.sherman.

@eigyan @ERayfield
I think this task is ready for estimation. If you have any questions or concerns, please pose them here.

Samwalton9 changed the task status from Stalled to Open.Tue, Dec 6, 3:11 PM