I'm kind of late on the thread...
While James's solution may work I don't think this is exactly what we want.
My understanding of why the current solution work is:
1. The background-color of the page is retrieved when the load event happens
at
http://mxr.mozilla.org/mozilla-central/source/dom/browser-element/BrowserElementChildPreload.js#1897
and forwarded to the parent process to use it as a background-color for the
<iframe mozbrowser> (otherwise it defaults to a white background).
2. The cover is removed when the load event happens. At the same time the
background is set.
My questions with this solution are:
1. Do we really want to allow transparent color for a webpage to show what is
displayed underneath by the system app ?
On Firefox there is always a default bgcolor (which is retrieved here
afaik:
http://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresContext.cpp#623)
2. The background-color is defined when the load event happens:
It likely work for app that loads under the 250ms allowed by
nglayout.initialpaint.delay but it may fail if the app takes longer than this
to load its dependencies (js, css, locales, images, etc..). So it seems a bit
racy to me.
I guess the system app can start the iframe with a transparent background
to get rid of the race, but then it may look weird for apps that expect a
default background color underneath.
Also I would like to have a more unified solution with what Chromium is doing
for webapps. Which is, afaik, removing the cover on the first non-empty paint.
See https://codereview.chromium.org/306823002/ and
https://groups.google.com/a/chromium.org/forum/#!msg/apps-dev/y39qqrqoxjs/o6lb7utaEoEJ
So what I would like to do in bug 1211853 is:
1. There is no paint unless there is something to paint. While it can be
tricky to know if there is something to paint, a simple such as: does the
<html> element has a frame and it is visible (not visibiliy: hidden) ?
If not nothing is painted on the screen until there is something to paint.
This is a pretty simple API. Nothing is painted, because there is nothing to
paint.
2. Once painting has happened, dispatch a mozfirstpaint event to the page.
This way the page can be optimize to quickly display something to the screen
and continue its work once something has been painted (or at least once the
platform has tried to paint it).
On Thursday, July 30, 2015 at 10:20:35 PM UTC+2, James Burke wrote:
> There are some forces at play in a web app that point to wanting to delay
> layout and rendering until a web app gives a signal that it should start:
>
> * ECMAScript modules, and even developer constructed JS module systems
> today, rely on async loading of scripts.
>
> * Custom elements need their JS registered with the browser before they are
> fully useful.
>
> * Apps can have dependencies on async IDB operations to know what UI to
> first show. For instance, if the user does not have a saved account, show
> the sign in view instead of the app data view.
>
> * We want fast app startups in B2G/Gaia. Typically we lose
> layout/render/paint time while we wait for these async mechanisms to
> finish, and the paints are not useful for the user in the meantime.
>
> In addition, there is a possibility that custom elements may take a path of
> synchronous construction with no later upgrades, which means the JS for the
> custom element needs to be registered before any custom element is used in
> the DOM.
>
> A similar case surfaced a while back in the context of B2G, and at the time
> I filed bug 863499[2], which focused on a document.mozDelayLoadEvent /
> document.mozStopDelayingLoadEvent JS API around controlling the load event
> firing.
>
> At that time, the concern was about losing times to wasted renders and the
> effects on screen shots.
>
> However, I believe the main concern now is getting enough JS and app data
> loaded to allow layout to be effective in fewer passes than strictly about
> the final render and load event. So maybe the API should be more about
> delaying layout than about the load event?
>
> In talking to Wilson Page, he mentioned something like a
> document.pauseLayout() document.resumeLayout(), not sure if there are
> existing thoughts around that.
>
> If that seemed workable, maybe also a <html mozPauseLayout> type of
> attribute, so the browser knows as soon as possible to pause its work,
> instead of relying on a JS API.
>
> For Gaia apps, we use a CSP policy that does not allow inline scripts, so
> the attribute on a tag is more appealing for that reason. A nonced script
> might be a workable alternative for the CSP case, if an attribute was too
> much of a stretch.
>
> Happy to hear about any suggestions for the general goal,
> James
>
> [1] Service workers help a bit here, but do not help the other aync forces.
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=863499
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
