Page MenuHomePhabricator

Assign watchlist labels via the watchstar
Open, Needs TriagePublic

Description

User Story:

Similar to the watchlist expiry time, it should be possible for a user to set the watchlist labels for a page after they've clicked the watchstar (or watch link, on skins without a star).

Details:

  • When selecting the Watch star, a popup opens, displaying Expiry and Labels fields.
  • This popover replaces the previous mw.notify notification.
  • The popover times out by itself after 5 seconds if not interacted with.
  • When selecting the Watch star, the page is immediately watched or unwatched, regardless of whether the user interacts with the popover.
  • The labels field is a MenuMultiselectLookup widget, with which it is possible to autocomplete on any of a user's watchlist labels. The labels are available from the action=userinfo API, and should not be loaded at page load time (note that the modules for the notification and popup are also not loaded, so they and the data can be loaded at the same time).
  • There will be a hyperlink from the watch popup to Special:WatchlistLabels.
  • Any number of labels will be able to be selected. As each is selected (i.e. its InfoChip appears) the set of labels is saved. This avoids the need for a 'save' button, and follows the behaviour of the expiry dropdown.
  • No new labels are able to be created from this place.
  • The action=watch API is updated to accept label IDs for assigning. T416291.
  • The action=watch page action is updated to show a new 'watchlist labels' field. T418547

Details for QA:

  • Should work in all supported skins.
  • No-JS flow should make sense and all features be usable.
  • Clicking the watchstar or menu triggers the loading of some extra ResourceLoader modules, and on slow connections this can be a noticeable delay. Some skins (e.g. Vector) indicate this by spinning the star.

Designs:

https://www.figma.com/design/CdyroPkkcT7GJA9bwno0Rq/WE1.4-Task-priotization?node-id=429-133223&t=OZMuLaAu0fF3Nofq-1 re

image.png (1,098×1,060 px, 269 KB)
image.png (384×862 px, 120 KB)
image.png (830×604 px, 123 KB)

Event Timeline

Samwilson renamed this task from Assign watchlist labels via the watchstar notification popup to Assign watchlist labels via the watchstar.Feb 27 2026, 1:57 AM
Samwilson updated the task description. (Show Details)

Now that we have a new design for this, I've updated the description above. The watchstar gets a dropdown menu containing the expiry, labels, and unwatch (although 'menu' might be the wrong word… I'm calling it a 'popup' in the description above, and that's what it's called in the code, but I'm not sure that there's a specific Codex component for this — it's halfway between a dialog and a popover, I think).

We'll make sure this works for skins that don't have a watchstar, or for when the link is in the tools menu (e.g. when $wgVectorUseIconWatch is false, or when MediaWiki-extensions-ReadingLists moves it there).

This plan of switching to two tab buttons (one the star, one the dropdown arrow for options) is not going terrifically well. These can't be one button (like the Tools menu) because then there's only one clicking target. I'm wondering if we can stay with one button (which may be the watchstar, or may be a link either in the tab bar or in the tools menu) and have the popover appear wherever the button/link is. Then, watching would still be a one-click process, but unwatching would be two clicks (whereas in the designs above it'd be possible to unwatch by clicking the solid star)? Does that sound okay? It's simpler, and works with existing Codex components.

Basically it'd be replicating the notification toast within a Codex popover, and adding the Unwatch button. It's simpler though, because we don't have to do all the extra handling that happens for the toast around clicking it or it auto-hiding itself.

The other aspect of removing the unwatch behaviour from the watchstar is that it'll become possible to view and change your labels or expiry without unwatching and rewatching.

Designs look fantastic! I agree however the button/chevron being separated might make the experience a little clunky, depending on workflows.

The existing notification will be simplified to just the confirmation message, and an 'Organise' button that opens the watchstar popup.

Will mw.notify also use Codex in this case, or are we loading both OOUI and Codex from a single action? Maybe not a big deal; We're all subject to having both running at some point or another through every day usage of MediaWiki, but I thought it was worth mentioning (if what I suspect is even true).

