Page MenuHomePhabricator

The display language in idwiki does not change even if a user has changed it
Closed, ResolvedPublicBUG REPORT

Description

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

What happens?:
The display language does not change and remains in Indonesian.

What should have happened instead?:
The display language should change according to the user's selection in the previous pop-up box.

Software version (skip for WMF-hosted wikis like Wikipedia):

Other information (browser name/version, screenshots, etc.):
I am using Safari Version 16.5 (18615.2.9.11.4)

Event Timeline

Further details: I have overridden the language selection in global preferences to select English, but I still couldn't change it to any language other than Indonesian.

Aklapper updated the task description. (Show Details)

Hi @Rachmat04, thanks for taking the time to report this!
I can confirm this on https://id.wikipedia.org/?useskin=vector&safemode=1 in Firefox 114. I could not reproduce on cswiki.

Thanks for checking @Aklapper ! How critical is this bug? Does it fall into the "UBN" category?

Nikerabbit moved this task from Backlog to Other teams/Watching on the Language-Team board.
Nikerabbit subscribed.

This is not an issue with ULS. I can see that the settings change works successfully, and that the selected language is shown in Special:Preferences. But it is not taking effect.

Looking at https://id.wikipedia.org/w/api.php?action=query&meta=siteinfo&siprop=showhooks I see ULS hook handler listed twice:

{
    "name": "UserGetLanguageObject",
    "subscribers": [
        "UniversalLanguageSelector\\Hooks::onUserGetLanguageObject",
        "UniversalLanguageSelector\\Hooks::onUserGetLanguageObject"
    ]
},

This does not seem to be the case in other projects.

On fiwiki:

> sudo $services->getHookContainer()->registry->getExtensionHooks()['UserGetLanguageObject'];
= [
    [
      "handler" => [
        "name" => "UniversalLanguageSelector-main",
        "class" => "UniversalLanguageSelector\Hooks",
        "services" => [
          "MainConfig",
          "UserOptionsLookup",
          "StatsdDataFactory",
          "LanguageNameUtils",
        ],
      ],
      "extensionPath" => "/srv/mediawiki/php-1.41.0-wmf.13/extensions/UniversalLanguageSelector/extension.json",
    ],
  ]

> sudo $services->getHookContainer()->handlers['UserGetLanguageObject'];

   NOTICE  Undefined index: UserGetLanguageObject in /srv/mediawiki/php-1.41.0-wmf.13eval()'d code on line 2.

= null

>

On idwiki:

> sudo $services->getHookContainer()->registry->getExtensionHooks()['UserGetLanguageObject'];
= [
    [
      "handler" => [
        "name" => "UniversalLanguageSelector-main",
        "class" => "UniversalLanguageSelector\Hooks",
        "services" => [
          "MainConfig",
          "UserOptionsLookup",
          "StatsdDataFactory",
          "LanguageNameUtils",
        ],
      ],
      "extensionPath" => "/srv/mediawiki/php-1.41.0-wmf.13/extensions/UniversalLanguageSelector/extension.json",
    ],
  ]

