1176924 - API to delay frame creation

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, defect)

Description

[Zibi Braniecki [:zbraniecki][:gandalf]]

We observe a dynamic in Firefox OS (Web apps) environment where we the app startup goes like this:

1) We have HTML in the document that we load
2) We initialize startup javascript that alters the DOM
3) We are ready for the firstPaint

Currently, step nr. 2 is a race with Gecko that requires us to write dirty, synchronous code in order to prevent flashes of not-ready content and reflows.

A prime example of that is client size localization. 

We initialize l10n.js, check if the document is in the right language and if it's not, we retranslate it (which requires loading resources in the new language). We try to do this all before firstPaint and we still compete with layout.

There are other examples of that - most Gaia apps these days has runtime code that is launched at startup and decides which elements to show, hide, sets toggles into initial state etc.

With the NG Architecture, we are going to cache and invalidate cache, hopefully outside of the app startup hotpath, but there's still the scenario where at the startup with have to invalidate the DOM and rebuild it *before* we display it.

Thus, I would like to get an API that allows us to temporarily delay frame creation until we report that the DOM is ready.

With ability to delay frame creation we should be able to reduce the competition, reduce the amount of layouts/reflows that we need at startup and in result improve the performance.

It could look like this:

document.mozDelayFrameCreation(timeout=50); // timeout controls time after which Gecko will resume automatically.

document.mozResumeFrameCreation();

I'm totally open to any other API approach that provide the required functionality.

Comment 1

[Boris Zbarsky [:bzbarsky]]

So your step 2 is spinning the event loop in between modifying the DOM?

Does just setting things display:none until ready to render not work?

Comment 2

[Zibi Braniecki [:zbraniecki][:gandalf]]

Step 2 may be asynchronous.

display:none may be the solution although historically I heard from Gaia people that we should avoid that.

Is display:none preventing frame creation?

Fabrice, Jonas, Vivien what do you think?

Comment 3

[Boris Zbarsky [:bzbarsky]]

> Is display:none preventing frame creation?

Yes, pretty much by definition.

Comment 4

[Zibi Braniecki [:zbraniecki][:gandalf]]

I tried display:none for non-default language for two Gaia apps - Settings (which has the largest DOM) and fm (smallest DOM).

There seem to be no perf difference, so I'm closing this bug for now.

If we get back to the conclusion that we are doing double reflow or sth like that, we'll reopen this.