On pages where the 'user' module is filtered out (e.g.
on Special:Preferences) it would export state 'loading' (or state
'ready') eventhough the actual call to makeResourceLoader() later
in getBottomScripts() would be a no-op due to filtering.
This would cause either an indefinite state of "loading" or a
state "ready" that wasn't true.
This restores status quo as it was before
80e5b160 and
3e7a50d5f.
Test plan:
* Logged-in with non-empty user page common.js.
* View Special:Preferences.
* Verify in <head> source code, or via mw.loader.getState('user')
that it has state "registered" (the default initial state) and
not state "loading" or "ready".
Change-Id: I9b360d7e12703bddb80793aef47296fd63032c3d
);
$this->rlExemptStyleModules = $exemptGroups;
- // Manually handled by getBottomScripts()
- $userModule = $rl->getModule( 'user' );
- $userState = $userModule->isKnownEmpty( $context ) && !$this->isUserJsPreview()
- ? 'ready'
- : 'loading';
- $this->rlUserModuleState = $exemptStates['user'] = $userState;
+ $isUserModuleFiltered = !$this->filterModules( [ 'user' ] );
+ // If this page filters out 'user', makeResourceLoaderLink will drop it.
+ // Avoid indefinite "loading" state or untrue "ready" state (T145368).
+ if ( !$isUserModuleFiltered ) {
+ // Manually handled by getBottomScripts()
+ $userModule = $rl->getModule( 'user' );
+ $userState = $userModule->isKnownEmpty( $context ) && !$this->isUserJsPreview()
+ ? 'ready'
+ : 'loading';
+ $this->rlUserModuleState = $exemptStates['user'] = $userState;
+ }
$rlClient = new ResourceLoaderClientHtml( $context, $this->getTarget() );
$rlClient->setConfig( $this->getJSVars() );