787378 - Dispatch a "firstpaint" event for mozbrowsers

Status: RESOLVED FIXED

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

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

This lets the embedder know when the iframe has valid pixels available.  This is useful for things like https://github.com/mozilla-b2g/gaia/issues/4213 .

To implement this, I think we'd want to
 - register a MozAfterPaint listener from BrowserElementChild when it's initialized
 - when the first MozAfterPaint event is dispatched, fire the "firstpaint" notification to the embedder
 - unhook the MozAfterPaint listener (they can cause some perf issues)

Comment 1

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Hm ... need to be careful about about:blank here.

Comment 2

[Justin Lebar (not reading bugmail)]

(In reply to Chris Jones [:cjones] [:warhammer] from comment #1)
> Hm ... need to be careful about about:blank here.

Yeah, I was just about to comment on that.  :)  But I think we can just check the location of the docshell/document.

Comment 3

[Justin Lebar (not reading bugmail)]

> But I think we can just check the location of the docshell/document.

...unless http://foo.com can be painted before the docshell's location changes away from about:blank.  I hope not, but I'm not sure.

Comment 4

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

If that were true, I think that many things other than this would be broken.

Comment 5

[Justin Lebar (not reading bugmail)]

One way to find out, I guess.

https://tbpl.mozilla.org/?tree=Try&rev=0f81ae103909

Anyone want to take bets on which platform will go randomorange?  My money is on OSX.

Comment 6

[Justin Lebar (not reading bugmail)]

No random oranges; just permaorange on opt builds on all platforms.  :)

Comment 7

[Justin Lebar (not reading bugmail)]

Second time's a charm? https://tbpl.mozilla.org/?tree=Try&rev=3ec505fdd543

Comment 8

[Justin Lebar (not reading bugmail)]

Attachment: Part 1: Fire a "firstpaint" event in iframe mozbrowser.

Comment 9

[Justin Lebar (not reading bugmail)]

Attachment: Bug 787378 - Part 2: Tests for mozbrowserfirstpaint event.

Comment 10

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Comment on attachment 657434 [details] [diff] [review]
Part 1: Fire a "firstpaint" event in iframe mozbrowser.

Stealing.

>diff --git a/dom/browser-element/BrowserElementChild.js b/dom/browser-element/BrowserElementChild.js

> function debug(msg) {
>-  //dump("BrowserElementChild - " + msg + "\n");
>+  // dump("BrowserElementChild - " + msg + "\n");

This is distracting, please remove.

Looks good!  r=me with nitfix

Comment 11

[Justin Lebar (not reading bugmail)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/0d060c3e7d65
https://hg.mozilla.org/integration/mozilla-inbound/rev/50e752beca26

I, um, forgot to put "r=cjones" in the commit messages.  Oops.

Comment 12

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

10 demerits.  10 more and we bust you down to L2 ;).

Comment 13

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/0d060c3e7d65
https://hg.mozilla.org/mozilla-central/rev/50e752beca26