Re: [whatwg] Fetch Objects and scripts/stylesheets
On Mon, Jul 28, 2014 at 8:34 PM, Ian Hickson i...@hixie.ch wrote: What's the use case here? Why are we trying to send custom headers on a link? E.g. for img and such you want to turn authentication dialogs off. Cross-origin images can be fine, but not if they start spawning confusing dialogs to users making them leak passwords. -- http://annevankesteren.nl/
Re: [whatwg] Fullscreen API and out-of-process iframe
On Mon, Jul 28, 2014 at 8:16 PM, Adam Barth w...@adambarth.com wrote: I meant a black-box experiment (i.e., no access to browser internal state). Put another way, can you describe a sequence of events in which the author or the user could observe the difference? If not, then the question is moot. Well if both A and B invoke requestFullscreen() that's obviously for different elements. The observable difference would be which element ends up being fullscreen of course and which call would either fail or end up overwriting the other depending on how we decide to deal with this. -- http://annevankesteren.nl/
Re: [whatwg] Fullscreen API and out-of-process iframe
Either: 1) The frames attempt no synchronization and both just call requestFullscreen(). In that case, the observable difference is largely moot. It shouldn't be surprising that racing operations like this cross origin returns a non-deterministic result. This is the position the Chrome out-of-process team is taking for other sorts of actions that have effects visible outside the frame (for example, navigating the top level frame, multiple frames sending a postMessage to the same frame, etc). 2) One frame calls requestFullscreen() and then sends a postMessage() to another frame, which calls requestFullscreen() upon receiving the message. Going fullscreen requires coordination with the browser process, so ordering is preserved by browser IPC message handling. Daniel On Mon, Jul 28, 2014 at 11:56 PM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jul 28, 2014 at 8:16 PM, Adam Barth w...@adambarth.com wrote: I meant a black-box experiment (i.e., no access to browser internal state). Put another way, can you describe a sequence of events in which the author or the user could observe the difference? If not, then the question is moot. Well if both A and B invoke requestFullscreen() that's obviously for different elements. The observable difference would be which element ends up being fullscreen of course and which call would either fail or end up overwriting the other depending on how we decide to deal with this. -- http://annevankesteren.nl/
Re: [whatwg] How to determine content-type of file: protocol
On Thu, Jul 17, 2014 at 2:26 PM, duanyao duan...@ustc.edu wrote: I think rule 5.1 should be applied to both static fetching and XHR consistently. Browsers should set Content-Type header to local files' actual type for XHR, and interpret them accordingly. But firefox developers think this would break some existing codes that already rely on firefox's behavior (see https://bugzilla.mozilla.org/show_bug.cgi?id=1037762). What do you think? Basically, this comes down to what http://fetch.spec.whatwg.org/#basic-fetch should do. For now, unfortunate as it is, file and ftp URLs are left as an exercise for the reader. There's an enormous amount of tricky things to define around file URLs, this being one of them. My theory to date has been that defining those things has less benefit than defining other things, such as parsing URLs or the way fetching works in general. If someone were to sort the issues out and get implementations to converge I would certainly not be opposed to including the result of such work in the specification. -- http://annevankesteren.nl/
Re: [whatwg] apple-touch-icon
On Mon, Jul 28, 2014 at 4:59 PM, John Mellor joh...@google.com wrote: Chrome 30 dropped support[1] for fetching apple-touch-icon-* from well known URLs, since the 404 pages that are usually returned were consuming 3-4% of all mobile bandwidth usage[2]. We're unlikely to reverse that. Good to know – thanks! We still support apple-touch-icon-* via link rel under some circumstances (e.g. for add to homescreen), but they're deprecated[3], since we'd like authors to use the standard for this, i.e.: link rel=shortcut icon sizes=128x128 href=/favicon.png There’s no need for `shortcut` there as per the standard.
Re: [whatwg] Fullscreen API and out-of-process iframe
On Tue, Jul 29, 2014 at 9:51 AM, Daniel Cheng dch...@google.com wrote: 1) The frames attempt no synchronization and both just call requestFullscreen(). In that case, the observable difference is largely moot. It shouldn't be surprising that racing operations like this cross origin returns a non-deterministic result. This is the position the Chrome out-of-process team is taking for other sorts of actions that have effects visible outside the frame (for example, navigating the top level frame, multiple frames sending a postMessage to the same frame, etc). 2) One frame calls requestFullscreen() and then sends a postMessage() to another frame, which calls requestFullscreen() upon receiving the message. Going fullscreen requires coordination with the browser process, so ordering is preserved by browser IPC message handling. So I tried to figure out how one would implement this in JavaScript as an exercise. You'd have a privileged asynchronous API that resizes the top-level browsing context's document's viewport. It calls a callback once that's done, presumably synchronized with animation frames. Now at that point you need to get hold of all your ancestor documents and start changing state outward-in. Some of these ancestor documents you can get a hold of synchronously, but not all. What if there's a cross-origin document inbetween? Now what I'm afraid of is that one of these ancestors or perhaps a descendant is also playing with requestFullscreen() and since the changing of state does not happen globally you end up with inconsistent state. -- http://annevankesteren.nl/
Re: [whatwg] apple-touch-icon
On 29 July 2014 12:46, Mathias Bynens mathi...@opera.com wrote: On Mon, Jul 28, 2014 at 4:59 PM, John Mellor joh...@google.com wrote: We still support apple-touch-icon-* via link rel under some circumstances (e.g. for add to homescreen), but they're deprecated[3], since we'd like authors to use the standard for this, i.e.: link rel=shortcut icon sizes=128x128 href=/favicon.png There’s no need for `shortcut` there as per the standard. Sure, it's just for compatibility with IE11 (IE 9 and 10 allow rel=icon, but only if you also specify type=image/x-icon[1]). [1]: http://blogs.msdn.com/b/ieinternals/archive/2013/09/08/internet-explorer-favicons-png-link-rel-icon-caching.aspx
Re: [whatwg] How to determine content-type of file: protocol
于 2014/7/29 18:48, Anne van Kesteren 写道: On Thu, Jul 17, 2014 at 2:26 PM, duanyao duan...@ustc.edu wrote: I think rule 5.1 should be applied to both static fetching and XHR consistently. Browsers should set Content-Type header to local files' actual type for XHR, and interpret them accordingly. But firefox developers think this would break some existing codes that already rely on firefox's behavior (see https://bugzilla.mozilla.org/show_bug.cgi?id=1037762). What do you think? Basically, this comes down to what http://fetch.spec.whatwg.org/#basic-fetch should do. For now, unfortunate as it is, file and ftp URLs are left as an exercise for the reader. There's an enormous amount of tricky things to define around file URLs, this being one of them. Are there some resources on those tricky things? My theory to date has been that defining those things has less benefit than defining other things, such as parsing URLs or the way fetching works in general. I agree that file protocol is less important than http. However packaged web applications (PhoneGap app, Chrome app, Firefox OS app, Window 8 HTML app, etc) are increasing their popularity, and they are using file: protocol or similar things to access their local assets. So I think it's worthwhile to work on file protocol to reduce porting issues of packaged web applications. If someone were to sort the issues out and get implementations to converge I would certainly not be opposed to including the result of such work in the specification. Firefox developers said they won't change their implementation of XHR with file: before the spec explicitly define the behavior, so it looks like a chicken-egg problem to me. Also I'd like to know some general principles of introducing new URL schemes (like file:) into web standards: (1) Should new URLs mimic http's behaviors as much as possible? Such as status codes, content-type, etc. (2) Should XHR and static resource fetching behave consistently with new URLs? As a web developer, my personal answers are all yes. Regards, Duan Yao.
Re: [whatwg] [Notifications] Persistent notifications depending on Service Workers
To summarize a discussion we had about this on IRC today:
http://krijnhoetmer.nl/irc-logs/whatwg/20140729#l-509
Jungkee wrote a helpful document for features using Service Workers as well:
https://gist.github.com/jungkees/3154398b8deee7c70139
The |serviceWorker| attribute can be added to the NotificationOptions
dictionary and to the Notification interface, and should be set by the
developer to the ServiceWorkerRegistration instance.
navigator.serviceWorker.ready.then(function(registration) {
new Notification(‘Hello, World!’, {
serviceWorker: registration
});
});
When used from a Service Worker, the attribute will implicitly default to
the ServiceWorkerRegistration of the running Service Worker. If
serviceWorker is set to any non-SWR value, a TypeError will be thrown. If
serviceWorker is set to null/undefined within a ServiceWorker context, a
TypeError will be thrown.
1. If registration.activeWorker is null, then:
1. Throw a DOMError with name “InvalidStateError”
2. Abort these steps.
Events will be delivered to either the Notification instance, or to the
Service Worker, not both. All four events will be exposed to a Service
Worker [onnotificationshow, onnotificationclick, onnotificationclose,
onnotificationerror]. The events will receive a NotificationEvent which
will contain a notification instance.
Thanks,
Peter
On Fri, May 16, 2014 at 3:17 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, May 16, 2014 at 4:02 PM, Peter Beverloo bever...@google.com
wrote:
On Fri, May 16, 2014 at 2:57 PM, Anne van Kesteren ann...@annevk.nl
wrote:
Service worker integration makes sense to me. I guess I'll wait with
updating the Notifications API until that is further along.
Do you have a specific milestone in mind?
Probably once it exposes a stable hook for does the current global
have an associated service worker. And if I am to define the service
worker events I suppose some more hooks are needed. Having service
workers in two implementations would also help, as at that point the
stability is a lot less uncertain.
--
http://annevankesteren.nl/
Re: [whatwg] Fetch Objects and scripts/stylesheets
Another concrete example with img tags: sometimes an abusive user will use a site like Facebook as a CDN -- they'll upload a picture and hotlink it from elsewhere. We could insert a time-stamped authentication token as a custom header. Today we sometimes do this via the query string -- giving the user a token that lasts for a few days. This means we bust the user's cache every time we rotate the token. With a custom header, the browser cache stays in tact. Images would also be a great example of where logging headers could be extremely helpful. For example, we could log what module within a page rendered an image and monitor bandwidth usage and CDN cache hit rate on a per module basis. In the past it's taken us a long time to debug issues that could easily be found with this method. On Mon, Jul 28, 2014 at 11:51 PM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jul 28, 2014 at 8:34 PM, Ian Hickson i...@hixie.ch wrote: What's the use case here? Why are we trying to send custom headers on a link? E.g. for img and such you want to turn authentication dialogs off. Cross-origin images can be fine, but not if they start spawning confusing dialogs to users making them leak passwords. -- http://annevankesteren.nl/
Re: [whatwg] Fullscreen API and out-of-process iframe
On Tue, Jul 29, 2014 at 5:14 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Jul 29, 2014 at 9:51 AM, Daniel Cheng dch...@google.com wrote: 1) The frames attempt no synchronization and both just call requestFullscreen(). In that case, the observable difference is largely moot. It shouldn't be surprising that racing operations like this cross origin returns a non-deterministic result. This is the position the Chrome out-of-process team is taking for other sorts of actions that have effects visible outside the frame (for example, navigating the top level frame, multiple frames sending a postMessage to the same frame, etc). 2) One frame calls requestFullscreen() and then sends a postMessage() to another frame, which calls requestFullscreen() upon receiving the message. Going fullscreen requires coordination with the browser process, so ordering is preserved by browser IPC message handling. So I tried to figure out how one would implement this in JavaScript as an exercise. You'd have a privileged asynchronous API that resizes the top-level browsing context's document's viewport. It calls a callback once that's done, presumably synchronized with animation frames. Now at that point you need to get hold of all your ancestor documents and start changing state outward-in. Some of these ancestor documents you can get a hold of synchronously, but not all. What if there's a cross-origin document inbetween? Now what I'm afraid of is that one of these ancestors or perhaps a descendant is also playing with requestFullscreen() and since the changing of state does not happen globally you end up with inconsistent state. Given that you haven't produced a black-box experiment that distinguishes the two approaches, different implementations can use different approaches and be interoperable. Adam
Re: [whatwg] Fullscreen API and out-of-process iframe
On Tue, Jul 29, 2014 at 5:29 PM, Adam Barth w...@adambarth.com wrote: Given that you haven't produced a black-box experiment that distinguishes the two approaches, different implementations can use different approaches and be interoperable. I guess. That still doesn't help us much defining it. However, I'm not convinced that just because I can't come up with an example, there is none. B is nested through A. A invokes requestFullscreen() and then does synchronous XMLHttpRequest, locking its event loop. B also invokes requestFullscreen(), posts a message to A about updating its state. A's synchronous XMLHttpRequest stops, it updates its state per B, and then gets to the point of putting its own element fullscreen. The end result is something that the current specification deems impossible which seems bad. I guess what needs to happen is that when requestFullscreen() is invoked it needs to do synchronous checks and those need to be done again just before the document changes state. And the only check that involves out-of-process iframe (nested browsing contexts) will block I guess, but that only needs to be made at the initial invocation I think. -- http://annevankesteren.nl/
Re: [whatwg] Fullscreen API and out-of-process iframe
On Tue, Jul 29, 2014 at 8:46 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Jul 29, 2014 at 5:29 PM, Adam Barth w...@adambarth.com wrote: Given that you haven't produced a black-box experiment that distinguishes the two approaches, different implementations can use different approaches and be interoperable. I guess. That still doesn't help us much defining it. However, I'm not convinced that just because I can't come up with an example, there is none. B is nested through A. A invokes requestFullscreen() and then does synchronous XMLHttpRequest, locking its event loop. B also invokes requestFullscreen(), posts a message to A about updating its state. A's synchronous XMLHttpRequest stops, it updates its state per B, and then gets to the point of putting its own element fullscreen. The end result is something that the current specification deems impossible which seems bad. I'm not sure I understand the significance of the synchronous XHR. I don't see what would change about your example if it were removed. There doesn't appear to be any known ordering between the two requestFullscreen calls and A only learns about what happens to B asynchronously. I guess what needs to happen is that when requestFullscreen() is invoked it needs to do synchronous checks and those need to be done again just before the document changes state. And the only check that involves out-of-process iframe (nested browsing contexts) will block I guess, but that only needs to be made at the initial invocation I think. I don't think that's the case. Have you started your implementation of out-of-process iframes? Some of these issues are easier to grapple with once you're deeper into the implementation. Adam
Re: [whatwg] Fullscreen API and out-of-process iframe
On Tue, Jul 29, 2014 at 8:46 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Jul 29, 2014 at 5:29 PM, Adam Barth w...@adambarth.com wrote: Given that you haven't produced a black-box experiment that distinguishes the two approaches, different implementations can use different approaches and be interoperable. I guess. That still doesn't help us much defining it. However, I'm not convinced that just because I can't come up with an example, there is none. B is nested through A. A invokes requestFullscreen() and then does synchronous XMLHttpRequest, locking its event loop. B also invokes requestFullscreen(), posts a message to A about updating its state. A's synchronous XMLHttpRequest stops, it updates its state per B, and then gets to the point of putting its own element fullscreen. The end result is something that the current specification deems impossible which seems bad. The race you describe is possible today if you assume A and B are collaborating by communicating with servers that can talk to each other. It's even true if A and B are loaded into different tabs or different browsers completely. A invokes requestFullscreen() or requestPointerLock() or anything else that touches a machine-global resorce and then sends a message over the network to A's server which forwards to B's server which forwards to B. B then invokes requestWhatever() with the 'knowledge' that its invocation has a happens-after relationship with A's, even though in practice A's requestWhatever() may not have propagated through the browser sufficient to touch the shared resource (i.e. ask the OS for fullscreen support / pointer lock / whatnot). This isn't new, but it's so rare and convoluted that I really doubt it ever happens in practice. A more practical sort of race of this nature can happen with NPAPI plugins which in multi-process browsers are a shared, global resource. Chrome (and I believe other multi-process browsers as well) do not run the event loops for different tabs referencing the same plugin in lockstep, so it's very easy for otherwise unrelated tabs to communicate information to each other through a plugin. This can include cross-origin pages if the plugin's same-origin policy is relaxed or relax-able as it is in some cases. It is theoretically possible to construct all sorts of cases where the behavior is black-box distinguishable from running all such tabs in lockstep with each other, but in practice nobody cares. I strongly suspect the situation with cross-origin iframes is similar. While you can construct scenarios where different frames communicate with each other through various channels and come up with answers that seem to contradict knowledge about shared global state, in practice it won't matter. In practice one frame will 'win' and one will 'lose', both will run the appropriate promise handler, and both will continue executing normally. I guess what needs to happen is that when requestFullscreen() is invoked it needs to do synchronous checks and those need to be done again just before the document changes state. And the only check that involves out-of-process iframe (nested browsing contexts) will block I guess, but that only needs to be made at the initial invocation I think. You could, of course, come up with a synchronous checking scheme similar to the storage mutex but barring somebody discovering a significant web compat issue I suspect that, as with the storage mutex, it would be completely ignored by all vendors. - James -- http://annevankesteren.nl/
Re: [whatwg] apple-touch-icon
I'd really like to avoid sticking this in specs. We already have 3 ways of adding icons, /favicon.ico, link rel=icon and link rel=manifest. That's probably about 2 too many. We shouldn't add a 4th one. Generally speaking, eventually I think manifests is what will encourage the best UX and the easiest syntax for authors. Given that both Blink and Gecko is adding support reluctantly and is planning to remove support, adding it to the spec will make this deprecation harder. At the very least, if it's added to the spec, add very clear language about it being deprecated. / Jonas On Sun, Jul 27, 2014 at 5:13 AM, Anne van Kesteren ann...@annevk.nl wrote: For link rel=icon we already define the /favicon.ico fallback. If a page lacks link rel=icon sizes we should probably also look at Apple's proprietary extension here given that it's quite widely adopted. Chrome supports it and there is some work going on in Firefox as well: https://bugzilla.mozilla.org/show_bug.cgi?id=921014 -- http://annevankesteren.nl/
