On 08/02/2015 07:17 AM, smaug wrote:
> MakeAndAddRef would have the same problem as MakeUnique. Doesn't really tell
> what type is returned.
For the MakeUnique uses I've added (doubtless many more have popped up since),
I've pretty much always tried to use |auto|. MakeUnique, and std::make_uniq
On Sun, Aug 2, 2015 at 10:31 PM, Nicholas Nethercote
wrote:
>
> Would it be reasonable to remove nsITimer.TYPE_REPEATING_PRECISE?
I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1190735 for this,
and a patch to do ithas r+. I thought I'd mention it here, before I
land it, in case anybody has
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
One change of note: the MSG/cubeb subcomponent is now called
MSG/cubeb/GMP. This is to help folks find out where to file GMP bugs.
NOTE: If a particular GMP bug can only affect Playback, we may move that
bug under Playback when we triage it. If you're not sure where a new GMP
bug should be file
Today's MemShrink meeting is brought to you by proper reference counting in
HTML5 media source extensions:
https://bugzilla.mozilla.org/show_bug.cgi?id=1190019
The wiki page for this meeting is at:
https://wiki.mozilla.org/Performance/MemShrink
Agenda:
* Prioritize unprioritized MemShrink bugs
TL;DR - We have reduced the amount of runtime warnings during testing by 90%.
As of today we are down to 66K warnings during linux64 debug testing; this is
down from >600K back in June. There are bugs on file for most of the remaining
top offenders blocking tracking bug 765224 [1]. It's time to
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
We could also do something like C++14's `make_unique`, which invokes
the constructor for you. Maybe `mkRefPtr(Arguments, To,
Some, Object, Constructor)`? (That way we wouldn't need the overhead on
each declaration - we could use static analysis to prevent direct
construction if we wanted).
Th
The Web API documentation community meeting, with representatives from the
technical evangelism and the API development teams, will take place on Thursday
at 8 AM Pacific Time (see http://bit.ly/1GghwBR for your time zone).
Typical meetings include news about recent API development progress and
(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 9:33 AM, Jonas Sicking wrote:
> Fingerprinting doesn't seem useful if the fingerprint changes every
> few minutes as the battery level changes.
>
> I do agree that there are concerns that if the user has
> private-browsing pages and non-private-browsing pages open at the sa
On Tue, Aug 4, 2015 at 9:33 AM, Jonas Sicking wrote:
> So disabling the API, or fudging its return values, in private
> browsing windows sounds like a good idea. The same applies to features
> like device orientation, proximity/light sensors, network information
> (wifi vs. mobile etc), device ori
Fingerprinting doesn't seem useful if the fingerprint changes every
few minutes as the battery level changes.
I do agree that there are concerns that if the user has
private-browsing pages and non-private-browsing pages open at the same
time, that the pages can track when exactly the battery level
On Tue, Aug 4, 2015 at 8:24 AM, Tim Taubert wrote:
>> Can we just reduce the accuracy of the API? Only give battery level at
>> certain broad breakpoints?
>
> The authors of the cited paper [1] filed a bug report and we fixed that
> for 38 [2].
I should think that more aggressive rounding would
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
Ben Kelly wrote:
> Can we just reduce the accuracy of the API? Only give battery level at
> certain broad breakpoints?
The authors of the cited paper [1] filed a bug report and we fixed that
for 38 [2].
- Tim
[1] http://eprint.iacr.org/2015/616.pdf
[2] https://bugzilla.mozilla.org/show_bug.cgi
Can we just reduce the accuracy of the API? Only give battery level at
certain broad breakpoints?
On Tue, Aug 4, 2015 at 11:02 AM, Chris Hofmann wrote:
> I've seen a lot of GPS related tracking apps that use a lot of power
> putting up warnings to users
> that it might be time to go to low powe
I've seen a lot of GPS related tracking apps that use a lot of power
putting up warnings to users
that it might be time to go to low power mode and shut down the GPS if
you'll need it
later for navigating a critical pathway later in your journey.
-chofmann
On Mon, Aug 3, 2015 at 7:49 PM, Katelyn
Hi everyone,
You can find below the list of new issues found and filed by the Desktop
Manual QA team last week (Week 31: July 27 - July 31).
Additional details on the team's priorities last week, as well as the plans
for the current week can be found at:
https://etherpad.mozilla.org/Deskto
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
27 matches
Mail list logo
