Re: Proposal: revisit and implement navigator.hardwareConcurrency

2016-03-15 Thread Ehsan Akhgari
On 2016-03-14 6:43 PM, Kyle Huey wrote: > On Mon, Mar 14, 2016 at 2:30 PM, Ehsan Akhgari > wrote: > > On 2016-03-14 3:23 PM, Boris Zbarsky wrote: > > On 9/8/15 3:21 PM, Luke Wagner wrote: > >> On a more technical detail: WebKit and Chromium have both sh

Re: Proposal: revisit and implement navigator.hardwareConcurrency

2016-03-14 Thread Boris Zbarsky
On 3/14/16 5:30 PM, Ehsan Akhgari wrote: I brought this up in an in person meeting about this a while ago. It seems pretty hard to justify returning a number more than our per-origin worker limit. To be clear, this will be a clamping different to what WebKit does. OK. So my current plan is t

Re: Proposal: revisit and implement navigator.hardwareConcurrency

2016-03-14 Thread Kyle Huey
On Mon, Mar 14, 2016 at 2:30 PM, Ehsan Akhgari wrote: > On 2016-03-14 3:23 PM, Boris Zbarsky wrote: > > On 9/8/15 3:21 PM, Luke Wagner wrote: > >> On a more technical detail: WebKit and Chromium have both shipped, > >> returning the number of logical processors where WebKit additionally > >> clam

Re: Proposal: revisit and implement navigator.hardwareConcurrency

2016-03-14 Thread Ehsan Akhgari
On 2016-03-14 3:23 PM, Boris Zbarsky wrote: > On 9/8/15 3:21 PM, Luke Wagner wrote: >> On a more technical detail: WebKit and Chromium have both shipped, >> returning the number of logical processors where WebKit additionally >> clamps to 2 (on iOS) or 8 (otherwise) [6] which is explicitly allowed

Re: Proposal: revisit and implement navigator.hardwareConcurrency

2016-03-14 Thread Mats Palmgren
On 9/8/15 3:21 PM, Luke Wagner wrote: On a more technical detail: WebKit and Chromium have both shipped, returning the number of logical processors where WebKit additionally clamps to 2 (on iOS) or 8 (otherwise) [6] which is explicitly allowed by WHATWG text [7]. I would argue for not clamping (

Re: Proposal: revisit and implement navigator.hardwareConcurrency

2016-03-14 Thread Boris Zbarsky
On 9/8/15 3:21 PM, Luke Wagner wrote: On a more technical detail: WebKit and Chromium have both shipped, returning the number of logical processors where WebKit additionally clamps to 2 (on iOS) or 8 (otherwise) [6] which is explicitly allowed by WHATWG text [7]. I would argue for not clamping (

Re: Proposal: revisit and implement navigator.hardwareConcurrency

2015-09-09 Thread Anne van Kesteren
On Tue, Sep 8, 2015 at 9:21 PM, Luke Wagner wrote: > https://wiki.whatwg.org/wiki/Navigator_HW_Concurrency Anyone here interested in making a PR against https://github.com/whatwg/html so the actual standard is updated too? -- https://annevankesteren.nl/

Re: Proposal: revisit and implement navigator.hardwareConcurrency

2015-09-08 Thread Johnny Stenback
While deciding how much resources are available to complex applications is far from an easy task, and one for which there's no obvious best answer, at least not yet, I agree that giving developers this bit of information is critical to enable exploring this space and bring out the any remaining iss

Re: Proposal: revisit and implement navigator.hardwareConcurrency

2015-09-08 Thread Ben Kelly
FWIW, I also think we should implement this. The clamping seems like a reasonable way to be conservative given the fingerprinting concerns. On Tue, Sep 8, 2015 at 3:21 PM, Luke Wagner wrote: > Since the original m.d.p thread on hardwareConcurrency last year: > > https://groups.google.com/d/topi

Re: Proposal: revisit and implement navigator.hardwareConcurrency

2015-09-08 Thread Rik Cabanier
On Tue, Sep 8, 2015 at 2:14 PM, Robert O'Callahan wrote: > Yes, I think we should do this. > Happy to hear the positive responses. I implemented a patch for this last year. Since the code is trivial, it probably still applies: https://bugzilla.mozilla.org/show_bug.cgi?id=1008453

Re: Proposal: revisit and implement navigator.hardwareConcurrency

2015-09-08 Thread Robert O'Callahan
Yes, I think we should do this. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodv

Re: Proposal: revisit and implement navigator.hardwareConcurrency

2015-09-08 Thread Jonas Sicking
I'm ok with implementing this. My biggest concern has always been fingerprinting, and I think that we'll need some way to deal with active (i.e. client-side) fingerprinting anyway, so I don't think this makes a big difference either way. / Jonas On Tue, Sep 8, 2015 at 12:21 PM, Luke Wagner wrote

Proposal: revisit and implement navigator.hardwareConcurrency

2015-09-08 Thread Luke Wagner
Since the original m.d.p thread on hardwareConcurrency last year: https://groups.google.com/d/topic/mozilla.dev.platform/QnhfUVw9jCI/discussion the landscape has shifted (as always) and I think we should reevaluate and implement this feature. What hasn't changed are the arguments, made in the or