1280260 - Pause Frame Creation from JS

Status: NEW

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

Description

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

We're implementing new client-side l10n layer for Firefox and we would like to be able to avoid the race condition where we're trying to get l10n resources loaded and DOM translated before the layout happens.

We're not the only ones that need this. It's becoming a common problem where Web Apps want to alter the DOM as part of the bootstrap process before layout/firstPaint.

It has been discussed at https://groups.google.com/d/topic/mozilla.dev.platform/F3Mp6dZonMA/discussion with a thumbs-up from :sicking.

:bz said that he could expose an API for us (for chrome only code now) to enable us to do that.
We could start with chrome-only API and later consider standardizing it and exposing to the Web.

:bz - the way I thought about it would be sth like a:

document.pauseFrameCreation();
(...)
document.resumeFrameCreation();

The pausing could also be a <meta> tag maybe?

How would you envision that?

Comment 1

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

CC'ing :sicking and :mbest (per :sickin's suggestion) because it would tremendously help WebApps.

Comment 2

[Boris Zbarsky [:bzbarsky]]

I don't think we'd ever expose this sort of API to non-chrome code, fwiw.  Not least because it's a best-effort thing: if someone flushes layout we _will_ construct frames.

I would probably call it document.blockLayoutStart()/document.unblockLayoutStart.  It would twiddle the mPendingSheetCount (needs renaming) in nsContentSink.cpp, for the HTML case.

And for XULDocument case we'd need to do something slightly different, possibly; it uses a different mechanism to determine when to start layout.

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I would suggest talking to the layout team.

Comment 4

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

:bz - would you be able to take this bug?

Comment 5

[Boris Zbarsky [:bzbarsky]]

So I have this partially written up, but it's ending up fairly complicated (especially with XUL involved) and quite fragile.  For example, any <script> following yours that touches a layout property will cause FOUC.

So for purposes of l20n, here's a question: can you just use sync XHR and take advantage of the parser-blocking <script> already does?

Comment 6

[Staś Małolepszy :stas]

I'd like to keep our options open and experiment with something like document.blockLayoutStart() to see how it affects our performance.

At the same time, FOUCs haven't come up as a significant performance problem in our work so far.  If they do, I'll be happy to first try sync IO as :bz suggests in comment 5.

Let's keep this bug open.  I'll report in a few weeks with more data on async v. sync IO.

Comment 7

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

Boris said he could try to get us a POC soon :)

Comment 8

[Boris Zbarsky [:bzbarsky]]

Attachment: part 1. Rename the pending sheet stuff in nsContentSink to more generic layout blocker stuff

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: part 2. Add an API on nsContentSink to allow adding/removing layout start blockers

Comment 10

[Boris Zbarsky [:bzbarsky]]

Attachment: part 3. Add an API on nsIDocument to allow adding/removing layout start blockers

Comment 11

[Boris Zbarsky [:bzbarsky]]

Attachment: part 4. Add a Document API for adding/removing layout start blockers

Comment 12

[Boris Zbarsky [:bzbarsky]]

Attachment: Roll-up patch to make experimenting simpler

Comment 13

[Boris Zbarsky [:bzbarsky]]

Note that this is not the way I'd structure stuff for real (e.g. the layout blocker count should probably just move to the document), but it's enough to at least try this out.  Again, no XUL document support so far.

Comment 14

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

I was able to apply the patch and use it for my testing.

I can confirm that it does prevent painting until blocker is removed, but it doesn't seem to prevent MozAfterPaint's.

I tried to set a document without any JS except of:

===
   <script type="application/javascript">
   document.addLayoutStartBlocker();

   setTimeout(() => {
     document.removeLayoutStartBlocker();
     window.docReady = 1;
   }, 1000);

  function logFirstPaint() {
    performance.mark('moz-after-paint');
    let measures = performance.getEntriesByName('moz-after-paint');
    let measure = measures[measures.length - 1];
    if (window.docReady) {
      window.removeEventListener('MozAfterPaint', logFirstPaint, true);
      console.log('Paint: ' + measure.startTime + ' (after docReady)');
    } else {
      console.log('Paint: ' + measure.startTime + ' (before docReady)');
    }
  }
  window.addEventListener("MozAfterPaint", logFirstPaint, true);
   </script>

===

and when I launched it in a tab (via chrome://) it returns 20 paint logs, 19 of which happen before the `docReady = 1`.

is that expected?

Comment 15

[Boris Zbarsky [:bzbarsky]]

Probably: painting happens from the root of the document tree, so even documents with nothing to paint yet (like this one) would get painted...

Comment 16

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

(In reply to Boris Zbarsky [:bz] from comment #15)
> Probably: painting happens from the root of the document tree, so even
> documents with nothing to paint yet (like this one) would get painted...

so, how can I measure when the engine starts layout/painting of the document?

I see MozAfterPaint firing before DOMContentLoaded, then between DOMContentLoaded and window.onload, and then again. How do I know which one of the three is the real painting of HTML?

The one that I have to finish any DOM modifications before if I want to prevent FOUC?

Comment 17

[Boris Zbarsky [:bzbarsky]]

> so, how can I measure when the engine starts layout/painting of the document?

I don't know offhand.

> How do I know which one of the three is the real painting of HTML?

They all could be, depending on what the DOM and layout trees look like...

> The one that I have to finish any DOM modifications before if I want to prevent FOUC?

FOUC will happen if a paint happens before your modifications are done _and_ layout is being done on whatever is already there, no?  The whole point of blocking layout is to prevent that second condition from being true.

Comment 18

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

> FOUC will happen if a paint happens before your modifications are done _and_ layout is being done on whatever is already there, no?  The whole point of blocking layout is to prevent that second condition from being true.

I thought that blocking layout will prevent paints so I was trying to check if your patch impacts the first paint time to be after l20n is done (so, DOM is ready).

If blocking layout doesn't prevent paints, then how can we test the impact of our changes on the performance?

The ts_paint tests the painting, and if painting is done irrelevant of layout, then we can block layout for a second and the paint won't be affected, am I correct?

Comment 19

[Boris Zbarsky [:bzbarsky]]

> I thought that blocking layout will prevent paints

Well, it prevents there being anything there to paint, which is not quite the same thing.

> then how can we test the impact of our changes on the performance?

I'm not sure, honestly.

> then we can block layout for a second and the paint won't be affected, am I correct?

I don't know enough about what ts_paint is measuring to answer that question, sorry.

Comment 20

[Axel Hecht [:Pike]]

Mass change dependency tree for bug 1279002 into a whiteboard keyword.