Similar to T381096: Hide the search form in the skin during login, signup, and other auth-domain workflows. These UI elements don't really make any sense during login, they only distract.

I think eventually we should switch to display=popup on all auth.wikimedia.org UIs. But while that's supported for login/signup today, it's not for a number of other things (password change, password reset, the OATHAuth managament form).

In T392337#10756331, @Tgr wrote:

These UI elements don't really make any sense during login, they only distract.

True; however, the notifications icons (to my knowledge) aren't displayed on the login page, because - at that point - there isn't anyone currently logged in (& I don't think the notification icons display when there’s no-one logged in? Happy to be proven wrong if they do sometimes display in that circumstance, though). However, in the situation where an already-logged-in end-user is attempting to create a new account, the user would (presumably) expect to have the same notification functionality available to them on Special:CreateAccount as they would on any other (special or non-special) page.

You can be logged in on the login page, just like you can be logged in on the signup page. (Although I just realized SUL3 breaks that - filed as T392359: Visiting Special:UserLogin to switch accounts doesn't work in SUL3.) Both are uncommon.

Realistically, I think this issue is not worth fixing - we don't want to enable unnecessary business logic on the auth domain, and we don't have a good way of interfering with the Echo popup logic from CentralAuth. I guess we could add a per-page disable flag or hook to Echo and use it in CentralAuth, but it seems too much effort for such a minor issue. As I said, in the longer term we probably want a much more pared-down login/signup experience, for a number of reasons (security, ease of use, ability to show in a popup, ability to eventually decouple from MediaWiki).

In T392337#10756759, @Tgr wrote:

You can be logged in on the login page, just like you can be logged in on the signup page. (Although I just realized SUL3 breaks that - filed as T392359: Visiting Special:UserLogin to switch accounts doesn't work in SUL3.) Both are uncommon.

Ah, thanks for pointing that out! :)

Realistically, I think this issue is not worth fixing - we don't want to enable unnecessary business logic on the auth domain, and we don't have a good way of interfering with the Echo popup logic from CentralAuth. I guess we could add a per-page disable flag or hook to Echo and use it in CentralAuth, but it seems too much effort for such a minor issue. As I said, in the longer term we probably want a much more pared-down login/signup experience, for a number of reasons (security, ease of use, ability to show in a popup, ability to eventually decouple from MediaWiki).

Fair enough - I’ll happily defer to you on the SUL3 side of things. I wonder if a change could be made on the Notifications (Echo) side of things, though, so that it doesn’t incorrectly display "there are no notifications" when the client-side JS hasn’t actually been able to retrieve an end-user’s notification status at all? (At a first idea, maybe it could display something like "Could not retrieve notification information" instead?) Or do you/Growth-Team also think that that might not be worth the effort? (/genuine question)

Change #1189376 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/Echo@master] Fix error handling in notifications popup

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

In T392337#11192228, @matmarex wrote:

In T392337#10756837, @A_smart_kitten wrote:

I wonder if a change could be made on the Notifications (Echo) side of things, though, so that it doesn’t incorrectly display "there are no notifications" when the client-side JS hasn’t actually been able to retrieve an end-user’s notification status at all? (At a first idea, maybe it could display something like "Could not retrieve notification information" instead?) Or do you/Growth-Team also think that that might not be worth the effort? (/genuine question)

It turns out that Echo already has code to do this, but it is not working correctly. It should say "Failed to fetch notifications". I think we can fix that and call it a day (or maybe file a follow-up for hiding the interface, if anyone wants).

Sounds good to me, thank you for the patch :)
I'll leave that follow-up task for someone else to file if they'd like.

Change #1189376 merged by jenkins-bot:

[mediawiki/extensions/Echo@master] Fix error handling in notifications popup

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