Re: Allowing web apps to delay layout/rendering on startup
On Thu, Oct 8, 2015 at 9:10 AM, Mounir Lamouri wrote: > Note that Chrome 46 has a way to work around the white screen while a > page load using a new property in the Manifest. If a website added to > the homescreen on Chrome Android has a background_color information, it > will be used while the page loads. After Chrome gets the first paint > following a non-empty layout, it will remove that plain colour and > switch to whatever the page has ready. It allows websites to be > constructed as websites and not rely on that splashscreen feature that > might or might not be present (given the UA and the current context) and > also keep the principle of quick first paint. > > Would using a similar system (ie. background_color from the Manifest) > help you here? I am unsure of the needs related to bug 1199674, but on the manifest background color: if it is a color that is set in the manifest, I find that marginally more useful than a flash of white before painting. What if the UI has different start colors? It would be a noticeable abrupt transition. For email, if no accounts configured, the background is a light gray. If accounts are configured, the header is an orange but the bulk of the content area uses a white color. To me, the use of a solid color, particularly if white, just looks like the typical browser new tab white loading screen. I am purposely trying to avoid that in email. I liked that Firefox OS uses the icon as part of the app launch transition, it felt different than a single color paint. Go from startup animation with the app icon to meaningful content. James ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: "non-missable" events, or multi-promises
On Tue, Sep 22, 2015 at 4:50 PM, Zibi Braniecki
wrote:
> This sort of repeatable-promise, would reduce it to:
> 1) Set the repeatable promise on the target
>
> Sounds like it would make much easier to write async code without logic for
> preventing race conditions.
>
> Is there any other approach to that?
I think it best to just consider promises async program flow: it
completes or errors out. A repeatable promise concept does not seem to
have an analogy with sync program flow (maybe checkpointing a line in
a piece of code and re-winding it to run again?), so I would be more
hesitant to try to fit that into a promise model.
In gaia email, we have an event library[1] that has an
"emitWhenListener" method, so the code that does the emit of the event
can do so via that method, and then when the first event listener
listens for that particular event name, it gets that previously
emitted event. This is only useful if we know there is likely just one
event listener and there may be a race between the emitter and the
listener.
There is also a concept of "latest" in the event library:
evt.latest('foo', function(event){}) will be called when there is a
'foo', and if there is an existing one, called right away, and for
future changes to a 'foo'. This approach works well for multiple
listeners that may be dealing with something that could already have
an existing state.
Maybe the conceptual models in that library could be refined, but they
sound related to what you are asking.
For async concepts, gtor[2] might be an interesting read, but I say
that not having fully grokked the fullness of gtor, and perhaps if I
did it would contradict some of the above.
James
[1] https://github.com/jrburke/evt - light on docs, tests might be the
most instructive.
[2] https://github.com/kriskowal/gtor/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Allowing web apps to delay layout/rendering on startup
On Tue, Aug 18, 2015 at 1:22 PM, Zibi Braniecki wrote: > My concern here is that if we don't, we're basically saying that the right > way to write webapps, is to put their content in a template and then inject > the template into body when we're done with startup JS. There are other approaches too, I expect apps that use an mvc layer with templating (not the template tag), could decide not to use the tag approach, just leave the body empty until JS injects the content. > That feels like a dirty hack, not sure how accessible it is, and it will > literally do nothing in a scenario of any JS error. With web components, but even with other MVC systems (react or ember components), or with service workers, we are saying we need app JS to generate views. When the app gets to handle the views it also needs to build its own error fallbacks. I think it is just good app practice to know how to handle errors. I would not be sure what platform API makes sense to recommend either, particularly given the performance captures, where it is unclear what benefit those APIs would provide. You could say the platform has already provided the API: a template tag and a way to hopefully avoid extra rendering work (or at least the annoying initial flash of white) with a transparent background color. James ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Allowing web apps to delay layout/rendering on startup
On Tue, Aug 11, 2015 at 5:17 PM, James Burke wrote: > https://github.com/jrburke/fxos-startup-test > > There are three variations mentioned in the README, each with a > profile.sh capture "Profile" link: I did a pass at the "Regular" profile and put the notes here: https://github.com/jrburke/fxos-startup-test#profile-notes and duplicated below for ease of reference. In short, it seems like an approach like the one used in the test app, with a transparent background and a template element for the body content, seemed to avoid any sizable layout or rendering work during initial page loading and the point where the app JS constructs the view. So, seems like we can hold off on any new browser APIs for now, and use app-level constructs to group changes that might trigger layout before insertion in the DOM. I welcome other people's inspection of the profile though. Perhaps I did not capture all the relevant info. The b2g/gaia code around launching an app has changed since last doing a profile like this (at least a year ago), so those changes and using the app approach in the test app seem to be sufficient for now. It might be nice to reduce some other startup costs but those seem to be more in the realm of gaia's control. --- 208030ms is the firstLoadURI marker, so going from that marker as the start point. Dropping the **208** prefix for the numbers to help make it easier to see the relative differences. * **Start**: 030 - firstLoadURI * **End**: 434 - The JS in startup.js that sets up the view. Layouts after this point are expected, not part of this test. The goal is to find savings between firstLoadURI and the startup.js point. Timeline: * 034-045 - 11ms: getAppInfo @ AppsService.js:110 * 058-223 - 165ms: epoll_wait on Content row, the GPU row has around notable 8 notable Composite entries, each around 4ms, some very small (less than 1ms) Composite entries too. Hypothesis: related to the app icon zoom in effect when tapping on an app icon from the home screen. * 239-284 - 45ms: Some script work relatied to user customizations and CSP: * this.UserCustomizations.observe() @ UserCustomizations.jsm:297 * getCSPBYLocalId() and getAppBYLocalId(), both in AppsService.js * 297-362 - 65ms: nsInputStreamPump:OnStateStop: some sort of IO? * 366-389 - 23ms: RunScript related to BrowserElementChild.prototype._metaChangedHandler @ BrowserElementChildPreload.js:562. * 389-433 - some IO work/evaluation of cards-message-list.js, a script in the page, and 7ms spent in nsStyleSet:FileRules. * 434: Start of startup.js view work. A quicker evaluation of the "display none body" and "display none html" profiles show they do not perform any faster than the "regular" one, and have a similar shape between the firstLoadURI and the startup.js work. Looking at that profile does not seem to indicate sizable wait time related to layouts or renders before the app JS constructs the view. There does not seem to be a need for extra APIs in the browser for controlling layouts or paints using this approach: * Set the background-color for the body to be transparent. * The body content consists of a `` element with the initial content. It can include custom elements, but they are inert given the `` usage. * Async load the scripts that will provide the implementation of the custom elements. * Once all the elements have been registered, document.importNode the body template's content, and append to the body. At this point the content becomes visible, and layouts and reflows occur. It might be possible to optimize some of that layout work, although this test is fairly straightforward: some innerHTMLs done in some custom element createdCallback steps, and no other dynamic JS work done after that. --- James ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Allowing web apps to delay layout/rendering on startup
On Thu, Aug 6, 2015 at 1:07 AM, Anne van Kesteren wrote: > I think at this point it would be nice if we reached out to other > browsers to see if they have any thoughts on this kind of API. James, > would you be willing to email either public-weba...@w3.org or > wha...@whatwg.org? First, given a suggestion earlier in the thread, I tried an app experiment and did some profile.sh captures to make sure we can identify how much work could be saved, if any, with a new API. I used this sample app: https://github.com/jrburke/fxos-startup-test There are three variations mentioned in the README, each with a profile.sh capture "Profile" link: 1) The content in a template tag that is only shown once the view JS is ready. 2) Builds on the first one, but uses a CSS class that has display: none on the tag. 3) Builds on the first one, but uses display:none on the tag. More details in the README. The way the app is set up mirrors the general style I can see working with a custom element-backed view approach for an app, so hopefully close to a real world test. It does not include l10n.js localization work, but I was hoping that could be done on the view after the template importNode but before it is placed in the document. Maybe the document mutation observeration that l10n.js does could cause another layout pass, but if no extra layout gains with these captures can be found, maybe we look at an approach with the l10n.js where the mutation observers would only be activated after the initial async view insertion. I am still very slow at analyzing the profile captures, so I do not have any conclusions to draw yet. I appreciate it if others more conversant with those kind of captures could point out things that are weird in them, if it even makes sense to pursue new APIs at this point, or if one of the above approaches is enough. If there are other variations I should try, let me know and I will add them. James ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Allowing web apps to delay layout/rendering on startup
On Tue, Aug 4, 2015 at 1:52 PM, Bobby Holley wrote: > On Tue, Aug 4, 2015 at 12:10 PM, James Burke wrote: >> If the meta tag, or whatever the toggle becomes, is set, then I expect >> if the page's JS asks for a DOM element's box properties, it will get >> values like 0 for sizes, since I believe the goal is to avoid the >> browser doing extra work until the page's JS got everything set up. >> >> If that is the case, should there be a promise API for knowing when >> the first layout and rendering has occurred so that the page's JS can >> then ask for element box properties to get accurate values? > > > We could fire an event if that seems necessary. A Promise API is overkill > and inconsistent with the way other stuff like this works. An event implies the page's JS to scan to see if there are any meta tag toggles in play, to make sure the code did not miss the event. At some point APIs that are just about one and done async operations, like DOMContentLoaded and this one, seem to make sense to expose via a promise API[1] to avoid the "did I miss the one event that ever fires for this condition, check a property and if not set, bind an event listener" pattern. But if an event is better in this case to leverage existing code paths/idioms, so be it. James [1] https://www.w3.org/2001/tag/doc/promises-guide ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Allowing web apps to delay layout/rendering on startup
On Tue, Aug 4, 2015 at 10:06 AM, Bobby Holley wrote: > How about a scheme in which there can be N such elements, and the > painting only happens when all of them are gone (or some timeout occurs)? > That solve the common case that Jonas is talking about, and allows > libraries to insert their own paint blocker into if they really want > to block painting? The a nice side-bonus of this scheme is that the > existence of blockers is clearly visible in the DOM, so that a buggy > library that leaves a paint blocker active is more noticeable. If the meta tag, or whatever the toggle becomes, is set, then I expect if the page's JS asks for a DOM element's box properties, it will get values like 0 for sizes, since I believe the goal is to avoid the browser doing extra work until the page's JS got everything set up. If that is the case, should there be a promise API for knowing when the first layout and rendering has occurred so that the page's JS can then ask for element box properties to get accurate values? James ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Allowing web apps to delay layout/rendering on startup
On Thu, Jul 30, 2015 at 1:28 PM, Jeff Muizelaar wrote: > Can't you just make everything display:none until you're ready to show it? Just using display: none seems like it will run into the same problem that prompted bug 863499, where the browser did some render/paints of a white page, which took time away from the async work completing. So maybe I should not frame it as just pausing layout? I was hoping it would also delay render and maybe paints that happen during startup, so more time is given up front to the async activities. James ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Allowing web apps to delay layout/rendering on startup
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 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
Synchronous clientHeight to transitionend leading to double entry in a function
The details are in: https://bugzilla.mozilla.org/show_bug.cgi?id=1135960 In the gaia email app, we have come across a case where a clientHeight check in a function leads to synchronous notification of a transitionend listener, which then leads to the same function being called and completed while the first call to the function is still paused on the clientHeight. Since that function is setting some state on an object, it causes some problems. If this is expected behavior given spec definitions, it would be educational to learn more about that, as it does not immediately match my very possibly naive expectations on how events are triggered from DOM state changes. I was under the impression the transitionend listener notifications would have happened during a different turn in the event loop. James ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Visibility plan for document.registerElement (custom elements)
Is there a place where I can follow the plan for enabling document.registerElement for wider web usage? Right now is is only available behind an about:config setting or if an app is a certified app. I am just interested in the machinery for document.registerElement/custom elements to be available, and do not need the full web components story (for example, do not need HTML Imports). Reason for asking: we want to try an experimental FxOS email app variant, but try delivering it through the marketplace. For that, it is best if the app is privileged instead of certified. We use some custom elements inside the app, so cannot currently go privileged. While it would be relatively straightforward for the app to move away from using document.registerElement, I would prefer to just leave it as-is if document.registerElement was going to be more widely available in the FxOS 3.0 timeframe (extra nice if it were to happen in the first half of this year). --- Originally posted on dev-b2g: https://groups.google.com/forum/#!topic/mozilla.dev.b2g/CqS5fQt9b-I but was informed off-list that dev-platform may be a better place to ask this question. James ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Icon fonts in FxOS
On 6/18/14 12:20 PM, Ben Francis wrote: On Wed, Jun 18, 2014 at 6:59 PM, James Burke <mailto:jbu...@mozilla.com>> wrote: So, I think we just need to set the expectation for at least another year or two, that the gaia set of apps will not be able to be "privileged", because we need them as early beta testers for features and capabilities we are building out for the mobile web platform. We said that a year or two ago. There will always be new features to test, and with a current total of 34 apps in the gaia/apps directory we have no shortage of certified apps to test them out with. The risk of inadvertently building another proprietary app platform that isn't the web and of crippling the pace of Firefox OS updates because we're forcing 34 apps through an arduous certification process they don't need (a mistake Android already made for us) seems greater than the risk of taking the brave step of making some Gaia apps a step closer to being web apps. The longer that each Gaia app is not a web app, the less credible our mantra of "the web is the platform" becomes. If we can't figure out how to build our own apps using the web, how can we can expect third party app developers to do so? Maybe we haven't yet figured out all the details of how to put the Email app in the Firefox Marketplace, let alone how to make it run cross-platform, but if we resign ourselves to the idea that all Gaia apps are going to have to be certified for the foreseeable future then we're not doing our mission justice IMHO. It is a matter of degree: at least with Gaia apps we get the use of web tech in the construction, just not the network delivery and addressability, and by proving out the web APIs in Gaia first, we ensure a better dev experience with those APIs later for all. That is how I would frame the larger picture, in the effort of cooperation and moving forward. For me personally, I would absolutely not put a performance fix that is only available for certified apps. See the use of the cookie cache in email: it is ugly, but it is standard. Sometimes we need to do the uglier things or have less ideal dev experience in the interests of working on the common platform, file bugs for the platform, then switch to something better when it is properly sorted out, available to all apps. For email's cookie cache, I'm hopeful the proper answer will be Service Workers. But, I am not working on that platform code affected by the icon font request, so it is easier for me to be harder philosophically in that case. I would endorse that harder line though for performance changes tied to "certified". New features only in certified apps is a harder one to sort out. I personally want to avoid features that are only available to certified apps in email. However, since email depends on /shared, some of that choice is out of email's control. Maybe instead of using "certified" as the marker, we use app signing instead, with a list of signatures that are allowed getting pushed as part of device flashing, and a dev experience that overrides that, so that we do not have to sign for our local dev-debug-deploy cycles. James ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Icon fonts in FxOS
On 6/18/14 8:25 AM, Jonas Sicking wrote: Another thing that will likely force us to use certified apps for now is Web Components. We are only enabling those for certified apps for now since we want to have freedom to make changes to the spec and the implementation without worrying about breaking other apps or webpages. Can the email app work without Web Components? Either way, I definitely agree that, we should certainly look at reducing those 150ms. But do people really feel comfortable with making that the only plan? Can we make that happen for Gecko 34 (September 1st)? At what point do we start working on a backup plan such as the ones discussed in this thread? So this is the heart of the matter (at least for email/gaia apps and the idea of "privileged"): "certified" is being used as an implementation pref switch. There will always be new things we will want to try, and it helps if Gecko has a well-constrained set of web apps to try it out, to work out any issues in the Gecko implementation, maybe help give early feedback on specs. We need a controlled space that also gets some real world use, but where we can hopefully update as the Gecko implementation changes. I am particularly interested in service workers because I am hopeful it will eliminate the need for email's cookie cache that is used for fast startup. I expect that will also only be enabled for "certified" apps in the beginning. This comes at a cost: Gaia apps will not be able to do installs/updates via the Marketplace, which also makes it hard to use them on Android via the web runtime, but the hope is that by having this early testing we have better APIs and implementations for the web platform in the long run. So, I think we just need to set the expectation for at least another year or two, that the gaia set of apps will not be able to be "privileged", because we need them as early beta testers for features and capabilities we are building out for the mobile web platform. In the short term this creates a bit of an issue for email. The "privileged" setting helped with the new CSP policy desires (bug 1012652) but since email is part of gaia, and email uses some of the shared resources, I filed bug 1027185 to switch email back to "certified", and we'll have to use another approach for bug 1012652. I will confirm the cause of the slowdown for bug 1024005 before switching email back to certified. That should end the "privileged" diversion for this thread. James ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Icon fonts in FxOS
On 6/17/14, 10:08 AM, Vivien Nicolas wrote: That's true. Actually there are many other hacks that depends on the fact that application are certified. So even if I would like to have more apps as privileged apps just for the principle, it's not that simple. And we may need to reconsider the |privileged| status of the email app based on some of the use case on some low end devices for now. So one of the only reason the email app has been made |privileged| is for some CSP compliance things, and because it does not needs APIs that are certified-only. But we may need to keep it certified for perf reasons if needed. It will depends on the impact of icon font there. I appreciate there are always tradeoffs, but I also want to caution against just proceeding because there is an escape value via certified. We have a train model, and if it takes another train to avoid certified-only, all apps benefit. It is already disconcerting that just switching the type value in the manifest from certified to privileged, we see a 20ms slowdown[1]. The greater concern is these certified escapes build up, and then taking the time to undo them later eats into the next certified escape that is wanted, so the gap will continue to grow. A good way to start fighting the issue is to stop adding to the pile. On icon fonts, it would be good to make sure there implemented with accessibility in mind. This document[1] talks about that, and mentions a Firefox bug[2] about aria-hidden that may need some attention if icon fonts are used in buttons. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1024005 [2] http://filamentgroup.com/lab/bulletproof_icon_fonts.html [3] https://bugzilla.mozilla.org/show_bug.cgi?id=948540 James ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Icon fonts in FxOS
On 6/16/14, 12:34 PM, Jet Villegas wrote: I also propose that we make any required code changes in v2.0 so that non-certified apps can't get unrestricted use of the font. All the options proposed (#2,3, or 4,) have drawbacks, the common one being that they may be overly restrictive. The Gaia email app has gone privileged instead of certified just recently. I expect that most partners will want to deliver the email app with the same look and feel as the other apps that may be certified. If that means the use of the icon font, we might have some trouble. In general, I prefer solutions that do not require certified status, as I hope more apps for gaia can move to privileged and even be delivered through the Marketplace and for Android devices that can use Marketplace apps. I can appreciate there are other factors involved, just mentioning a general desire to move more to apps out of the certified embrace. For email, I will likely look for any alternatives that allow us to stay privileged instead of reverting to certified. James ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
