In T427074#11976243, @Samwalton9-WMF wrote:

Yeah sorry for the lack of design on this one :)

Is it feasible to pull the text up out of that grey area and into the header of the module (white area), under the title?

In the absence of any design, keeping this as a codex Message seems to make sense, and looks reasonable I think - is this what you had in mind @Samwalton9-WMF?

Deployed :)

[will be] resolved in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1285807 for T426040: Implement redesigned watchstar popover on desktop

In T426040#11914985, @IKhitron wrote:

I wouldn't do it this way, because it can be accidentally, but I understand why do you want it. Maybe better decision will be restart the timer instead of continuing, so the user would have enough time to pay attention and return inside the popover?

In T426040#11912846, @IKhitron wrote:

In T426040#11912514, @TheresNoTime wrote:

Have updated the description to reflect the timeout of 5 seconds

Thanks. As I already said, it's not enough IMHO. So could you instead add to the description that

• Clicking on any place inside the popover kills the timeout

please? This way if the user needs it, they can "freeze" the popover on the screen and think about the expiration time and the right labels, without being afraid it disappears every moment. Thank you.

In T426040#11912459, @IKhitron wrote:

Please clarify in the description:

• The "clicking anywhere off of the popover closes it" means that's it or, for example, clicking on a blank target link outside the popover will close it and also open the link in a new tab.
• How long are the timeouts.

Thank you.

nice, thank you! This was an interesting way of learning how our CI jobs work :)

In T425943#11907624, @Jdforrester-WMF wrote:

Copying what I said in a DM:

My only thought is whether to roll these extra dependencies into the php\d\d-compile images which are used by the same repos, and just run the run.sh command inline in the jjb instead?

Deployed

Introduced in rMWd465165996fa: Switch watchstar from Popover to Dialog (which was cherry picked to .26)

should be fine now but I'll keep an eye out for any issues

(with thanks to @taavi for the suggestion)

In T423778#11843342, @TheresNoTime wrote:

Just noting that I can't replicate this on https://en.wikipedia.beta.wmcloud.org/wiki/Test_watchlist_labels

Just noting that I can't replicate this on https://en.wikipedia.beta.wmcloud.org/wiki/Test_watchlist_labels

I looked over that TODO item and the chain of what has/hasn't been done got very confusing - I think this is an 'upstream' bug that we might not be best placed to resolve?

Resolved by T417134: Watchlist labels data appears in wrong place in group mode

This has been successfully deployed (in this patchset) after some issues

In T423100#11824542, @codenamenoreste wrote:

TheresNoTime (a deployer) told me on IRC that the patch might be delayed for now until possibly later today or probably tomorrow.

https://spiderpig.wikimedia.org/jobs/1758

As this will ride the train next week, we should probably ensure an entry is included in tech news (if it hasn't already - just trying to find that out)

In T419987#11722181, @Cparle wrote:

Yeah. Lower uptake than we were hoping for! Might be interesting to also run the query for users with over 1k pages in their watchlist?

All done - unsurprisingly enwiki had the most to process. No obvious errors in the logs.

group0 was uneventful - other than the already run testwikis (which had some operations when they first ran) there was only:

mediawikiwiki
-----------------------------------------------------------------
mediawikiwiki Fixing labels on talk pages for 1 watchlist items (batch 1).
mediawikiwiki Done.

Did a test run on testwiki(s) ^

Confirmed with @Samwilson that this can be run at any time now - I've created T420328: Run cleanupWatchlistLabelMember maintenance script for the run

Running my query with the new date of January 2026 brings it up to 1.63% - I guess that sounds nearer the truth?

The query finished:

In T416172#11700646, @Samwilson wrote:

When no items are found by the title search, the "You have no items on your watchlist" message is incorrectly shown. This should be a different message, e.g. "No items were found".

I really need to tidy up my localsettings.. managed to fix this and its working as expected :)

Good idea, I'll look at doing this

nb. passing the state back from Special:WatchlistLabels/edit to Special:WatchlistLabels when the redirect happens appears to be done elsewhere by using session-based state storage (looking at things like SpecialPreferences), so I'm going to follow that pattern

Raising to UBN per instructions at ci-test-error (WMF-deployed Build Failure)