Is there any concerns about the solution I'm proposing or should I move
forward ?
On Fri, Oct 16, 2015 at 12:29 PM, Vivien Nicolas
wrote:
>
>
> On Thu, Oct 8, 2015 at 6:10 PM, Mounir Lamouri wrote:
>
>> Note that Chrome 46 has a way to work around the white screen while a
>> page load using a n
On Thu, Oct 8, 2015 at 6:10 PM, 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
On Sat, Oct 10, 2015 at 9:26 PM, wrote:
> On Saturday, October 10, 2015 at 4:28:30 AM UTC-7, Mounir Lamouri wrote:
>> On Sat, 10 Oct 2015, at 02:02, zbranie...@mozilla.com wrote:
>> > On Friday, October 9, 2015 at 10:51:54 AM UTC-7, Mounir Lamouri wrote:
>> > > As far as speed feeling goes, they
On Saturday, October 10, 2015 at 4:28:30 AM UTC-7, Mounir Lamouri wrote:
> On Sat, 10 Oct 2015, at 02:02, zbranie...@mozilla.com wrote:
> > On Friday, October 9, 2015 at 10:51:54 AM UTC-7, Mounir Lamouri wrote:
> > > As far as speed feeling goes, they would win to show something as soon
> > > as po
There should be an answer in the middle. Showing something as soon as
possible is best iif it not a half baked part of the UI.
So for example showing the navigation chrome first is good, if it is not
rebuilding right after. Then showing the app content.
But I'm not convinced any of us is the best
On Sat, 10 Oct 2015, at 02:02, zbranie...@mozilla.com wrote:
> On Friday, October 9, 2015 at 10:51:54 AM UTC-7, Mounir Lamouri wrote:
> > As far as speed feeling goes, they would win to show something as soon
> > as possible and handle any post-first paint loading themselves.
>
> That is unfortuna
On Friday, October 9, 2015 at 10:51:54 AM UTC-7, Mounir Lamouri wrote:
> As far as speed feeling goes, they would win to show something as soon
> as possible and handle any post-first paint loading themselves.
That is unfortunately not consistent with my experience. People tend to
perceive visibl
On Fri, 9 Oct 2015, at 16:27, Vivien Nicolas wrote:
> On Thu, Oct 8, 2015 at 6:10 PM, 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 ha
On Thu, Oct 8, 2015 at 6:10 PM, 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
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 p
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-em
I also forgot to say that the proposed solution does not help for cases like
bug 1199674 afaict.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
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/b
On 8/6/15 4:09 AM, Jonas Sicking wrote:
Agreed. Would it work to define that they behave like inside of a
display:none layout tree? Or will that still force some cascade
calculations to happen?
If you getComputedStyle then you'll still end up doing style computation
in display:none subtrees.
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
On Friday, August 14, 2015 at 3:59:23 PM UTC-7, James Burke wrote:
> There does not seem to be a need for extra APIs in the browser for
> controlling layouts or paints using this approach:
Great work James!
I like that we can play with this approach right now, but I'm wondering if we
should stil
My assumption was that the preferred fallback would be equivalent to the
behavior of the element were ignored. I guess people might want to
hand-implement their own lazy-loading stuff, but given that the site
"works" without it, most people probably won't.
On Tue, Aug 18, 2015 at 6:57 AM, Ehsan A
On 2015-08-04 3:08 PM, Jonas Sicking wrote:
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, a
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
Le 04/08/2015 21:10, James Burke a écrit :
> 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 a
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
On Thu, Aug 6, 2015 at 10:09 AM, Jonas Sicking wrote:
> Agreed. Would it work to define that they behave like inside of a
> display:none layout tree? Or will that still force some cascade
> calculations to happen?
That might actually be sufficient for now, yes.
--
https://annevankesteren.nl/
_
On Thu, Aug 6, 2015 at 1:07 AM, Anne van Kesteren wrote:
>> A simple solution here would be to simply use MutationObservers to
>> detect when the last is removed. Any time that layout
>> properties are queried after that they could behave like they
>> currently do, i.e. force a synchronous layout
On Thu, Aug 6, 2015 at 9:58 AM, Jonas Sicking wrote:
> Lots of features force layout. Accessing any layout related properties
> like .offsetTop or .getComputedStyle() force a layout.
Yes. dglazkov has a library that enumerates the full set. CSSOM should
just define it.
> Having an API which pro
On Thu, Aug 6, 2015 at 12:53 AM, Anne van Kesteren wrote:
> On Tue, Aug 4, 2015 at 9: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 bel
On Wed, Aug 5, 2015 at 1:02 AM, Bobby Holley wrote:
> I'll defer to Anne et al on this one, but I think adding a second pattern
> for delivering load notifications is worse than the inconvenience of the
> existing pattern.
We will be adding document.loaded,
On Tue, Aug 4, 2015 at 9: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 t
On Tue, Aug 4, 2015 at 3:51 PM, Zibi Braniecki wrote:
> I'm not sure if the multiple- solution is going to be really working
> well.
>
> From the perspective of a gaia app developer that means that he has to
> inject manually a new for every library he wants to use.
>
No, the developer merely h
I'm not sure if the multiple- solution is going to be really working well.
>From the perspective of a gaia app developer that means that he has to inject
>manually a new for every library he wants to use.
That feels weird. I would rather expect a single that app controls
fully, sort of a mast
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
On Tue, Aug 4, 2015 at 12:10 PM, James Burke wrote:
> 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 Jo
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
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
(And note that it would be trivial to implement a programmatic promise-y
API on top of this as a library, if people want that).
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 g
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? Th
On Tue, Aug 4, 2015 at 2:55 AM, Anne van Kesteren wrote:
> On Tue, Aug 4, 2015 at 11:07 AM, James Graham wrote:
>> I am extremely wary of designing a solution like this where there's a single
>> master switch that any code can unilaterally flip; if the assumption that
>> libraries will never want
On Tue, Aug 4, 2015 at 11:07 AM, James Graham wrote:
> I am extremely wary of designing a solution like this where there's a single
> master switch that any code can unilaterally flip; if the assumption that
> libraries will never want to delay rendering turns out to be false it will
> force page
Le 30/07/2015 22:28, Jeff Muizelaar a écrit :
> Can't you just make everything display:none until you're ready to show it?
Note that even with "display: none" we run refreshStyles everytime an
element is added to the page. I don't know if this is fast when the
whole document.body is hidden though.
On 03/08/15 16:46, Bobby Holley wrote:
On Mon, Aug 3, 2015 at 12:37 AM, Jonas Sicking wrote:
On Mon, Aug 3, 2015 at 12:32 AM, Anne van Kesteren
wrote:
On Mon, Aug 3, 2015 at 9:23 AM, Jonas Sicking wrote:
I think something like a might be a
simpler solution here. Coupled with either simply
On Mon, Aug 3, 2015 at 12:37 AM, Jonas Sicking wrote:
> On Mon, Aug 3, 2015 at 12:32 AM, Anne van Kesteren
> wrote:
> > On Mon, Aug 3, 2015 at 9:23 AM, Jonas Sicking wrote:
> >> I think something like a might be a
> >> simpler solution here. Coupled with either simply removing the
> >> from t
On Mon, Aug 3, 2015 at 12:32 AM, Anne van Kesteren wrote:
> On Mon, Aug 3, 2015 at 9:23 AM, Jonas Sicking wrote:
>> I think something like a might be a
>> simpler solution here. Coupled with either simply removing the
>> from the DOM, or having a function which indicates that rendering is
>> ok
On Mon, Aug 3, 2015 at 9:23 AM, Jonas Sicking wrote:
> I think something like a might be a
> simpler solution here. Coupled with either simply removing the
> from the DOM, or having a function which indicates that rendering is
> ok.
Neither of those deal well with multiple libraries being inclu
On Sun, Aug 2, 2015 at 11:12 PM, Anne van Kesteren wrote:
> On Mon, Aug 3, 2015 at 7:59 AM, Jonas Sicking wrote:
>> Ah, yes, that makes sense.
>
> Is this yet another API where we want to basically have an internal
> list of promises?
>
> someInstance.doNotRenderUntil(promise)
I don't have a s
On Sunday, August 2, 2015 at 10:47:26 PM UTC-7, Wilson Page wrote:
> Are we expecting that this will reduce unwanted layout/paint cycles on the
> critical path and thus minimise the 'white flash of doom'?
Absolutely.
I believe that that's the primary goal, to replace the current race condition
b
On Mon, Aug 3, 2015 at 7:59 AM, Jonas Sicking wrote:
> Ah, yes, that makes sense.
Is this yet another API where we want to basically have an internal
list of promises?
someInstance.doNotRenderUntil(promise)
--
https://annevankesteren.nl/
___
dev-p
On Sun, Aug 2, 2015 at 10:28 PM, Robert O'Callahan wrote:
> On Mon, Aug 3, 2015 at 4:53 PM, Jonas Sicking wrote:
>>
>> The need is not for an event, no? But rather for an API which allows
>> the page to tell the browser that it's ready for initial rendering?
>
> Right. Which gets turned into an e
Are we expecting that this will reduce unwanted layout/paint cycles on the
critical path and thus minimise the 'white flash of doom'? If not what are
the options for killing this?
If the user has to see anything before the new 'please-draw-me' event, we'd
probably like to see the app's background
On Mon, Aug 3, 2015 at 4:53 PM, Jonas Sicking wrote:
> The need is not for an event, no? But rather for an API which allows
> the page to tell the browser that it's ready for initial rendering?
>
Right. Which gets turned into an event that's sent to the browser.
Rob
--
lbir ye,ea yer.tnietoehr
On Sun, Aug 2, 2015 at 2:41 PM, Robert O'Callahan wrote:
> On Mon, Aug 3, 2015 at 8:15 AM, Jonas Sicking wrote:
>>
>> Often times the "chrome" of a webapp is ready before various other
>> things that are loaded during initial page load is loaded.
>
> OK then, I guess a new event is needed.
The n
On Mon, Aug 3, 2015 at 8:15 AM, Jonas Sicking wrote:
> Often times the "chrome" of a webapp is ready before various other
> things that are loaded during initial page load is loaded.
>
OK then, I guess a new event is needed.
Rob
--
lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnen
On Sun, Aug 2, 2015 at 2:03 AM, Robert O'Callahan wrote:
> On Sun, Aug 2, 2015 at 11:58 AM, Zibi Braniecki <
> zbigniew.branie...@gmail.com> wrote:
>
>> So maybe we would need another event that the website fires to indicate
>> when it for paint/cache/screenshot.
>
> Assuming pages have an easy wa
On Sunday, August 2, 2015 at 2:03:28 AM UTC-7, Robert O'Callahan wrote:
> On Sun, Aug 2, 2015 at 11:58 AM, Zibi Braniecki wrote:
>
> > So maybe we would need another event that the website fires to indicate
> > when it for paint/cache/screenshot.
> >
>
> Assuming pages have an easy way to block t
On Sun, Aug 2, 2015 at 11:58 AM, Zibi Braniecki <
zbigniew.branie...@gmail.com> wrote:
> So maybe we would need another event that the website fires to indicate
> when it for paint/cache/screenshot.
>
Assuming pages have an easy way to block the 'load' event until they're
ready, can this just be
On Saturday, August 1, 2015 at 3:01:39 PM UTC-7, Jonas Sicking wrote:
> On Sat, Aug 1, 2015 at 12:30 PM, Zibi Braniecki wrote:
> > 2) We want to bring app to foreground/paint it only when the app's chrome
> > is visually complete.
>
> I would very much want this. Right now, during a navigation fr
On Sat, Aug 1, 2015 at 12:30 PM, Zibi Braniecki
wrote:
> 2) We want to bring app to foreground/paint it only when the app's chrome is
> visually complete.
I would very much want this. Right now, during a navigation from page
A to page B I believe that we render A until we've parsed B's opening
This is something I've been asking for for quite a while.
We have this state with runtime localization where we have to do backflips in
order to win the race with Gecko to firstPaint.
I filed a bug for getting an API to prevent frame creation [0] and got a
response that display: none should do
It should be represented as a color layer which is very cheap. We should
only composite it once. We will use a bit of memory bandwidth but nothing
major, the main thread impact should be very small.
I agree, we should really have some data to support that drawing something
like a display:none is c
On Thu, Jul 30, 2015 at 4:27 PM, James Burke wrote:
> 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, wh
James Burke writes:
> 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/pai
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
I can't speak about the validity of the requirement, but in terms of
API, we probably want something more compositional, if several codepaths
need to stop rendering. And then, we end up with the possibility that
someone forgets to enable rendering, with all the ensuing debugging joy.
Since this is
Can't you just make everything display:none until you're ready to show it?
-Jeff
On Thu, Jul 30, 2015 at 4:20 PM, 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:
>
> * ECMAS
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 regis
63 matches
Mail list logo
