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
On Sun, Aug 2, 2015 at 3:47 AM, Xidorn Quan wrote:
> On Sun, Aug 2, 2015 at 7:57 PM, Kyle Huey wrote:
>> On Sun, Aug 2, 2015 at 2:56 AM, Hubert Figuière wrote:
>>> On 02/08/15 04:55 AM, smaug wrote:
A new type of error 'auto' seems to cause, now seen on m-i, is
auto foo = new SomeRefCo
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
Hi,
Would it be reasonable to remove nsITimer.TYPE_REPEATING_PRECISE?
The docs for it say "Use this timer type with extreme caution.
Chances are, this is not what you want."
https://bugzilla.mozilla.org/show_bug.cgi?id=650379 introduced
nsITimer.TYPE_REPEATING_PRECISE_CAN_SKIP as a safer alterna
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 8/2/2015 10:21 AM, Boris Zbarsky wrote:
On 8/2/15 7:34 AM, Hubert Figuière wrote:
This is also part of why I'd suggest having an construction method that
will return a smart pointer - preventing the use of raw pointers.
Returning an already_AddRefed would prevent the use of raw pointers,
b
On 8/2/15 7:34 AM, Hubert Figuière wrote:
This is also part of why I'd suggest having an construction method that
will return a smart pointer - preventing the use of raw pointers.
Returning an already_AddRefed would prevent the use of raw pointers, but
would leak if the caller used "auto", rig
On 08/02/2015 02:34 PM, Hubert Figuière wrote:
On 02/08/15 07:17 AM, smaug wrote:
Probably we should generally avoid using constructor directly for
those cases. Instead, use helper functions like MakeUnique() or
MakeAndAddRef(), which is much safer.
MakeAndAddRef would have the same problem as
On 02/08/15 07:17 AM, smaug wrote:
>> Probably we should generally avoid using constructor directly for
>> those cases. Instead, use helper functions like MakeUnique() or
>> MakeAndAddRef(), which is much safer.
>
> MakeAndAddRef would have the same problem as MakeUnique. Doesn't really
> tell wha
On 02/08/15 05:57 AM, Kyle Huey wrote:
> On Sun, Aug 2, 2015 at 2:56 AM, Hubert Figuière wrote:
>> On 02/08/15 04:55 AM, smaug wrote:
>>> A new type of error 'auto' seems to cause, now seen on m-i, is
>>> auto foo = new SomeRefCountedFoo();
>>>
>>> That hides that foo is a raw pointer but we shoul
On 08/02/2015 01:47 PM, Xidorn Quan wrote:
On Sun, Aug 2, 2015 at 7:57 PM, Kyle Huey wrote:
On Sun, Aug 2, 2015 at 2:56 AM, Hubert Figuière wrote:
On 02/08/15 04:55 AM, smaug wrote:
A new type of error 'auto' seems to cause, now seen on m-i, is
auto foo = new SomeRefCountedFoo();
That hides
On Sun, Aug 2, 2015 at 7:57 PM, Kyle Huey wrote:
> On Sun, Aug 2, 2015 at 2:56 AM, Hubert Figuière wrote:
>> On 02/08/15 04:55 AM, smaug wrote:
>>> A new type of error 'auto' seems to cause, now seen on m-i, is
>>> auto foo = new SomeRefCountedFoo();
>>>
>>> That hides that foo is a raw pointer b
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 2:56 AM, Hubert Figuière wrote:
> On 02/08/15 04:55 AM, smaug wrote:
>> A new type of error 'auto' seems to cause, now seen on m-i, is
>> auto foo = new SomeRefCountedFoo();
>>
>> That hides that foo is a raw pointer but we should be using nsRefPtr.
>>
>> So please, consider
(Cross-post to dev-platform and dev-b2g, reply-to dev-b2g)
Hi,
sometimes we need to track crashes, and sometimes those are crashes
happening with unit tests.
So I just landed in bug 1177165 a change so that you can to run the test
runner in gdb.
You can find more information on MDN [1].
Please
On 02/08/15 04:55 AM, smaug wrote:
> A new type of error 'auto' seems to cause, now seen on m-i, is
> auto foo = new SomeRefCountedFoo();
>
> That hides that foo is a raw pointer but we should be using nsRefPtr.
>
> So please, consider again when about to use auto. It usually doesn't
> make the c
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
A new type of error 'auto' seems to cause, now seen on m-i, is
auto foo = new SomeRefCountedFoo();
That hides that foo is a raw pointer but we should be using nsRefPtr.
So please, consider again when about to use auto. It usually doesn't make the
code easier to read,
and it occasionally just le
23 matches
Mail list logo
