Re: [whatwg] Proposal: navigator.cores
On Wed, Jul 2, 2014 at 2:19 AM, Ryosuke Niwa rn...@apple.com wrote: On May 3, 2014, at 10:49 AM, Adam Barth w...@adambarth.com wrote: Over on blink-dev, we've been discussing [1] adding a property to navigator that reports the number of cores [2]. As far as I can tell, this functionality exists in every other platform (including iOS and Android). Some of the use cases for this feature have been discussed previously on this mailing list [3] and rejected in favor of a more complex system, perhaps similar to Grand Central Dispatch [4]. Others have raised concerns that exposing the number of cores could lead to increased fidelity of fingerprinting [5]. My view is that the fingerprinting risks are minimal. This information is already available to web sites that wish to spend a few seconds probing your machine [6]. Obviously, exposing this property makes that easier and more accurate, which is why it's useful for developers. IMHO, a more complex worker pool system would be valuable, but most systems that have such a worker pool system also report the number of hardware threads available. Examples: C++: std::thread::hardware_concurrency(); Win32: GetSystemInfo returns dwNumberOfProcessors POSIX: sysctl returns HW_AVAILCPU or HW_NCPU Java: Runtime.getRuntime().availableProcessors(); Python: multiprocessing.cpu_count() In fact, the web was the only platform I could find that didn't make the number of cores available to developers. FWIW, this property has been added to WebKit [1] and Blink [2] although that's not an indication of any browser actually shipping it for WebKit. Since there are now 2 implementations, it should be added to the spec instead of just being a wiki.
Re: [whatwg] Proposal: navigator.cores
On Wed, Jul 2, 2014 at 8:58 AM, Rik Cabanier caban...@gmail.com wrote: Since there are now 2 implementations, it should be added to the spec instead of just being a wiki. That depends on whether other vendors are objecting. Looks like that is the case: https://groups.google.com/d/msg/mozilla.dev.platform/QnhfUVw9jCI/PEFuf5a_0YQJ -- http://annevankesteren.nl/
Re: [whatwg] Effect on window.opener when navigating an existing window using window.open
On 2 July 2014 03:18, Ryosuke Niwa rn...@apple.com wrote: Could you point me to a specific test case that demonstrates the difference? Sure, here you go: https://people.mozilla.org/~bowen/openerTest/openerTest.html In IE you get firstOpener alerted both times, which is as spec. In Firefox and Chrome secondOpener is alerted the second time. I'm almost embarrassed to say that I don't have Safari to test against, but I believe it's the same as Firefox and Chrome. I've got a fix for Gecko, but we're concerned that there might be some compat issues and I haven't had time to look into it. If I remember correctly the fix for WebKit was pretty straight forward, so if you would be able to take on the compat testing that would be fantastic. Cheers, Bob
Re: [whatwg] Proposal: navigator.cores
On Wed, Jul 2, 2014 at 10:37 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Jul 2, 2014 at 8:58 AM, Rik Cabanier caban...@gmail.com wrote: Since there are now 2 implementations, it should be added to the spec instead of just being a wiki. That depends on whether other vendors are objecting. Looks like that is the case: https://groups.google.com/d/msg/mozilla.dev.platform/QnhfUVw9jCI/PEFuf5a_0YQJ That thread concluded with a let's see how this feature is going to be used before we commit. Blink and WebKit certainly are in favor.
Re: [whatwg] Proposal: navigator.cores
On Wed, Jul 2, 2014 at 3:31 PM, Rik Cabanier caban...@gmail.com wrote: That thread concluded with a let's see how this feature is going to be used before we commit. I cannot find that quote. -- http://annevankesteren.nl/
Re: [whatwg] High-density canvases
On Fri, Jun 27, 2014 at 6:42 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Sat, Jun 28, 2014 at 3:41 AM, Justin Novosad ju...@google.com wrote: Example of a problematic renderedsizechange event listener: canvas.width = Math.floor(canvas.renderedPixelWidth * myPixelScale); canvas.height = Math.floor(canvas.renderedPixelHeight * myPixelScale); I don't know why anyone would actually want to do this. Could be performance, saving memory, retro game pixelated look, who knows. For sure people are going to end up doing stuff like this if the API allows it. The scary part is that web-developpers may test their page and everything will seem OK, but then some clients that have a full page zoom at a specific ratio or If we don't want to bother supporting cases like this, then we should constrain the API. For example we could implement an auto-resize option instead of exposing renderedPixelWidth/Height, that way the browser stays in charge of the resizing. This behavior seems sound at first glance, but because that arithmetic may induce a change to the intrinsic aspect ratio due to rounding, step 3) may not jump out of the loop during the second iteration, thus allowing the feedback loop to keep spinning. What are the specified values of CSS 'width' and 'height' on the canvas in your example? Anything but 'auto'. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w
Re: [whatwg] Proposal: navigator.cores
On Jul 2, 2014, at 6:31 AM, Rik Cabanier caban...@gmail.com wrote: On Wed, Jul 2, 2014 at 10:37 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Jul 2, 2014 at 8:58 AM, Rik Cabanier caban...@gmail.com wrote: Since there are now 2 implementations, it should be added to the spec instead of just being a wiki. That depends on whether other vendors are objecting. Looks like that is the case: https://groups.google.com/d/msg/mozilla.dev.platform/QnhfUVw9jCI/PEFuf5a_0YQJ That thread concluded with a let's see how this feature is going to be used before we commit. Blink and WebKit certainly are in favor. I'm not certain if that accurately reflects where the WebKit community stands. There was a lot of contentious discussion on the webkit-dev thread [1] and Bugzilla [2] I agree some people are in favor but I wouldn't say everyone is definitely in the favor. Also, WebKit's implementation also caps the number of cores at eight to mitigate some of the finger printing / privacy concerns raised. [1] https://bugs.webkit.org/show_bug.cgi?id=132588 [2] https://lists.webkit.org/pipermail/webkit-dev/2014-May/thread.html#26511 - R. Niwa
Re: [whatwg] Proposal: navigator.cores
On Wed, Jul 2, 2014 at 11:31 AM, Rik Cabanier caban...@gmail.com wrote: I thought that those concerns were addressed with the addition of a maximum number of cores? That doesn't address much, if anything. Also, WebKit's implementation also caps the number of cores at eight to mitigate some of the finger printing / privacy concerns raised. This is a misunderstanding of what fingerprinting is. It's not about having rare values, like the one user in a thousand with 32 cores. (That matters too, but it's not the main issue.) Fingerprinting is having data that persists for the user at all, such as whether a user has one or two or four cores, which are then combined with as many other data points as possible to create a fingerprint. Limiting the maximum exposed number of cores doesn't affect this. -- Glenn Maynard
Re: [whatwg] Proposal: navigator.cores
On 7/2/2014 8:31 AM, Rik Cabanier wrote: That thread concluded with a let's see how this feature is going to be used before we commit. Blink and WebKit certainly are in favor. I went back and looked at the later messages in that thread. Your argument implies that a plurality of engines implementing this feature would mollify the detractors, and that is certainly not my reading. People brought up serious concerns about the utility and wisdom of this API, and summaries like yours very much feel like an attempt to avoid addressing those concerns by creating facts on the ground instead. The concerns I recall off the top of my head, to wit: 1. Fingerprinting 2. Use of the API is implicitly assuming that the browser uses only one thread, which is not a safe assumption. 3. The existence and probable eventual takeover of asynchronous multiple core architectures. 4. There are better ways to achieve the desired use cases. I've personally mused that the usual motivation for this feature is essentially predicated on the notion that there is too much work to be assigned for a weak computer, yet the advocates of this API respond to comments about the problems involved with high dynamic usage of the computer with the scheduler can solve it--the same scheduler whose inability to cope with too much work is the basis for the API in the first place. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
Re: [whatwg] Proposal: navigator.cores
On 7/2/14, 3:21 PM, Rik Cabanier wrote: facts = 2 implementations. I certainly didn't say anything else. You said, and I quote: That thread concluded with a let's see how this feature is going to be used before we commit. Anyway, 2 implementations is a necessary condition for a REC, not a sufficient one. -Boris
Re: [whatwg] Proposal: navigator.cores
On Wed, Jul 2, 2014 at 9:27 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 7/2/14, 3:21 PM, Rik Cabanier wrote: facts = 2 implementations. I certainly didn't say anything else. You said, and I quote: That thread concluded with a let's see how this feature is going to be used before we commit. ah, I see now that he responded to my second message. Yes, I was off on there. Anyway, 2 implementations is a necessary condition for a REC, not a sufficient one. This is from the WHATWG site: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F The WHATWG doesn't have a hard requirement for 2 implementations but it certainly is an indication that it should be more than just a wiki.
[whatwg] Hit regions: exception when the region has no pixels
The canvas spec [1] currently states: If any of the following conditions are met, throw a NotSupportedError exception and abort these steps: ... The specified pixels has no pixels. Since the specified pixels are the union of the clipping path and the current path, it will be nearly impossible for an author to determine if a hit region has no pixels. Can't we relax this requirement and simply not set up a new hit region if there are no pixels? 1: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#hit-region
Re: [whatwg] Hit regions: exception when the region has no pixels
On Wed, 2 Jul 2014, Rik Cabanier wrote: The canvas spec [1] currently states: If any of the following conditions are met, throw a NotSupportedError exception and abort these steps: ... The specified pixels has no pixels. Since the specified pixels are the union of the clipping path and the current path, it will be nearly impossible for an author to determine if a hit region has no pixels. Can't we relax this requirement and simply not set up a new hit region if there are no pixels? Yeah, that seems reasonable. Please assume that the spec is so adjusted. (I'm in the middle of updating my pipeline, so I can't easily make any spec edits right this second. Sorry about that, everyone. I promise I'll be getting back to my old productive rate of response as soon as the pipeline is back up and running!) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] High-density canvases
On Thu, Jul 3, 2014 at 3:03 AM, Justin Novosad ju...@google.com wrote: On Fri, Jun 27, 2014 at 6:42 PM, Robert O'Callahan rob...@ocallahan.org wrote: This behavior seems sound at first glance, but because that arithmetic may induce a change to the intrinsic aspect ratio due to rounding, step 3) may not jump out of the loop during the second iteration, thus allowing the feedback loop to keep spinning. What are the specified values of CSS 'width' and 'height' on the canvas in your example? Anything but 'auto'. If both 'width' and 'height' are not 'auto' then changing the canvas width and height will not trigger a change in the canvas content-box, so renderedPixelWidth/Height should not change, so there's no loop here. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w
