Games for mobile phones, handheld devices, and laptops often show a
battery indicator and/or a clock in the corner of the screen while
running in fullscreen mode. That's the only good reason I can think of
off-hand.
On 3 August 2015 at 12:55, Chris Peterson wrote:
> What is a legitimate use case
On Mon, Aug 3, 2015 at 6:07 PM, Jonas Sicking wrote:
> How would you make a factory function like the above fail?
Don't allow for the possibility. If Foo::Create() is directly
analogous to new Foo(), then it can't fail. Leave the failing for
later method calls.
On Mon, Aug 3, 2015 at 6:07 PM, Jonas Sicking wrote:
How would you make a factory function like the above fail? Returning
> an nsresult will make it not much better than NS_NewFoo() pattern.
> Returning null won't let you indicate a useful error code (though
> maybe there's no such thing as usefu
On Mon, Aug 3, 2015 at 6:03 PM, Mike Hommey wrote:
> On Mon, Aug 03, 2015 at 05:55:01PM -0700, Jonas Sicking wrote:
>> On Mon, Aug 3, 2015 at 5:06 PM, Karl Tomlinson wrote:
>> > but I don't see much advantage of public constructors over
>> > something like
>> >
>> > static already_AddRefed Foo:
On Mon, Aug 03, 2015 at 05:55:01PM -0700, Jonas Sicking wrote:
> On Mon, Aug 3, 2015 at 5:06 PM, Karl Tomlinson wrote:
> > but I don't see much advantage of public constructors over
> > something like
> >
> > static already_AddRefed Foo::Create()
> >
> > or
> >
> > static nsRefPtr Foo::Make()
On Mon, Aug 3, 2015 at 5:06 PM, Karl Tomlinson wrote:
> but I don't see much advantage of public constructors over
> something like
>
> static already_AddRefed Foo::Create()
>
> or
>
> static nsRefPtr Foo::Make()
Fair enough. Though it is somewhat more boilerplate in the class
itself. But may
FWIW Webkit has long had the convention of using Foo::create() as the sole
creation point for refcounted objects. I like the idea. Apart from
enforcing the invariant that every new object is addrefed, it can slightly
optimize object creation by initializing the refcount to 1.
Rob
--
lbir ye,ea ye
Jonas Sicking writes:
> On Sun, Aug 2, 2015 at 3:47 AM, Xidorn Quan wrote:
>> Probably we should generally avoid using constructor directly for
>> those cases. Instead, use helper functions like MakeUnique() or
>> MakeAndAddRef(), which is much safer.
>
> We used to have NS_NewFoo() objects all o
What is a legitimate use case for a web page to know my battery status?
Battery level and time remaining can be used to fingerprint users.
A mobile webapp might use battery level to throttle its activity, but
that could be something the OS handles by pausing or throttling apps
directly or broa
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 Sun, Aug 2, 2015 at 8:37 PM, Joshua Cranmer 🐧 wrote:
> I've discussed this several times, but with we added operator T*() && =
> delete;, that would prevent the scenario you're talking about here.
And FWIW, I have patches that I'm going to shortly submit to bug
1179451 that do this for nsRefPt
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
14 matches
Mail list logo
