Page MenuHomePhabricator

Vector 2010 doesn't display orange bar indicating a new user talk message to temporary accounts
Closed, DeclinedPublicBUG REPORT

Assigned To
None
Authored By
Novem_Linguae
Jul 8 2025, 4:02 AM
Referenced Files
F70083071: monobook.png
Nov 10 2025, 6:48 PM
F70083077: modern.png
Nov 10 2025, 6:48 PM
F70083070: vector.png
Nov 10 2025, 6:48 PM
F70083068: timeless.png
Nov 10 2025, 6:48 PM
F70005456: Screenshot 2025-11-07 at 10.19.54 AM.png
Nov 10 2025, 5:14 PM
F70005443: Screenshot 2025-11-07 at 10.19.10 AM.png
Nov 10 2025, 5:14 PM
F66015159: screenshot.png
Sep 12 2025, 11:43 AM
F63417382: image.png
Jul 8 2025, 4:02 AM

Description

Steps to replicate the issue (include links if applicable):

  • set default skin to vector 2010
  • in browser 1, make an edit, triggering the creation of a temporary account
  • in browser 2, log in as admin, then go post on browser 1's talk page
  • in browser 1, visit the main page

What happens?:

  • no orange bar at top indicating that a user talk message has been received

image.png (386×1 px, 55 KB)

What should have happened instead?:

  • orange bar at top indicating that a user talk message has been received

image.png (347×1 px, 54 KB)

Software version (on Special:Version page; skip for WMF-hosted wikis like Wikipedia):

Other information (browser name/version, screenshots, etc.):

  • This could become an issue for third party wikis that keep Vector 2010 as their default skin and upgrade to the latest version of MediaWiki.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Jdlrobson-WMF subscribed.

To set expectations there will be no significant feature development on legacy Vector by WMF staff (as a general rule: no feature development on non-default skins).

Pppery subscribed.

Leaving https://en.wikipedia.org/w/index.php?title=Wikipedia:THEYCANTHEARYOU style bugs deliberately unfixed seems like a seriously unwise decision.

Leaving https://en.wikipedia.org/w/index.php?title=Wikipedia:THEYCANTHEARYOU style bugs deliberately unfixed seems like a seriously unwise decision.

Temporary users on Wikimedia production wikis will always be using Vector 2022 skin so I'm not 100% sure how this relates to Wikipedia:THEYCANTHEARYOU ?

To set expectations there will be no significant feature development on legacy Vector by WMF staff [...]

Unless a patch to fix this issue wouldn’t be accepted, though, that isn’t a reason to set the task as declined IIUC (xref https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle). (And if that is the case, I guess my question would be 'why would a patch to fix this bug not be accepted?')

Temporary users on Wikimedia production wikis will always be using Vector 2022 skin [...]

I could be wrong, but IIUC this could potentially be an issue for the Russian Wikipedia, if ruwiki's default skin is V2010 at the time of the its temporary account deployment. (xref T375046)

Russian Wikipedia will behave like every other wiki and temporary users will get Vector 2022 so no fix is needed for that wiki.

Unless a patch to fix this issue wouldn’t be accepted,

Any feature request to Vector is risky, so practically I think any patch is likely to sit in Gerrit for a long time and I want to spare a volunteer from wasting their time working on a patch for this ticket which will not be merged by the maintainers.

FWIW I did a little bit of looking into this, and it seems like this might have something to do with the MediaWiki-Core-Skin-Architecture (potentially more so than legacy Vector?).

