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

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.

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

In terms of approaches we decided that "implement separate navigation functionality for mobile" would be the better option.

@jsn.sherman TBH, I am not sure what the task is - is this supposed to change something for the end user look/fee;/experience? If so, are there any design docs? Is this a code change trying to combine tab.js with mobile.js? Is it that any time a use clicks something under their selected preference the end user goes directly there? Or, is our logic design out of place with the current logic flow?

This may show my ignorance, but:
Testing and QA steps
Log in to a Wikipedia account OK
Navigate to the sidebar and select Settings I see no settings, perhaps prefernces?
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.

In T321330#8460437, @ERayfield wrote:

@jsn.sherman TBH, I am not sure what the task is - is this supposed to change something for the end user look/fee;/experience? If so, are there any design docs? Is this a code change trying to combine tab.js with mobile.js? Is it that any time a use clicks something under their selected preference the end user goes directly there? Or, is our logic design out of place with the current logic flow?

The Description section of the task lays out the desired behaviour - is something there unclear?

This may show my ignorance, but:
Testing and QA steps
Log in to a Wikipedia account OK
Navigate to the sidebar and select Settings I see no settings, perhaps prefernces?

The settings link is in the sidebar, which can be opened by selecting the hamburger menu:

@Samwalton9 - just following the steps as laid out - perhaps
Log in to a Wikipedia account OK
Navigate to the top left of page and click hamburger menu
Select Settings
yadaydayada

Insofar as the Description

In various places in the MediaWiki interface anchored links are used to link to specific preference sections and settings.

This seems very general, to me. I would feel much better about this if these were explicitly listed

@ERayfield are you accessing the mobile site? I think that's the trip up here. The settings menu is mobile only. I'll update the description to specify the mobile site.

In T321330#8460463, @ERayfield wrote:

In various places in the MediaWiki interface anchored links are used to link to specific preference sections and settings.

This seems very general, to me. I would feel much better about this if these were explicitly listed

I'm not sure how to generate a list of all the links, they're in various extensions and around the MediaWiki interface. Maybe there's a way to codesearch for them?

In T321330#8460493, @jsn.sherman wrote:

@ERayfield are you accessing the mobile site? I think that's the trip up here. The settings menu is mobile only. I'll update the description to specify the mobile site.

Oh, yep, good catch!

Change 845048 abandoned by Jsn.sherman:

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

Reason:

used for learning

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

Greetings,I am moving this ticket back to ready so that another engineer can pick up as I will be going on break today for the holidays.