Clicking the watchstar or menu triggers the loading of some extra ResourceLoader modules, and on slow connections this can be a noticeable delay. Some skins (e.g. Vector) indicate this by spinning the star.

This worried me on the first read. If the dropdown and watch star are different actions, what happens while Codex is loading after clicking the chevron? Spin the star and go to the same state? Even if that does sound weird, I do think some loading indication is good.. Echo is perhaps a good example, where it simply grays out interaction as things are loading.

… I'm wondering if we can stay with one button (which may be the watchstar, or may be a link either in the tab bar or in the tools menu) and have the popover appear wherever the button/link is. Then, watching would still be a one-click process, but unwatching would be two clicks (whereas in the designs above it'd be possible to unwatch by clicking the solid star)? Does that sound okay? It's simpler, and works with existing Codex components.

That sounds sensible to me! A nice compromise whilst also complimenting what is probably the most usual workflow. That is, usually you want to watch and/or modify the expiry and labels. Unwatching is destructive so a two-step process makes sense, I think. I know I've (un)watched pages by accident before, but better to accidentally watch then unwatch.

The other aspect of removing the unwatch behaviour from the watchstar is that it'll become possible to view and change your labels or expiry without unwatching and rewatching.

Yes! I think there are probably a lot of people who have just gotten used to having to do this, myself included. So yeah, the behaviour you suggest with a "presume watch or modify expiry/labels" workflow is probably going to result in the fewest clicks on average, and possibly loading of fewer libs too and whatever energy saving costs that amounts to at the scale that is Wikimedia :)

Will mw.notify also use Codex in this case, or are we loading both OOUI and Codex from a single action?

My current approach is doing away with OOUI completely, and only using Codex (a popover containing two fields and a button). I don't think there's any point to the mw.notify toast, i.e. clicking the star will always open the options popover, so there's no need to have other info away in the corner of the screen. (Assuming we'll be getting rid of the two feature flags for expiry and labels, that is.)

This worried me on the first read. If the dropdown and watch star are different actions, what happens while Codex is loading after clicking the chevron? Spin the star and go to the same state? Even if that does sound weird, I do think some loading indication is good.. Echo is perhaps a good example, where it simply grays out interaction as things are loading.

Yeah, I wondered that too. I think if there's only one button, then spinning the star is fine (e.g. if a page is already watched, it'd spin the solid star, and it'd stay solid). On skins without a star we currently change to "Watching…"/"Unwatching…" etc and so perhaps that'd need a neutral "Loading…" message.

Regarding loading of modules, mediawiki.watchstar.widgets will be smaller because it'll not need OOUI, but an extra API request will need to be made to fetch the current expiry and lists of labels and expiries. If a page isn't watched, clicking will a) load the modules; b) submit the watch request; and c) fetch the labels and expiries. If it is already watched, then the middle request won't happen. To unwatch, a) and c) will happen, and then another request to unwatch. I'm not sure there's a neat way to do it in fewer requests, other than perhaps having action=watch return more info (i.e. the full list of labels and expiries).

Joy and I met earlier today to talk about this, and he's going to update the Figma designs with some new ideas. Mainly, moving to a single popover rather than a notification followed by a menu, and figuring out what the unwatch flow should be (if there's an unwatch button in the popover, clicking it will update the message and maybe turn into a watch button, but do the fields disappear at that point? they could perhaps be emptied and stay where they are… anyway I'm sure Joy will figure out all those bits). The half-star will not change, but there might be changes needed to the tooltip of the star (because clicking it when you're already watching a page will not unwatch the page as it does currently, but rather open the popover).

Here's a bit of an example (with wrong bits) of what it might look like:

2026-03-12 Watchlist labels popover.png (351×542 px, 43 KB)

Just a thought: the special page that opens when using action=watch in the URL — for example, by right-clicking the watchstar and choosing “Open in a new browser tab” — already has the labels mechanism. But action=unwatch just removes the page from the watchlist, which is not consistent with the popup behavior. Maybe it would be better to add an Undo button there to preserve and edit the labels.