Page MenuHomePhabricator

Hide article toolbar/tab-bar if there is only one item/tab
Open, MediumPublic3 Estimated Story Points

Description

NOTE: if you have feedback on this feature you are invited to share it on https://www.mediawiki.org/wiki/Talk:Reading/Web/Desktop_Improvements. This task should only be used for discussing implementation.
NOTE: The tab can be restored with the following gadget/user script: var sp = mw.config.get('wgCanonicalSpecialPageName'); if ( sp ) { mw.util.addPortletLink('p-associated-pages', mw.util.getUrl(sp), 'Special page' ); }

Description

For pages where there is only one item/tab in the article toolbar/tab-bar we should hide the article toolbar/tab-bar. Example:

currenthidden
image.png (1×2 px, 302 KB)
Screen Shot 2022-07-20 at 9.28.02 AM.png (759×1 px, 221 KB)

Open questions

Some gadgets show in that toolbar/tab-bar area on certain special pages (e.g. Twinkle). How do we want to handle this?

  • Show the toolbar/tab-bar?
  • Work with gadget authors to re-locate the position of the gadget on special pages?

image.png (1×2 px, 2 MB)

QA steps

Screen Shot 2022-09-01 at 1.40.59 PM.png (1×1 px, 303 KB)

Screen Shot 2022-09-01 at 1.41.43 PM.png (250×1 px, 40 KB)

Event Timeline

ovasileva triaged this task as Medium priority.Jul 20 2022, 1:37 PM

Please provide or indicate how you propose to handle gadgets like Twinkle which have a home in that space on special pages.

Screenshot_2022-07-20-09-26-55-82_3aea4af51f236e4932235fdada7d1643.jpg (170×1 px, 52 KB)

Please provide or indicate how you propose to handle gadgets like Twinkle which have a home in that space on special pages.

{F35326846}

thanks for raising this @Izno. to clarify your point I've highlighted the tab-bar and the twinkle gadget.
I've updated the task description to include: if someone has a gadget installed that shows in that space the tab-bar should still appear. one of the developers on our team will be able to speak to possible approaches here.

This work should be blocked on T313349 as presumably, we want this to be limited to the new Vector and not older skins.

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

[mediawiki/skins/Vector@master] Enable related tabs on Vector

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

Estimated today. I'll provide some feedback to @Izno regarding his comment in T313409#8091755 - these should continue to work. The menu will still exist but will have zero items. I will confirm this by end of week with some code.

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

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

Visit https://patchdemo.wmflabs.org/wikis/9fbff0695f/wiki/Special:RecentChanges?useskin=vector-2022 and you'll see the special tab is gone.
A new link can be added via mw.util.addPortletLink('p-associatedPages', '#', 'new link')

I realize this is a change, as it means anyone referencing p-namespace would now need to reference p-associatedPages instead. It looks like that would impact around 466 different scripts, which is pretty low, but non-zero:
https://global-search.toolforge.org/?q=%5C%23p-namespaces&regex=1&namespaces=&title=.*%5C.%28css%7Cjs%29

I updated the patch to retain compatibility and log warnings to gadgets. I suggest we remove this within the next few months:
https://patchdemo.wmflabs.org/wikis/67ef013455/wiki/Special:RecentChanges?useskin=vector-2022

The following code works just as before:

mw.util.addPortletLink('p-namespaces', '#', 'new link')

Sound like a plan?

Still working this out. Specifically need to work out the behaviour with T316169 and other existing namespaces e.g. the translate tab in Extension:Translate and https://en.wikipedia.org/wiki/Special:CollabPad/Test, TimedMediaHandler (for TimedText files), and https://en.wikipedia.org/wiki/Special:Homepage

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

[mediawiki/core@master] SkinTemplate: Make associatedPages menu backwards compatible with namespaces

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

Please provide or indicate how you propose to handle gadgets like Twinkle which have a home in that space on special pages.

Screenshot_2022-07-20-09-26-55-82_3aea4af51f236e4932235fdada7d1643.jpg (170×1 px, 52 KB)

See also:

Screenshot (1×779 px, 129 KB)
capture.png (274×1 px, 24 KB)

I've just tested htem and perf menu and CVN overlay both work perfectly fine with the proposed changes.

Change 828047 merged by jenkins-bot:

[mediawiki/core@master] SkinTemplate: Make associatedPages menu backwards compatible with namespaces

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