As mentioned earlier in the ticket, we be porting logic from tabs.js to detect a (#) hash in the URL and scroll to view the intended hashed section.

Here is the code below from tabs.js. that will detect the hash:

		// Jump to correct section as indicated by the hash.
		// This function is called onload and onhashchange.
		function detectHash() {
			var hash = location.hash;
			if ( /^#mw-prefsection-[\w]+$/.test( hash ) ) {
				mw.storage.session.remove( 'mwpreferences-prevTab' );
				switchPrefTab( hash.slice( 1 ) );
			} else if ( /^#mw-[\w-]+$/.test( hash ) ) {
				var matchedElement = document.getElementById( hash.slice( 1 ) );
				var $parentSection = $( matchedElement ).closest( '.mw-prefs-section-fieldset' );
				if ( $parentSection.length ) {
					mw.storage.session.remove( 'mwpreferences-prevTab' );
					// Switch to proper tab and scroll to selected item.
					switchPrefTab( $parentSection.attr( 'id' ), true );
					matchedElement.scrollIntoView();
				}
			}
		}

		$( window ).on( 'hashchange', function () {
			var hash = location.hash;
			if ( /^#mw-[\w-]+/.test( hash ) ) {
				detectHash();
			} else if ( hash === '' ) {
				switchPrefTab( 'mw-prefsection-personal', true );
			}
		} )
			// Run the function immediately to select the proper tab on startup.
			.trigger( 'hashchange' );

I would also like to note that helper methods switchPrefTab() and onTabPanelSet() will need to be refactored to load the proper section into view.

	function switchPrefTab( name, noHash ) {
			if ( noHash ) {
				switchingNoHash = true;
			}
			tabs.setTabPanel( name );
			enhancePanel( tabs.getCurrentTabPanel() );
			if ( noHash ) {
				switchingNoHash = false;
			}
		}

	function onTabPanelSet( panel ) {
			if ( switchingNoHash ) {
				return;
			}
			// Handle hash manually to prevent jumping,
			// therefore save and restore scrollTop to prevent jumping.
			var scrollTop = $( window ).scrollTop();
			// Changing the hash apparently causes keyboard focus to be lost?
			// Save and restore it. This makes no sense though.
			var active = document.activeElement;
			location.hash = '#' + panel.getName();
			if ( active ) {
				active.focus();
			}
			$( window ).scrollTop( scrollTop );
		}

I'm looking through these files and understand why this is tricky. Right now, we have the variable useMobileLayout but it is only used in init.js to choose between tabs.js and mobile.js. Assuming it is true, only mobile.js is loaded. Previously, useMobileLayout was loaded in both tabs.js and mobile to js to determine what code to use. Jason's approach would have us moving all the code to tabs.js with useMobileLayout switching between the two display options. I can see his point around maintainability, but it does introduce a lot of complexity into that file and tabs.js could become too heavy. In addition, it is hard to extricate the hash change logic from tabs. Note this comment was edited to consolidate it with the ones below it, which is why they were deleted.

A few thoughts on ways forward:

• Could we call this *vertical* layout instead of *mobile*? I suggest this because that makes it more usable in other contexts/devices in the future, if for any reason others would rather use this (beautiful) new layout.
• With this approach, I'd suggest pulling the code that handles hashes into a separate file. As I looked at this before break, the issue--with either consolidating files or separating them--is that the hash code is very specific to the tab layout right now and would need reworking to incorporate the newly optimized vertical menu. If we pull the hash code out, the trick too is to trigger the desired behavior in the other files.
• How hard would it be to rewrite preferences in codex? That's ultimately going to be more supportable, and might allow us to restructure the code to address some of these concerns. If that was actually doable within a week, it might be worthwhile. It is not simple to rewrite this in codex right now because they are still working on allowing server-side rendering.

In T321330#8495386, @mepps wrote:

A few thoughts on ways forward:

• Could we call this *vertical* layout instead of *mobile*? I suggest this because that makes it more usable in other contexts/devices in the future, if for any reason others would rather use this (beautiful) new layout.

That thought has occurred to me as well. If we were going to rename it, I'd vote for "stacked" since that's the name of the layout component we're using. We'd need to rename hooks & and update implementations in extensions, which is monotonous but not difficult. If we do want to rename it, March is our cutoff for the hook becoming stable.

• With this approach, I'd suggest pulling the code that handles hashes into a separate file. As I looked at this before break, the issue--with either consolidating files or separating them--is that the hash code is very specific to the tab layout right now and would need reworking to incorporate the newly optimized vertical menu. If we pull the hash code out, the trick too is to trigger the desired behavior in the other files.

I like this thinking. There are a few different parts of the hash navigation:

• the hash detection could easily be layout agnostic
• the section selection (either tabs or dialogs) is layout specific
• the subsection scrolling could easily be layout agnostic

• How hard would it be to rewrite preferences in codex? That's ultimately going to be more supportable, and might allow us to restructure the code to address some of these concerns. If that was actually doable within a week, it might be worthwhile. It is not simple to rewrite this in codex right now because they are still working on allowing server-side rendering.

100%

Change 876016 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/876016

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

I've factored out most of the anchor handling to nav.js and tried to make the code in the layout-specific modules as straightforward as possible.

Hi @jsn.sherman! I have been reviewing your change request on Gerrit and have a couple of comments and questions:

1. I noticed that the hash is not added when you change sections in the mobile layout as it is on the desktop layout. Is this the intended behavior?

Mobile behavior

Desktop behavior

2. Whenever I refresh the desktop layout with a highlighted hash, the subsection of the hash disappears. I don't think this is the intended behavior.

In T321330#8511518, @Scardenasmolinar wrote:

Hi @jsn.sherman! I have been reviewing your change request on Gerrit and have a couple of comments and questions:

1. I noticed that the hash is not added when you change sections in the mobile layout as it is on the desktop layout. Is this the intended behavior?

Leaving it out was intentional, but perhaps wrong. Basically, I just decided not to worry about it since it's not strictly necessary for anchor navigation to work. But I can see how it would be confusing for users trying to make new links from mobile. I'll give it a go!

In T321330#8511556, @Scardenasmolinar wrote:

2. Whenever I refresh the desktop layout with a highlighted hash, the subsection of the hash disappears. I don't think this is the intended behavior.

That is certainly a bug.

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

Test wiki on Patch demo by JSherman (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/459fff1f2c/w/

Test wiki on Patch demo by JSherman (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/d0e46d4ccb/w/

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

Test wiki on Patch demo by JSherman (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/92f8be31a1/w/

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

I believe I have this in good working order now:
mobile:
https://patchdemo.wmflabs.org/wikis/b6c1d6155b/w/index.php?title=Special:Preferences&mobileaction=toggle_view_mobile#mw-prefsection-rendering-math
desktop:
https://patchdemo.wmflabs.org/wikis/b6c1d6155b/w/index.php?title=Special:Preferences&mobileaction=toggle_view_desktop#mw-prefsection-rendering-math

Testing this in a browser, I'm sometimes not reaching the specific setting being targeted. mw-prefsection-rendering-math, for example (https://patchdemo.wmflabs.org/wikis/b6c1d6155b/wiki/Special:Preferences#mw-prefsection-rendering-math) takes me here sometimes:

It seemed to work as intended on my actual mobile though, so I suspect this might just be a browser emulation issue.

I also tested the editor help panel, which is the preferences link that prompted this task in the first place, and that worked as intended!

@Samwalton9 I noticed that the dev tools panel seemed to mess up the vertical offset sometimes. Does it happen when your dev tools are broken out into a separate window?

In T321330#8535076, @jsn.sherman wrote:

@Samwalton9 I noticed that the dev tools panel seemed to mess up the vertical offset sometimes. Does it happen when your dev tools are broken out into a separate window?

Definitely seems more reliable when dev tools are in a 2nd window - couldn't reproduce the issue.

@jsn.sherman I have verified the QA Steps and Acceptance Criteria listed in the ticket Description is working as described.

Change 876016 merged by jenkins-bot:

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

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

Test wiki on Patch demo by JSherman (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/3914adebe9/w/

Test wiki on Patch demo by JSherman (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/b6c1d6155b/w/

This is not fully resolved, see T341816 for the followup ticket.