Page underneath the overlay flashes for 1 frame when switching between loading overlay and real overlay. This seems to be a problem with overlays in MobileFrontend and Minerva that use loadingOverlay: talk, categories and editor.
The video below demonstrates the issue with the following overlays: editor (wikitext) and talk.
(Recorded on https://en.m.wikipedia.org/wiki/The_Fighting_Temeraire using Chrome on desktop, but the same can be seen on real mobile devices.)
{F28027495}
It's difficult to consciously notice, so here are frames extracted from the video:
| Overlay | Before click | After click (loading overlay) | Flash | Real overlay | Notes (feel free to file as separate tasks)
| -- | -- | -- | -- | -- | --
| editor (wikitext) | {F28027503} | {F28027504} | {F28027505} | {F28027507} | There is an extra loading screen within the overlay with the spinner in a different location: {F28027506}
| talk | {F28027512} | {F28027513} | {F28027509} | {F28027511} |
= Developer notes
The issue here is the use of loadModule and OverlayManager.
```
overlayManager.add( /^\/languages$/, function () {
var lang = mw.config.get( 'wgUserLanguage' );
return loader.loadModule( 'mobile.languages.structured', true ).then( function ( loadingOverlay ) {
var gateway = new PageGateway( api ),
LanguageOverlay = M.require( 'mobile.languages.structured/LanguageOverlay' );
return gateway.getPageLanguages( mw.config.get( 'wgPageName' ), lang ).then( function ( data ) {
```
We hide the loading overlay here...
```
loadingOverlay.hide();
return new LanguageOverlay( {
currentLanguage: mw.config.get( 'wgContentLanguage' ),
languages: data.languages,
variants: data.variants,
deviceLanguage: getDeviceLanguage()
} );
} );
} );
} );
```
_processMatch uses the factoryResult (in this case the return value of loader.loadModule)
```
factoryResult.then( function ( overlay ) {
match.overlay = overlay;
attachHideEvent( overlay );
self._show( overlay );
} );
```
These things are therefore not 100% connected (ideally loadingOverlay.hide would be managed by the OverlayManager itself)
Given the complexity here, I propose waiting until T212465 has been resolved and then re-evaluating this task. I've left a note on that one.