> sudo $services->getHookContainer()->handlers['UserGetLanguageObject'];
= [
    [
      "callback" => [
        UniversalLanguageSelector\Hooks {#1138},
        "onUserGetLanguageObject",
      ],
      "functionName" => "UniversalLanguageSelector\Hooks::onUserGetLanguageObject",
    ],
  ]

>
Nikerabbit added a subscriber: daniel.

This hook issue might be unrelated (since that hook doesn't actually do anything in WMF production), but it's the only clue so far. @daniel any thoughts what might cause the duplication?

Note that $services->getHookContainer()->handlers['UserGetLanguageObject'] is used for lazy initialization of hook handlers. The fact that it's missing an entry just means that nothing asked for the handlers of this hook yet. handlers['UserGetLanguageObject'] would be initialized based on the information from extensions - once it is initialized, information from extensions would be ignored.

I can't think of a way this duplication would happen, unless something actually registered the hook twice... But of course, there may be a bug somewhere.

Ah, I think I found the bug. getHandlerDescriptions() will return the handler twice, once from the extension and once from $this->handlers.
This will cause the API to erroneously report the handler twice.

This will happen if the handler was initialized, typically because the hook was run.

So the difference between idwiki and frwiki is that on idwiki, the hook seems to be run early on all requests.

Here is a fix for the miss-reporting: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/931640

This is unrelated to the issue d escribed in this ticket though.

Thanks for checking. Nevertheless the fact that the hook is called (so) early (even on CLI) on idwiki sounds suspicious and worth investigating. I am not sure how to find out what triggers it.

Thanks for checking. Nevertheless the fact that the hook is called (so) early (even on CLI) on idwiki sounds suspicious and worth investigating. I am not sure how to find out what triggers it.

Idea: Make a patch against the deployment branch that adds a handler that throws an exception, deploy it to mwdebug, and look at the stack trace :)

I tried to use Excimer instead: https://performance.wikimedia.org/excimer/profile/15a816db9a18de24

Found the issue:

MediaWiki\HookContainer\HookRunner::onUserGetLanguageObject (/srv/mediawiki/php-1.41.0-wmf.13/includes/HookContainer/HookRunner.php)
> RequestContext::getLanguage (/srv/mediawiki/php-1.41.0-wmf.13/includes/context/RequestContext.php)
> Message::getLanguage (/srv/mediawiki/php-1.41.0-wmf.13/includes/language/Message.php)
> Message::fetchMessage (/srv/mediawiki/php-1.41.0-wmf.13/includes/language/Message.php)
> Message::format (/srv/mediawiki/php-1.41.0-wmf.13/includes/language/Message.php)
> Message::plain (/srv/mediawiki/php-1.41.0-wmf.13/includes/language/Message.php)
> MediaWiki\Extension\Wikistories\hooks\RecentChangesPropagationHooks::__construct (/srv/mediawiki/php-1.41.0-wmf.13/extensions/Wikistories/includes/hooks/RecentChangesPropagationHooks.php)
> Wikimedia\ObjectFactory\ObjectFactory::getObjectFromSpec (/srv/mediawiki/php-1.41.0-wmf.13/vendor/wikimedia/object-factory/src/ObjectFactory.php)
> Wikimedia\ObjectFactory\ObjectFactory::createObject (/srv/mediawiki/php-1.41.0-wmf.13/vendor/wikimedia/object-factory/src/ObjectFactory.php)
> MediaWiki\HookContainer\HookContainer::makeExtensionHandlerCallback (/srv/mediawiki/php-1.41.0-wmf.13/includes/HookContainer/HookContainer.php)
> MediaWiki\HookContainer\HookContainer::normalizeHandler (/srv/mediawiki/php-1.41.0-wmf.13/includes/HookContainer/HookContainer.php)
> MediaWiki\HookContainer\HookContainer::getHandlers (/srv/mediawiki/php-1.41.0-wmf.13/includes/HookContainer/HookContainer.php)
> MediaWiki\HookContainer\HookContainer::register (/srv/mediawiki/php-1.41.0-wmf.13/includes/HookContainer/HookContainer.php)
> Wikibase\Client\Hooks\ExtensionLoadHandler::registerHooks (/srv/mediawiki/php-1.41.0-wmf.13/extensions/Wikibase/client/includes/Hooks/ExtensionLoadHandler.php)
> Wikibase\Client\Hooks\ExtensionLoadHandler::onExtensionLoad (/srv/mediawiki/php-1.41.0-wmf.13/extensions/Wikibase/client/includes/Hooks/ExtensionLoadHandler.php)
> /srv/mediawiki/php-1.41.0-wmf.13/includes/Setup.php (/srv/mediawiki/php-1.41.0-wmf.13/includes/Setup.php)
> /srv/mediawiki/php-1.41.0-wmf.13/includes/WebStart.php (/srv/mediawiki/php-1.41.0-wmf.13/includes/WebStart.php)
> /srv/mediawiki/php-1.41.0-wmf.13/index.php (/srv/mediawiki/php-1.41.0-wmf.13/index.php)
> /srv/mediawiki/w/index.php (/srv/mediawiki/w/index.php)

@daniel This seems to another issue caused by hook handlers being created so early. Anything you can do here?

For WikiStories: one possible quick fix would be to move the wfMessage call out of a constuctor to a static method that initializes it on the first call.

For WikiStories: one possible quick fix would be to move the wfMessage call out of a constuctor to a static method that initializes it on the first call.

I can implement that quickly if you want.

Change 933903 had a related patch set uploaded (by Sbisson; author: Sbisson):

[mediawiki/extensions/Wikistories@master] Avoid calling wfMessage in the hook handler constructor

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

Change 933903 merged by jenkins-bot:

[mediawiki/extensions/Wikistories@master] Avoid calling wfMessage in the hook handler constructor

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

Change 937913 had a related patch set uploaded (by Func; author: Sbisson):

[mediawiki/extensions/Wikistories@wmf/1.41.0-wmf.17] Avoid calling wfMessage in the hook handler constructor

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

Change 937913 merged by jenkins-bot:

[mediawiki/extensions/Wikistories@wmf/1.41.0-wmf.17] Avoid calling wfMessage in the hook handler constructor

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

Mentioned in SAL (#wikimedia-operations) [2023-07-13T20:17:28Z] <taavi@deploy1002> Started scap: Backport for [[gerrit:937913|Avoid calling wfMessage in the hook handler constructor (T339272)]]

Mentioned in SAL (#wikimedia-operations) [2023-07-13T20:19:03Z] <taavi@deploy1002> func and taavi: Backport for [[gerrit:937913|Avoid calling wfMessage in the hook handler constructor (T339272)]] synced to the testservers: mwdebug2001.codfw.wmnet, mwdebug2002.codfw.wmnet, mwdebug1002.eqiad.wmnet, mwdebug1001.eqiad.wmnet

Mentioned in SAL (#wikimedia-operations) [2023-07-13T20:22:15Z] <taavi@deploy1002> Started scap: Backport for [[gerrit:937913|Avoid calling wfMessage in the hook handler constructor (T339272)]]

Mentioned in SAL (#wikimedia-operations) [2023-07-13T20:23:40Z] <taavi@deploy1002> func and taavi: Backport for [[gerrit:937913|Avoid calling wfMessage in the hook handler constructor (T339272)]] synced to the testservers: mwdebug2002.codfw.wmnet, mwdebug1001.eqiad.wmnet, mwdebug2001.codfw.wmnet, mwdebug1002.eqiad.wmnet

Mentioned in SAL (#wikimedia-operations) [2023-07-13T20:29:53Z] <taavi@deploy1002> Finished scap: Backport for [[gerrit:937913|Avoid calling wfMessage in the hook handler constructor (T339272)]] (duration: 07m 38s)

Nikerabbit claimed this task.

Assuming fixed.