I don't fully understand how things work at the moment, but SkinTemplate:injectLegacyMenusIntoPersonalTools seems to insert the 'notifications' items after the 'userpage' array key, but a link to the userpage isn't added when a temporary account is being used.
Modifying the code so that (if the userpage array key isn't set) it instead inserts the 'notifications' items before the mytalk array key seemed to resolve this for me locally. I can't speak to any side effects that this approach may/may not cause, though.

screenshot.png (93×547 px, 8 KB)

beware: hacky code [patch updated 2025-11-10]
diff --git a/includes/Skin/SkinTemplate.php b/includes/Skin/SkinTemplate.php
index e7d5cdc1f51..4d489e88b5c 100644
--- a/includes/Skin/SkinTemplate.php
+++ b/includes/Skin/SkinTemplate.php
@@ -1513,12 +1513,22 @@ class SkinTemplate extends Skin {
 		$userMenu = $contentNavigation['user-menu'] ?? [];
 		// userpage is only defined for logged-in users, and wfArrayInsertAfter requires the
 		// $after parameter to be a known key in the array.
-		if ( isset( $contentNavigation['user-menu']['userpage'] ) && isset( $contentNavigation['notifications'] ) ) {
-			$userMenu = wfArrayInsertAfter(
-				$userMenu,
-				$contentNavigation['notifications'],
-				'userpage'
-			);
+		if ( isset( $contentNavigation['notifications'] ) ) {
+				if ( isset( $contentNavigation['user-menu']['userpage'] ) ) {
+						$userMenu = wfArrayInsertAfter(
+								$userMenu,
+								$contentNavigation['notifications'],
+								'userpage'
+						);
+				} else if ( isset( $contentNavigation['user-menu']['mytalk'] ) ) {
+						$userMenuKeys = array_keys( $userMenu );
+						$userMenuKeyOffsets = array_flip( $userMenuKeys );
+						$userMenuMyTalkOffset = $userMenuKeyOffsets['mytalk'];
+
+						$userMenu = array_slice( $userMenu, 0, $userMenuMyTalkOffset, true )
+								+ $contentNavigation['notifications']
+								+ array_slice( $userMenu, $userMenuMyTalkOffset, count( $userMenu ) - $userMenuMyTalkOffset, true );
+				}
 		}
 		if ( isset( $contentNavigation['user-interface-preferences'] ) ) {
 			return array_merge(

@Jdlrobson-WMF Genuine question, given that this wouldn't involve a patch to Vector (legacy skin), what are your thoughts on reopening this task, with the idea that this bug be fixed by modifying this area of core code? Now that I've taken a look at it, it doesn't seem like it'd just be legacy Vector that this bug would be affecting, and TBH I share @Novem_Linguae's thoughts (in the task description) around the idea that this might well impact 3rd party wikis.

If this is correct it would likely mean that the fix for Vector 2022 wasn't done correctly (since Vector 2022 is working fine).

If we can prove that is the case then - yes - we can reconsider reopening this task with the framing along the lines of "When we fixed this bug for Vector 2022 we added technical debt rather than the simpler solution of addressing it in the core skin platform".

I haven't got the mental space (and I can't find the original bug report for Vector 2022) to verify whether this is correct or not but I can circle back in 2 weeks or so.

Thanks for the ping. I took another look and I my be mistaken but it seems that Echo notifications menu does not show up for temporary users using any skin other than Vector 2022 or Minerva. At least that's what I see when testing on test.wikipedia.org ? The orange bar seems to be tied to the Echo feature ( Notifications (Echo) ) so that's where any fix would need to live. There does not appear to be good technical documentation for the feature and how it should work without Echo and whether it is deliberate not to show notifications on older skins.

The code adding the new messages alert next to notifications is here unless I'm mistaken:
https://gerrit.wikimedia.org/g/mediawiki/extensions/Echo/+/56da46943cc4b8a8629295b128d30b7a57640282/includes/Hooks.php#882

Here's some screenshots of how it looks for a temporary user with talk page comments in different skins..

e.g. https://test.wikipedia.org/wiki/Testorienteerix?useskin=vector

Screenshot 2025-11-07 at 10.19.10 AM.png (1×3 px, 1 MB)

https://test.wikipedia.org/wiki/Testorienteerix?useskin=timeless
Screenshot 2025-11-07 at 10.19.54 AM.png (1×3 px, 868 KB)

Given the yellow bar does show up at the top of the article this might be acceptable for third parties (but no strong opinions here).

I took another look and I my be mistaken but it seems that Echo notifications menu does not show up for temporary users using any skin other than Vector 2022 or Minerva.

I'm pretty sure this is part of the bug here FWIW.

[...] whether it is deliberate not to show notifications on older skins.

Personally I would assume that it's not, given that I can see notifications on older skins while logged-in to a non-temporary account.

If it's okay, would you mind trying locally (with Echo also installed/loaded), applying the diff I pasted in T398905#11175764? I am very inexperienced here; but as far as I could tell, the fact that the notification bar isn't being inserted seems to be part of what might be causing the bug here (and, as best I could tell, the fact that the notification bar isn't being inserted into older skins seems to be [for some reason] as a result of the core code I posted a diff for).

If it's okay, would you mind trying locally (with Echo also installed/loaded), applying the diff I pasted in T398905#11175764?

I applied your diff and I can confirm the banners do not show with Echo uninstalled (not even in Vector 2022).

If it's okay, would you mind trying locally (with Echo also installed/loaded), applying the diff I pasted in T398905#11175764?

I applied your diff and I can confirm the banners do not show with Echo uninstalled (not even in Vector 2022).

Thanks for that but I'm confused - the diff I posted results in the 'new talk page message' banner / notification icons showing when using a temporary account, on a wiki with Echo installed. I provided it basically as a proof-of-concept that it seems to be mw/core code that's causing this bug, rather than code in V2010 (or necessarily Echo).
Why it's core code that's causing this bug I don't know, but AFAICS it does seem to be core code that's causing it.

Sorry to be clear your diff does not fix the issue with either Echo installed or Echo uninstalled. There is no bug here with legacy Vector or core. As far as I can see the issue is that Echo is now a requirement for the new talk orange bar to show. So to fix this Echo would need to add support for legacy skins.

Change #1203501 had a related patch set uploaded (by A smart kitten; author: A smart kitten):

[mediawiki/core@master] [DNM] Proof of concept - patch to mw/core to allow notification icons to be shown on legacy skins

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

I don't really know what to say, except that the diff I posted does seem to also fix the issue on a patch demo (https://568a59f193.catalyst.wmcloud.org/), when I made an edit using a temporary account & then appended ?useskin=timeless/?useskin=vector/?useskin=modern/?useskin=monobook to the end of the URL 🤷

timeless.png (511×1 px, 49 KB)
vector.png (376×1 px, 49 KB)
modern.png (305×1 px, 31 KB)
monobook.png (329×1 px, 48 KB)
timelessvector 2010modernmonobook

Okay my bad. Looks like I misapplied the diff since it was on a patch against old version.

Thanks for pushing the patch and patchdemo that's helpful. I guess my next question would be what changed to break this? This function hasn't changed since 2021. Surely this hasn't been broken since then?

I think there is still an open question about whether the Growth team as maintainers we want to support notifications on older skins.

For next steps, I'd suggest creating a new feature request for Notifications (Echo) posting your POC there and asking if it's intentional.

If it's unintentional I think it would be a good time to simplify this code so notifications are outputted by skins in the all the same way (by working on T409774: Deprecate legacy "personal" and "namespaces" menu from SkinTemplate). This code is ever so convoluted and I now see a deprecation note that is probably time to act on.

I guess my next question would be what changed to break this? This function hasn't changed since 2021. Surely this hasn't been broken since then?

I haven't tested previous versions, so I don't know for certain how long this has been broken on temp accounts for; but my root-cause assessment in T398905#11175764 (which I don't currently have a reason to think is now inaccurate) was:

[...] SkinTemplate:injectLegacyMenusIntoPersonalTools seems to insert the 'notifications' items after the 'userpage' array key, but a link to the userpage isn't added when a temporary account is being used.


I think there is still an open question about whether the Growth team as maintainers we want to support notifications on older skins.

For next steps, I'd suggest creating a new feature request for Notifications (Echo) posting your POC there and asking if it's intentional.

I don't have the energy to invest in opening a new task for this issue right now, but I'll cc the Growth PM here: @KStoller-WMF

Thanks for doing that, and apologies for not pushing the POC as a patch to Gerrit sooner - it probably would have kept things simpler if I had :)