Change 816209 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Enable related tabs on Vector

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

cjming moved this task from Code Review to QA on the Readers-Web-Backlog (Kanbanana-2022-23-Q1) board.
cjming added a subscriber: cjming.
Jdlrobson updated the task description. (Show Details)

One use-case that I commonly have for the single tab, is to reset a Special page back to its (or my) defaults. E.g.

  • I often open https://meta.wikimedia.org/wiki/Special:RecentChanges
  • and then change the/my default filters to see something specific
    • this automatically updates the address-bar URL (which is usually great!)
  • when I'm done, or if my tests weren't what I wanted, then instead of manually reverting each change, I click the Tab (which always points to the plain "Special:Foo" page instead of the parameterized version)

I'm not sure how widespread this workflow is (perhaps only me!) but thought I'd document it here.

@Quiddity thanks for sharing! I notice there's no "reset" button on Special:RecentChanges which might help with that particular workflow?

Re: reset-button – One complexity is that there are both system-defaults and personal-defaults, and I'm not sure which I'd expect a "reset" button to result in.
E.g. my volunteer-account's personal-default is this "saved filter"
https://meta.wikimedia.org/w/index.php?hidebots=1&translations=site%3Bfilter&hidecategorization=1&limit=50&days=7&enhanced=1&userExpLevel__unregistered_color=c4&userExpLevel__newcomer_color=c3&translations__site_color=c5&changeType__hidenewpages_color=c1&title=Special:RecentChanges&urlversion=2
whereas the logged-out-user (system) default is
https://meta.wikimedia.org/wiki/Special:RecentChanges?hidebots=1&translations=filter&hidecategorization=1&hideWikibase=1&limit=50&days=7&urlversion=2

(Another minor(?) use-case: to access that 2nd URL, I right-clicked on the single-tab and clicked "open in private window"! I'm very used to it being there!)

Thanks for posting this in the Tech News. I have a similar concern to Quiddity's (posted at Thu, Sep 1, 15:19). I often want to duplicate a page in a new tab (e.g. to compare a page that I am actively fixing or have sorted to the page as it is currently rendered), so I hold down the Command key (Mac OS) and click the tab for the page. Quick and easy. Removing this tab will break this workflow.

I see that there are workarounds, like continuing to use the page-width-friendly legacy Vector, but I thought I would mention this case. I use this trick dozens of times every day.

Gah. I'm religiously in favour of trimming away unneeded stuff in the UI (cf. T163098), but as I read the above comments I realise I rely on that behaviour too: for lots of pages I use the tab to get a "clean" (or just specific or predictable) version of the page, or a related page (i.e. talk vs. main vs. history etc.). And perhaps key here, not just on special pages. That is, if just special pages change (no tab but grow a reset button in the page-specific UI) I can't just retrain muscle memory, it'll end up being a constant impedance.

Not sure there's any actual solution to this; and not sure how big of an issue it'd be (or for how many; I imagine this workflow is pretty uncommon, but I could be wrong).

@Quiddity @Jonesey95 @Xover thanks for letting us know about these use cases. I'm wondering if it would be acceptable if we removed the tab, and instead made the special page title (e.g. "Recent changes", etc.) a link to the "base" version of the special page (and it could also be right-clicked to to duplicate a page in a new tab)?

Moving this to blocked so we can collect some feedback on whether people are running into more use cases this makes difficult.

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

[mediawiki/core@master] [POC] Special page tab is restored to all special pages

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

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

[mediawiki/core@master] Add tab to recent changes for resetting form

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

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

The new capability allows us to have more meaningful menus on these pages. My recommended solution would be to add a tab on RecentChanges with a more meaningful name then Special page (in example I've used "Filter").
https://patchdemo.wmflabs.org/wikis/5f60093644/wiki/Special:RecentChanges?useskin=vector-2022
Perhaps in future, saved filters could also go here to avoid the additional click?

Screen Shot 2022-09-08 at 8.35.58 AM.png (1×2 px, 307 KB)

Change 830888 abandoned by Jdlrobson:

[mediawiki/core@master] [POC] Special page tab is restored to all special pages

Reason:

Doesn't seem to be needed.

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

Change 830892 abandoned by Jdlrobson:

[mediawiki/core@master] [POC] Add tab to recent changes for resetting form

Reason:

Doesn't seem to be needed. Please open a new ticket and restore if so.

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