This is something I've been asking for for quite a while. We have this state with runtime localization where we have to do backflips in order to win the race with Gecko to firstPaint.
I filed a bug for getting an API to prevent frame creation [0] and got a response that display: none should do this. Because I couldn't verify any gain and I hit the "white page on load" problem I gave up. My understanding is that we have two topics here: 1) We need a way to inject asynchronous javascript that will take DOM from HTML, modify it and report when done. There may be multiple code pieces that want to do this and it should delay frame creation and layout until this code is done. That concept that a given app wants to prevent frame creation until its JS reports being done would help a lot of frameworks like react, angular and localization related as well. The challenge is that ideally we would like to not have to inject synchronous script to enable that. So any form of <meta> tag or manifest entry would be better than DOM API for notifying the platform that this page wants to delay. We may also want to think about a timeout in case things go south, but I'm not sure if after the timeout we should paint whatever we have (almost certainly a broken and useless UI) or should we paint a user-friendly "This page is broken. Restart? Reinstall? Remove? Report?" dialog. >From the perspective of Gaia UI I'd say the latter. 2) We want to bring app to foreground/paint it only when the app's chrome is visually complete. This is easier since we now have the performance marks and they nicely correspond to when the UI of the app is meaningful. The only challenge here is that the marks from the website are representing app code state and intention. "navigationLoaded" which indicates that chrome code is ready will overlap with "start frame creation" from 1) but doesn't mean that frame/layout/firstPaint happened. So on one hand we could tie Gaia system to bring app to foreground on this even, on the other hand, ideally we'd like to tie that event to gecko's frame/layout and then bring the app to foreground on firstPaint. ------------------------------------ So if the display:none strategy does prevent frame/layout, I see the solution as such: 1) We add <body style="display:none"> to our apps 2) We switch body.style.display = 'block'; on navigationLoaded 3) We need an event from Gecko when *after* step (2) it painted the document 4) We need to switch in the system to only bring apps to foreground in reaction to step (3) That should solve it? On top of that we could achieve two more features: a) Look from System into app's document's DOM on DOMContentLoaded and if <body> has display='none' wait with bringing it to the foreground for navigationLoaded b) If document's body has display='none' and doesn't fire up navigationLoaded in a certain amount of time, stop script execution of that document and display "Unfortunately this app failed to load" user-friendly dialog. What do you think? zb. [0] https://bugzilla.mozilla.org/show_bug.cgi?id=1176924 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
