Re: [whatwg] `brand-color` meta extension
On Tue, Aug 19, 2014 at 6:52 PM, fantasai fantasai.li...@inkedblade.net wrote: On 06/26/2014 12:50 PM, Tobie Langel wrote: On Jun 26, 2014, at 21:20, Marcos Caceres w...@marcosc.com wrote: On June 26, 2014 at 1:58:17 PM, Tab Atkins Jr. (jackalm...@gmail.com) wrote: Here's a first crack at a better spec: Moved your text here: https://github.com/whatwg/meta-brand-color Could we change the name to something a tad more neutral and extendable, e.g.: ua-background-color? Like that, people that use the Web for things other than brand promotion don't feel offended, and we can add ua-color once devs start requesting it while keeping consistent with CSS. It's not the UA's color you're after here, it's the page's own theming color, right? So theme-color or accent-color might make more sense. Yeah, we ended up at theme-color after much back-and-forth: https://github.com/whatwg/meta-theme-color Adam
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 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
Can you explain what experiment you could run to determine whether (2) happens synchronously or asynchronously? Adam On Jul 28, 2014 9:03 AM, Anne van Kesteren ann...@annevk.nl wrote: There's two things the Fullscreen API does: 1. Resize the top-level browsing context's document's viewport. (I.e. resizing the window of the browser.) 2. Change state of that document and its descendant documents. 1 needs to happen asynchronously. 2 needs to happen from a task per-document. Potentially 2 could happen from a task per unit of related browsing contexts, but I'm not sure if that's better. 2 also needs to be synchronized with animation frames, once we figure out how to define that. (How are animation frames synchronized across iframe boundaries?) I don't really see a way to avoid having a global flag across process boundaries. E.g. if B is nested through A (assume allowfullscreen is set), A and B are cross-origin, and both invoke requestFullscreen(), what happens? (YouTube embedded in some other app.) Anyone with a good idea how we could make this work? There's some background on some of this available here: * https://www.w3.org/Bugs/Public/show_bug.cgi?id=26366 (It's possible to go fullscreen with an element not in the document) * https://www.w3.org/Bugs/Public/show_bug.cgi?id=26440 (Allow fullscreenchange events to be synchronized with animation frames) -- http://annevankesteren.nl/
Re: [whatwg] Fullscreen API and out-of-process iframe
On Jul 28, 2014 10:58 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jul 28, 2014 at 7:42 PM, Adam Barth w...@adambarth.com wrote: Can you explain what experiment you could run to determine whether (2) happens synchronously or asynchronously? I'm not sure I understand the question. Do you mean if you can observe that the tasks in different documents might run at the same time? I don't think you could observe that. The problem I have is addressing the racing issues with this API. 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. Adam
Re: [whatwg] Proposal: navigator.launchURL
On Mon, Jul 14, 2014 at 12:35 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jul 14, 2014 at 4:26 AM, Adam Barth w...@adambarth.com wrote: The launchURL() method requests that the User Agent launch the protocol handler for the specified URL. If the User Agent itself is the registered protocol handler for |url|, then the User Agent should open the requested URL in a new browsing context in a new unit of related browsing contexts. Is this observably different from a target=_blank rel=noreferrer somehow? Yes, that causes a blank window to be created before launching the external protocol handler. On Mon, Jul 14, 2014 at 4:39 AM, Boris Zbarsky bzbar...@mit.edu wrote: Which raises a separate question, by the way: should a sandboxed iframe (without allow-popups, in case that matters) be able to do this? Nope, I think we should block that. On Mon, Jul 14, 2014 at 6:47 AM, Konstantin Welke konstantin.we...@citrix.com wrote: Yes, the success/failure callback are very important to have a good user experience. Most important is whether the information that handler is not available (so that you can e.g. provide a download to install the application instead). Having a success callback is very nice to provide a good UX. Makes sense. In the end, it’s a privacy tradeoff: Do you want to mix “handler not available” and “user declined the launch” into one callback, so that the web page does not know whether X is installed or the user just didn’t want to launch it? (However, that information might be accessible from the timings…) What the msLaunchUri call does: * successCallback if the app was launched * noHandlerCallback if no URI handler was installed * if you get no callback that means either the user declined the launch or has not click anything yet (if there was a confirmation dialog). If the user declines, we should probably reject the promise. I’m not decided on promises vs. callbacks. I guess promises are the more modern approach. Either would work fine here and it’s easy to wrap one into the other if needed. Promises are the future. New APIs should use them instead of having a pair of success and failure callbacks. I think it should be allowed in sandboxed iframes (but maybe I’m biased as I want to use this API). At the very least, there should be a sandbox attribute that allows using this API. IMHO, the allow-popups should enable the feature, just like it enables window.open. On Mon, Jul 14, 2014 at 7:44 AM, Anne van Kesteren ann...@annevk.nl wrote: This does not seem particularly compelling. I'd rather figure out why there needs to be a native application in the first place. It's about user choice. Users might choose to use a web-based SSH client or they might choose to use a native application as their SSH client. The web site that's launching the SSH session doesn't need to care. They can all share the same URI scheme: ssh. Adam
Re: [whatwg] Proposal: navigator.launchURL
On Mon, Jul 14, 2014 at 10:42 AM, Ian Hickson i...@hixie.ch wrote:
On Sun, 13 Jul 2014, Adam Barth wrote:
== Use Case ==
A web site wants to launch an external protocol handler. For example,
a web site might want to launch PuTTY via the ssh scheme.
window.open('ssh://...');
I'll look at this in more detail in due course, but FWIW this appears to
be more or less identical to a proposal from Microsoft about 18 months
ago:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20799
It's still not really clear what difference this API would have to
window.open(), though.
The difference is that window.open opens a new browser window even if
the URL is handled by an external protocol handler. Even if we
changing current browsers to detect whether the URL will be handled by
an external protocol handler before opening the window, web sites
won't be able to feature-detect which browsers have this new behavior
and therefore won't be able to move away from iframe@src hacks until
all the browsers they care about have the behavior change. By
contrast, sites can feature detect navigator.launchURL and fall back
to iframe@src in UAs that lack the new API.
Adam
Re: [whatwg] Proposal: navigator.launchURL
On Mon, Jul 14, 2014 at 2:10 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 14 Jul 2014, Adam Barth wrote: The difference is that window.open opens a new browser window even if the URL is handled by an external protocol handler. Even if we changing current browsers to detect whether the URL will be handled by an external protocol handler before opening the window, web sites won't be able to feature-detect which browsers have this new behavior and therefore won't be able to move away from iframe@src hacks until all the browsers they care about have the behavior change. By contrast, sites can feature detect navigator.launchURL and fall back to iframe@src in UAs that lack the new API. I'm skeptical of features that only have a benefit during a short transition phase. Suppose it's five years from now and now everyone implements window.open() in this cleaner way and everyone also has launchURL(). Why is it good that we have both? You're presupposing a particular series of future events. It's more likely that it will take longer than five years. As an example, we shipped unprefixed support for border-radius in May 2010, and browser support is still only ~85% of traffic: http://caniuse.com/#search=border-radius If web developers need to wait for the long tail of browsers to catch up before they can use a feature, they're unlikely to adopt it. If developers don't adopt a feature, browser vendors are less likely to adopt the feature. That's why the bootstrapping process is an important consideration. Adam
Re: [whatwg] Proposal: navigator.launchURL
On Mon, Jul 14, 2014 at 3:28 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 14 Jul 2014, Adam Barth wrote: I'm skeptical of features that only have a benefit during a short transition phase. Suppose it's five years from now and now everyone implements window.open() in this cleaner way and everyone also has launchURL(). Why is it good that we have both? You're presupposing a particular series of future events. It's more likely that it will take longer than five years. As an example, we shipped unprefixed support for border-radius in May 2010, and browser support is still only ~85% of traffic: http://caniuse.com/#search=border-radius It doesn't really matter how long it takes. The time until authors can stop using the iframe hack is the same whether we provide a new API or have a legacy API that needs updating to be slightly less annoying. If web developers need to wait for the long tail of browsers to catch up before they can use a feature, they're unlikely to adopt it. They can use window.open() today. It's just that it causes a bit of flicker for now. IMHO the flicker is just a bug we should fix. Introducing a new API that literally doesn't do anything you can't already do is a pretty high cost, IMHO. Ok, we can try the window.open approach first. Adam
[whatwg] Proposal: navigator.launchURL
== Use Case ==
A web site wants to launch an external protocol handler. For example,
a web site might want to launch PuTTY via the ssh scheme.
== Workarounds ==
Currently developers launch external protocol handlers by creating
iframes with src attributes that point to the external protocol URLs.
Web developers aren't able to set window.location to the external
protocol URL because that cancels all in-progress network requests
(e.g., outstanding XMLHttpRequests). Unfortunately, we need to
maintain this behavior for compatibility.
== Why Now? ==
We've run into this issue because we've been tightening down Chrome's
mixed content policy. When we started blocking secure pages from
embedding insecure iframes, we broke web sites that were using iframes
to launch external protocol (see http://crbug.com/318788).
We could change out mixed content policy to blacklist only known
insecure URI schemes, but that isn't as secure as whitelisting known
secure URI schemes. Instead, it seems better to give web developers a
way to tell the browser what they want to do, which is to launch an
external protocol handler.
That, of course, raises the interesting question of how to handle the
case where the external protocol handler is registered by a web page
(e.g., WebPuTTY registering ssh via
navigator.registerProtocolHandler). The simplest thing is probably to
open the registered URL in a new tab because that's the most similar
to launching an external program to handle the URL.
== Proposal ==
partial interface NavigatorContentUtils {
void launchURL(DOMString url);
};
The launchURL() method requests that the User Agent launch the
protocol handler for the specified URL. If the User Agent itself is
the registered protocol handler for |url|, then the User Agent should
open the requested URL in a new browsing context in a new unit of
related browsing contexts.
Adam
Re: [whatwg] Proposal: navigator.launchURL
On Sun, Jul 13, 2014 at 8:05 PM, Michael[tm] Smith m...@w3.org wrote:
Adam Barth w...@adambarth.com, 2014-07-13 19:26 -0700:
== Use Case ==
A web site wants to launch an external protocol handler. For example,
a web site might want to launch PuTTY via the ssh scheme.
[...]
== Proposal ==
partial interface NavigatorContentUtils {
void launchURL(DOMString url);
};
Did you see the similar proposal that came up for discussion back in March?
http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/thread.html#msg791
http://bengjohnson.github.io/ExternalProtocolSpecification.html
It also used the example of launching an SSH client:
http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0797.html
It proposed a method that includes a successCallback noHandlerCallback:
navigator.launchUri(uri, successCallback, noHandlerCallback)
No, I missed that. Looks very similar. A more modern idiom would be
to return a promise to inform the caller of success or failure.
Is there a use case for reporting success or failure? I thought about
including that, but it wasn't necessary for the use cases I'm aware
of. We can always extend the API with a returned promise in the
future if more use cases arise.
Adam
Re: [whatwg] brand-color meta extension
On Thu, Jun 26, 2014 at 11:13 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 26 Jun 2014, Tao Bai wrote: The brand color is super set of them and not limited to use in the navbutton or status bar, furthermore, not all browsers have navbutton or status concept, it makes developer confused. I don't think it confuses authors any more, and possibly a lot less, than having three ways to do essentially the same thing. The msapplication-navbutton-color and apple-mobile-web-app-status-bar-style are prefix and browser specific, brand-color is general and could be standard for all browsers. That the keywords are prefixed is a mistake made by the relevant vendors, but I don't think it should stop us from using them if they are appropriate. Looking at those two keywords more closely, it seems that apple-mobile-web-app-status-bar-style wouldn't work because it doesn't take a CSS colour, it takes some specific keywords. However, msapplication-navbutton-color, and, maybe better, msapplication-TileColor, seem like pretty good fits to me. I don't really understand why one would avoid just reusing those, either instead of, or at least as well as, a newer more generic term. If I were trying evangelize the use of this feature, I wouldn't want to recommend that web developers use a vendor-prefixed feature. I wish either Apple or Microsoft hadn't used a vendor-prefixed name, but they both did. Adam
Re: [whatwg] Fetch API: asHTML
On Mon, Jun 23, 2014 at 3:15 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sun, Jun 22, 2014 at 6:10 AM, Adam Barth w...@adambarth.com wrote: I haven't been following the fetch API in detail. Is there some collective understanding of what abstraction layer fetch represents? It's at the same level as XMLHttpRequest. XMLHttpRequest isn't particularly cleanly layered. It's sounds like you're not overly concerned about layering, which is probably fine. Adam For example, I could imagine that we might not want to add a dependency from the fetch to the HTML parser because fetch is a lower layer of the system. The API in question would be on the FetchBodyStream returned from the network. Adding asHTML there wouldn't pose any requirements on the underlying Fetch system. However, I think we should wait with adding more as* APIs until we have some experience with the current set of features. -- http://annevankesteren.nl/
Re: [whatwg] Fetch API: asHTML
On Mon, Jun 23, 2014 at 8:28 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jun 23, 2014 at 5:11 PM, Adam Barth w...@adambarth.com wrote: XMLHttpRequest isn't particularly cleanly layered. It's sounds like you're not overly concerned about layering, which is probably fine. I think I see what you mean. If you wanted to implement this in terms of JavaScript then indeed you would end up importing several modules other than the fetch module to implement these methods. E.g. encoding, for asText, filesystem and MIME for asBlob, and encoding and JSON for asJSON. For asHTML you'd need encoding and HTML. Yes, exactly. However, the sadness comes when the HTML module ends up depending on the fetch module because that creates a circular dependency. You then need to merge them into one module, which will quickly become the everything module. This seems fine to me. This discussion is about theoretical purity, which is pretty far down the list things we should care about. However, I could see it instead has to go the other way around. Instead of having a bunch of methods on stream to convert it into various other pieces. Other pieces could have ways of dealing with streams. That might make coding a bit more awkward though. It might be instructive to think about how the Node community would structure these APIs. Node has a much stronger notion of modules and dependencies than browsers because Node uses npm. As Node developer, I would be sad if my networking module dragged in an entire HTML implementation. Adam
Re: [whatwg] Fetch API: asHTML
I haven't been following the fetch API in detail. Is there some collective understanding of what abstraction layer fetch represents? For example, I could imagine that we might not want to add a dependency from the fetch to the HTML parser because fetch is a lower layer of the system. Adam On Fri, Jun 20, 2014 at 2:39 PM, Joshua Peek j...@joshpeek.com wrote: Hey Anne, love the direction of the Fetch API. I'm curious what you think of an asHTML extension to the FetchBodyStream? Parsing fragment HTML from XHRs is pretty typical. It could potential return a DocumentFragment or if it used some streaming HTML parser, it could emit the top level nodes as they were being parsed. Any reasons why its a terrible idea? Or just something thats a little to complex to tackle in the early states of Fetch? Thanks!
Re: [whatwg] Bogus comment state and CDATA section state do not stylistically fit in the tokenizer
In Blink's implementation, we actually use two additional tokenizer states for CDATA: CDATASectionRightSquareBracketState, CDATASectionDoubleRightSquareBracketState, Adam On Sun, Jun 8, 2014 at 6:24 PM, Geoffrey Sneddon foolist...@googlemail.com wrote: It would aid programmatic conversion of the spec, and confuse me when reading the spec less thereby avoiding bugs like 25871, if these states matched the model of the rest of the tokenizer. Thus I propose the bogus comment state becomes: Consume the next input character: U+003E GREATER-THAN SIGN (): Switch to the data state. Emit the comment token. U+ NULL: Append a U+FFFD REPLACEMENT CHARACTER character to the comment token's data. EOF: Switch to the data state. Emit the comment token. Reconsume the EOF character. Anything else: Append the current input character to the comment token's data. This also necessitates creating a new comment token prior to entering the bogus comment state. The CDATA section state should become: Consume the next input character: U+005D RIGHT SQUARE BRACKET (]): If the three characters starting from the current input character are U+005D RIGHT SQUARE BRACKET U+005D RIGHT SQUARE BRACKET U+003E GREATER-THAN SIGN (]]), then consume those characters and switch to the data state. Otherwise, emit the current input character as a character token. EOF: Switch to the data state. Reconsume the EOF character. Anything else: Append the current input character to the comment token's data. No changes are needed elsewhere for this. (There is no consistent style for lookahead — and most cases are ASCII case-insensitive words — so I went with what seems sane here!) /Geoffrey
[whatwg] BroadcastChannel memory leak
When is it safe for a user agent to garbage collect a BroadcastChannel instance? http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#broadcasting-to-other-browsing-contexts Given that another document might create a new BroadcastChannel instance at any time, the |message| event of the object might fire any time its responsible document is fully active. For web application that have long-lived documents, the BroadcastChannel might not be eligible for garbage collection for a long time. Proposal: Add a |close| method to the BroadcastChannel interface similar to the |close| method on MessagePort. The |close| method would just neuter the instance of the channel and prevent it from receiving further messages. Adam
Re: [whatwg] BroadcastChannel memory leak
On Fri, May 23, 2014 at 5:54 PM, Michael Nordman micha...@google.com wrote: When is it safe for a user agent to garbage collect a BroadcastChannel instance? When there's no direct reference to the object and no onmessage handler attached to it. (?) That doesn't play nicely with anonymous JavaScript functions that can't ever be removed as event listeners... Adam On Fri, May 23, 2014 at 5:23 PM, Adam Barth w...@adambarth.com wrote: When is it safe for a user agent to garbage collect a BroadcastChannel instance? http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#broadcasting-to-other-browsing-contexts Given that another document might create a new BroadcastChannel instance at any time, the |message| event of the object might fire any time its responsible document is fully active. For web application that have long-lived documents, the BroadcastChannel might not be eligible for garbage collection for a long time. Proposal: Add a |close| method to the BroadcastChannel interface similar to the |close| method on MessagePort. The |close| method would just neuter the instance of the channel and prevent it from receiving further messages. Adam
Re: [whatwg] AppCache Content-Type Security Considerations
On Mon, May 12, 2014 at 4:17 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 12 May 2014, Eduardo' Vela\ Nava wrote: Now, with appcache manifest files, we are introducing a security-sensitive change based on a file with special powers (more on this later), and while before they were guarded by a Content-Type check, this isn't the case anymore. Note that there _is_ still a content type check with appcache, it's just done on the first few bytes of the file instead of on the metadata. (This is IMHO how all file typing should work.) There's a big difference between the first few bytes of a file and the Content-Type HTTP header. In many scenarios, the former is under the control of an attacker when the latter is not. Adam
Re: [whatwg] Proposal: navigator.cores
I've updated the spec proposal [1] to sanction reporting fewer than the actual number of logical cores as a fingerprinting mitigation. I've also renamed the API from navigator.cores to navigator.hardwareConcurrency to match the proposed WebKit patch. Adam [1] http://wiki.whatwg.org/wiki/NavigatorCores On Thu, May 8, 2014 at 7:02 PM, Rik Cabanier caban...@gmail.com wrote: FYI From the WebKit side, people are leaning towards returning the logical CPU count but limit the maximum value to 8 [1]. This should cover the vast majority of systems and use cases for this property and still not expose users that are on high value devices.. 1: https://bugs.webkit.org/show_bug.cgi?id=132588 On Tue, May 6, 2014 at 2:30 PM, Rik Cabanier caban...@gmail.com wrote: On Tue, May 6, 2014 at 8:51 AM, Joe Gregorio jcgrego...@google.com wrote: On Tue, May 6, 2014 at 7:57 AM, João Eiras jo...@opera.com wrote: ... I guess everyone that is reading this thread understands the use cases well and agrees with them. The disagreement is what kind of API you need. Many people, rightly so, have stated that a core count gives little information that can be useful. It's better to have an API that determines the optimal number of parallel tasks that can run, because who knows what else runs in a different process (the webpage the worker is in, the browser UI, plugins, other webpages, iframes, etc) with what load. Renaming 'cores' to 'parallelTaskCount' would be a start. +1 The solution proposed should actually be a solution to the problem as stated, which, from the abstract read: The intended use for the API is to help developers make informed decisions regarding the size of their worker threadpools to perform parallel algorithms. So the solution should be some information about the maximum number of parallel workers that a page can expect to run, which may have no relation to the number of cores, physical or virtual. The browser should be allowed to determine what that number is based on all the factors it has visibility to, such as load, cores, and policy. Returning the number is actually important, for example, physics engines for WebGL games, how you shard the work may depend on knowing how many parallel workers you should schedule. It seems everyone is in agreement that this API should return the number of useful parallel tasks. So far, people have proposed several names: - cores - this seems confusing since the returned number might be lower - concurrency - there can be more concurrent tasks than there are logical cores - hardwareConcurrency - parallelTaskCount Leaving the question of fingerprinting aside for now, what name would people prefer?
Re: [whatwg] Proposal: Event.creationTime
Can we just change timeStamp to be a DOMHighResTimeStamp rather than
introducing a redundant property?
Adam
On Tue, May 6, 2014 at 10:51 PM, Brian Birtles bbirt...@mozilla.com wrote:
Hi,
Gecko's implementation of Event.timeStamp does not conform to the spec[1]
since it reports the number of milliseconds since system start rather than
00:00:00 UTC on 1 January 1970. This is tracked as Mozilla bug 77992 [2].
DOM Level 2 allowed this[3] but the spec has since changed.
One reason for not updating to match the spec has been concern about using
a non-monotonic clock as a time source. This can lead to bugs when the
system clock is adjusted.
Now that we have a DOMHighResTimeStamp that provides a monotonically
increasing time, I propose we add it to the Event interface.[4]
This time is measured from navigationStart which removes some of the
security concerns raised regarding using system start.[5] navigationStart
is also the point of reference being using for Performance.now(),
requestAnimationFrame and Web Animations.
As for use cases for event timestamps, apparently Youtube uses the
timeStamp on progress events to estimate download bandwidth. Another use
case is that of SMIL which seems to want to overload the timestamp from
being strictly creation time to when the event *should* have been created
in order to avoid synchronization slew.[6]
Proposal:
partial interface Event {
readonly attribute DOMHighResTimeStamp creationTime;
};
(Alternative naming suggestions are obviously most welcome.)
Semantics are as with 'timeStamp' but based on navigationStart.
Given that 'timeStamp' is currently implemented inconsistently, it might
be possible to eventually deprecate it.
Best regards,
Brian
[1] http://dom.spec.whatwg.org/#dom-event-timestamp
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=77992
[3] http://www.w3.org/TR/DOM-Level-2-Events/events.html#
Events-Event-timeStamp
[4] http://www.w3.org/TR/hr-time/
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=579652#c2
[6] http://www.w3.org/TR/SMIL/smil-timing.html#q135
Re: [whatwg] Proposal: Event.creationTime
On Wed, May 7, 2014 at 3:43 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, May 7, 2014 at 7:00 AM, Adam Barth w...@adambarth.com wrote: Can we just change timeStamp to be a DOMHighResTimeStamp rather than introducing a redundant property? http://lists.w3.org/Archives/Public/www-dom/2012OctDec/thread.html#msg8 is the previous thread on this topic. In that thread bz pointed out that changing Date.now() to return sub-milliseconds as an experiment failed. If people want to do the experiment for Event.prototype.timeStamp I'd be happy with that. It seems worth experimenting with. If the experiment fails, we can try another approach. Adam Is there a good reference somewhere for what the time would be relative to? (I previously had a problem with doing this in DOM as it would depend on page load time which is defined by HTML, but I have since accepted that HTML and DOM are intertwined.) -- http://annevankesteren.nl/
Re: [whatwg] Proposal: navigator.cores
On Sun, May 4, 2014 at 8:35 PM, Ian Hickson i...@hixie.ch wrote: On Sun, 4 May 2014, Adam Barth wrote: The world of computing has changed since 2009. At that time, the iPhone 3G had just been released and Apple hadn't even released the first iPad. The needs of the web as a platform have changed because now the web faces stiff competition from other mobile application frameworks. I'm not arguing that we shouldn't provide solid APIs that allow authors to provide multi-core solutions. I'm arguing that when we do so, we should do so while protecting the privacy of users. I feel a bit like I'm repeating myself, but I'll try to present my two arguments again concisely: 1) There is no privacy issue today. The only privacy concern people have raise is in regards to fingerprinting. Today, fingerprinting is already possible with a high degree of accuracy regardless of navigator.cores. The fingerprinting concern with navigator.cores only degrades privacy in a hypothetical future world in which we're removed all the existing fingerprinting vectors in the platform. I don't believe we'll ever live in that world, and I'm no longer willing to withhold useful tools from developer to keep that dream alive. 2) In 2009, as well as today, you've argued that we should hold out for a better solution. I agree that we should provide developers with a better solution (e.g., something analogous to Grand Central Dispatch). However, I also believe we should provide developers with a worse solution [1], and I'm sad that we didn't do that in 2009. If we had provided developers with a worse solution in 2009, they would be better off today. Similarly, developers will be better off if we provide navigator.cores today even if we manage to ship a better solution sometime before 2019. Adam [1] http://www.jwz.org/doc/worse-is-better.html
Re: [whatwg] Proposal: navigator.cores
On Sun, May 4, 2014 at 12:13 AM, Tobie Langel tobie.lan...@gmail.comwrote: On May 4, 2014, at 7:45, Rik Cabanier caban...@gmail.com wrote: On Sat, May 3, 2014 at 10:32 PM, Eli Grey m...@eligrey.com wrote: The proposal specifically states using logical cores, which handles all of the CPUs you mentioned properly. Intel CPUs with hyperthreading enabled report logical cores as double the hardware cores. Depending on the version and configuration of the Samsung Exynos Octa big.LITTLE CPUs, you will get either 4 logical cores (only one cluster can run at a time) or 8 logical cores (big.LITTLE MP, available in Exynos 5420 or later only). Great! Make sure this is captured when it is put in a specification. Otherwise the subtlety between an actual and a logical core might get lost. Shouldn't this also be captured in the API's name? Maybe navigator.hardwareConcurrency as a nod to the C++11 name? Adam
Re: [whatwg] Proposal: navigator.cores
On Sun, May 4, 2014 at 1:11 PM, Ian Hickson i...@hixie.ch wrote: On Sat, 3 May 2014, Adam Barth wrote: Over on blink-dev, we've been discussing [1] adding a property to navigator that reports the number of cores [2]. [1] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/B6pQClqfCp4 [2] http://wiki.whatwg.org/wiki/NavigatorCores 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]. [3] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024251.html [4] http://en.wikipedia.org/wiki/Grand_Central_Dispatch It's not clear what has changed since that discussion. The world of computing has changed since 2009. At that time, the iPhone 3G had just been released and Apple hadn't even released the first iPad. Why are the concerns raised at that time no longer valid? The needs of the web as a platform have changed because now the web faces stiff competition from other mobile application frameworks. As far as I can tell, this functionality exists in every other platform (including iOS and Android). This is true, but all those platforms have security mechanisms in place to mitigate the risk: you have to manually install the application, thus granting it either essentially full access to your machine (Win32), or you have to have it vetted by a third party (iOS), or you have to examine permissions that the application is requesting, and explicitly grant it the right to run on your machine. The Web's security model is radically different. On the Web, we assume that it is safe to run any random hostile code, and that that code cannot harm you or violate your privacy. There are flaws in the privacy protection (i.e. fingerprinting vectors) that browsers are slowly patching, but we have worked hard to avoid adding new fingerprinting vectors. We should continue to do so. My personal view is that the fingerprinting horse left the barn years ago. I don't believe vendors will succeed in patching the existing fingerprint vectors. For example, the WebKit project cataloged a number of vectors three year ago and has made very little progress patching any of them: http://trac.webkit.org/wiki/Fingerprinting Moreover, vendors are adding new state vectors all the time. For example, the HTTP2 protocol contains an explicit protocol element for persisting data on the client: http://tools.ietf.org/html/draft-ietf-httpbis-http2-12#section-6.5 The web cannot afford to avoid exposing useful, non-privacy sensitive information, such as the number of cores, to developers out of a fear of fingerprinting. Avoiding exposing this information will not improve privacy because fingerprinting is already possible. Instead, not providing developers the tools they need to build compelling web content on mobile will simply result in developers leaving the web platform for other mobile application frameworks. 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. [5] https://groups.google.com/a/chromium.org/d/msg/blink-dev/B6pQClqfCp4/bfPhYPPQqwYJ [6] http://wg.oftn.org/projects/core-estimator/demo/ The core estimator is wildly inaccurate. For example, it is highly sensitive to machine load. I don't think it's fair to say well, you can get this data with poor fidelity over a few seconds, therefore providing a precise number with zero milliseconds latency is no worse. You're right that Panopticlick doesn't bother to spend the few seconds it takes to estimate the number of cores because it already has sufficient information to fingerprint 99.1% of visitors: https://panopticlick.eff.org/browser-uniqueness.pdf 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. They don't have to, though. I didn't say they needed to. I said they did. In fact, the web was the only platform I could find that didn't make the number of cores available to developers. The Web is unique in attempting to protect users' privacy in the face of hostile code without requiring installation or a trust-granting step. I don't believe the number of cores is privacy-sensitive information. Revealing this information to web sites does not require a trust-granting step. Adam
[whatwg] Proposal: navigator.cores
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. Adam [1] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/B6pQClqfCp4 [2] http://wiki.whatwg.org/wiki/NavigatorCores [3] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024251.html [4] http://en.wikipedia.org/wiki/Grand_Central_Dispatch [5] https://groups.google.com/a/chromium.org/d/msg/blink-dev/B6pQClqfCp4/bfPhYPPQqwYJ [6] http://wg.oftn.org/projects/core-estimator/demo/
Re: [whatwg] Simplified picture element draft
On Wed, Jan 8, 2014 at 10:05 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Jan 8, 2014 at 9:47 AM, Yoav Weiss y...@yoav.ws wrote: On Wed, Jan 8, 2014 at 6:18 PM, Maciej Stachowiak m...@apple.com wrote: - It seems this draft allows arbitrary media queries, with only a subset expected to give best performance (by correctly informing the preload scanner). In my opinion, this is worse than the alternative of only supporting the media queries that could plausibly be integrated with preload scanning. Creating a programming interface with a performance cliff - a point beyond which performance suddenly gets significantly worse for what seems like a small incremental change - is generally a bad idea. And the use cases for fully general media queries seem much more speculative than the ones for the simplified subset. I'm not opposed to having a white-list of performance-safe authorized media queries, and extending that list in the future if necessary, but we need to make sure that it's extensible without causing the content to break in browsers where the new MQs are not supported. As far as I can tell, the current syntax can support this. Right. We can't just ignore the MQ, as that's unfriendly. We could maybe ignore the source, but that feels like too much. Having it evaluated on the main thread is slower, but it's guaranteed to *work* in older browsers, which is nice. And, as previously stated, *every* MQ beyond resolution is preloader-unfriendly in at least some cases. I'd like to avoid making this complicated for authors as much as possible. Having to worry about if legacy browsers will display an image more slowly is much less troublesome than wondering if legacy browsers will display it at all; in most cases, you don't have to worry about it at all, because preloading is a nice benefit but not a necessity. Note, too, that though the full set of MQs is only for niche cases, I can certainly come up with reasonable cases nonetheless, particularly as we introduce new device-capability MQs. For example, you could switch from a GIF to a still picture based on the updates MQ that we're considering adding, or use a higher-contrast version based on whatever MQ we end up developing for detecting high-contrast needs. Disallowing these entirely just means that either devs will use JS to switch their images (then why did we spend all this effort on a markup-based solution?) or they just won't cater to those needs at all. The way we'd likely implement this feature in Blink is in couple stages. In the first stage, we'd implement the portions of the specification that don't involve media queries because we'll be able to provide developers a high-quality implementation of that part of the spec, including preload scanning. In the second stage, we'd implement the parts of the specification that relate to media queries. We'll likely wait to implement the second stage until we're able to provide a high-quality implementation, which means waiting until we're able to parse and process media queries in the preload scanner without joining the main thread. Adam
Re: [whatwg] Simplified picture element draft
Thanks Yoav. Tab asked me to provide some more feedback to this list, but it's hard to tell from the lengthy discussion what proposal folks are most interested in. Is there an editor's draft or some other relatively self-contained write-up that I could review? Thanks, Adam On Mon, Nov 25, 2013 at 12:00 AM, Yoav Weiss y...@yoav.ws wrote: This is a part of the proposal that got people excited. The linked document defines picture's source selection algorithm. It contains some parts that I'm not sure have a consensus around them yet: * It defines picture as controlling img, where earlier on this list we discussed mostly the opposite (img querying its parent picture, if one exists) * It defines img as a part of picture's shadow DOM, which we need to see how it fits with having fallback img elements (which are necessary in the near future). This proposal does contain srcset as a subcomponent, but it's not the same srcset as defined in the HTML spec, but a modified version based on improvements from the src-N spec. (that cover the variable-width images use-case) The proposal will also require some changes to img and specifically, when not created by JS, img will have to avoid loading of resources until the element is added to the DOM, and can see if its direct parent is picture. If the parent is picture, img would then query the parent (or wait to be controlled by its parent), otherwise, it'll load its resources as usual. On Mon, Nov 25, 2013 at 8:33 AM, Adam Barth w...@adambarth.com wrote: I'm trying to sort out from the many messages on this topic which proposal I should read in detail. Is the one linked below the one that people are most excited about? I'm I correct in understand that this proposal contains srcset as a subcomponent? Thanks, Adam On Sat, Nov 23, 2013 at 3:04 PM, Kornel Lesiński kor...@geekhood.net wrote: I've written down proposal for the simplified source selection algorithm: http://geekhood.net/picture-element.html This also includes variant of the idea from the recent picture redux proposal to use an actual img element as the basis for the picture element definition. This draft doesn't include all features of src-N *yet*, but I expect this to be added either via extended srcset syntax to something like source sizes once there's consensus how to approach this. To simplify implementation even further I've allowed UAs to flatten fallback DOM to a plaintext string (in case they need to emulate img alt for existing screen readers or accessibility APIs). I've dropped usemap. It could be added, but I'm not sure if there is need for it. I've specified very few IDL attributes. This area may need to be extended. -- regards, Kornel
Re: [whatwg] Simplified picture element draft
I'm trying to sort out from the many messages on this topic which proposal I should read in detail. Is the one linked below the one that people are most excited about? I'm I correct in understand that this proposal contains srcset as a subcomponent? Thanks, Adam On Sat, Nov 23, 2013 at 3:04 PM, Kornel Lesiński kor...@geekhood.net wrote: I've written down proposal for the simplified source selection algorithm: http://geekhood.net/picture-element.html This also includes variant of the idea from the recent picture redux proposal to use an actual img element as the basis for the picture element definition. This draft doesn't include all features of src-N *yet*, but I expect this to be added either via extended srcset syntax to something like source sizes once there's consensus how to approach this. To simplify implementation even further I've allowed UAs to flatten fallback DOM to a plaintext string (in case they need to emulate img alt for existing screen readers or accessibility APIs). I've dropped usemap. It could be added, but I'm not sure if there is need for it. I've specified very few IDL attributes. This area may need to be extended. -- regards, Kornel
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Fri, Nov 15, 2013 at 1:55 AM, Yoav Weiss y...@yoav.ws wrote:
On Tue, Nov 12, 2013 at 7:31 PM, Maciej Stachowiak m...@apple.com wrote:
Content authors can already do what is described above, and in fact often
do. However, a div with a background-image property set is not the same as
an img in practice. Here are a few differences:
(1) There's no ready way to have an element size automatically to its
background-image (the way an img will to its src by default).
(2) In general, browsers will not provide the same user interaction
operations for a background image as for a content image in an img element
(e.g. ability to drag it elsewhere, context menu items to save it, etc).
(3) Assistive technologies will ignore background image holding divs for
which no textual equivalent has been provided (as opposed to img, where
they do something like reading the filename, or just indicate the presence
of an image without labeling it).
(4) Software that processes content to look for images may treat content
images in img differently from images specified as backgrounds, for
instance by assuming background images are decorative and therefore less
meaningful and/or less related to search terms in text on the page.
Some of the above may be addressable by using the 'content' property
instead of the 'background-image' property, though using 'content' on an
element as opposed to a :before or :after pseudo does not work reliably
cross-browser.
I agree with Maceij's concerns here.
I also think that writing inline CSS will be cumbersome in a CSP world.
Hashes will make it easier for static inline CSS, but if we're going to
write down frequently-changing, content images' resources in inline CSS,
that'd be a lot of hash calculations. A build step can help, but it's a
downside of this approach.
Can any proponent of the inline-style based methods address the concerns
Maciej and myself have raised?
My apologies. I thought Christian Biesinger addressed all these
concerns with his proposal:
On Tue, Nov 12, 2013 at 5:56 PM, Christian Biesinger
cbiesin...@google.com wrote:
For a bit more presentation, and while we're inventing new syntax
anyway, how about this:
style
@media (min-width: 480px) {
.artdirected { content: replaced url(attr(src-small)); }
}
@media (min-width: 600px) {
.artdirected { content: replaced url(attr(src-medium)); }
}
@media (min-width: 800px) {
.artdirected { content: replaced url(attr(src-big)); }
}
/style
...
img class=artdirected src=foo.jpg src-small=foo-small.jpg
src-medium=foo-medium.jpg src-big=foo-big.jpg
Specifically, his approach uses an img element, which addresses all
four of Maciej's concerns.
Adam
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Fri, Nov 15, 2013 at 9:00 AM, Yoav Weiss y...@yoav.ws wrote:
On Fri, Nov 15, 2013 at 4:20 PM, Adam Barth w...@adambarth.com wrote:
My apologies. I thought Christian Biesinger addressed all these
concerns with his proposal:
On Tue, Nov 12, 2013 at 5:56 PM, Christian Biesinger
cbiesin...@google.com wrote:
For a bit more presentation, and while we're inventing new syntax
anyway, how about this:
style
@media (min-width: 480px) {
.artdirected { content: replaced url(attr(src-small)); }
}
@media (min-width: 600px) {
.artdirected { content: replaced url(attr(src-medium)); }
}
@media (min-width: 800px) {
.artdirected { content: replaced url(attr(src-big)); }
}
/style
...
img class=artdirected src=foo.jpg src-small=foo-small.jpg
src-medium=foo-medium.jpg src-big=foo-big.jpg
Specifically, his approach uses an img element, which addresses all
four of Maciej's concerns.
You're right, Maciej's concerns were addressed by Christian's proposal (and
John's followup proposal).
Any thoughts on my concerns with making inline CSS mandatory (especially
from the CSP angle)?
CSP 1.1 supports securing inline style and script with nonces and/or hashes.
Adam
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Fri, Nov 15, 2013 at 10:25 AM, matmarquis.com m...@matmarquis.com wrote: On Nov 15, at 12:27 PM, Yoav Weiss wrote: Any thoughts on my concerns with making inline CSS mandatory (especially from the CSP angle)? CSP 1.1 supports securing inline style and script with nonces and/or hashes. OK, since the latest proposals keep the URLs outside the style, modifying the content image can keep the same style, assuming layout is identical. So these inline-style are not more likely to change than any other inline-styles and the authoring complexity is identical to other inline styles. Still - I'm not sure such a solution is author friendly. I’m just not sure what this proposal claims to handle or support that `src-n` doesn’t, apart from handling it with a slightly different syntax that’s subjectively preferred by a few people? Seems like it depends on a number of fairly large assumptions, but doesn’t really bring anything new to the table. The primary benefit of this proposal over src-N is that implementors are willing to implement it (or at least haven't refused to implement it yet). Adam
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Fri, Nov 15, 2013 at 10:32 AM, Tim Kadlec t...@timkadlec.com wrote: To my knowledge the only implementor who flat-out refused to implement src-N was WebKit. There is interest from Mozilla and Blink, though it did sound like Blink was considering playing follow the leader. That's right. Blink isn't likely to implement a responsive image proposal that WebKit refuses to implement. Adam On Fri, Nov 15, 2013 at 12:25 PM, Adam Barth w...@adambarth.com wrote: On Fri, Nov 15, 2013 at 10:25 AM, matmarquis.com m...@matmarquis.com wrote: On Nov 15, at 12:27 PM, Yoav Weiss wrote: Any thoughts on my concerns with making inline CSS mandatory (especially from the CSP angle)? CSP 1.1 supports securing inline style and script with nonces and/or hashes. OK, since the latest proposals keep the URLs outside the style, modifying the content image can keep the same style, assuming layout is identical. So these inline-style are not more likely to change than any other inline-styles and the authoring complexity is identical to other inline styles. Still - I'm not sure such a solution is author friendly. I’m just not sure what this proposal claims to handle or support that `src-n` doesn’t, apart from handling it with a slightly different syntax that’s subjectively preferred by a few people? Seems like it depends on a number of fairly large assumptions, but doesn’t really bring anything new to the table. The primary benefit of this proposal over src-N is that implementors are willing to implement it (or at least haven't refused to implement it yet). Adam
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Fri, Nov 15, 2013 at 12:30 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Nov 12, 2013 at 10:40 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Nov 12, 2013 at 9:50 AM, Adam Barth w...@adambarth.com wrote:
We might even be able to make this work without inventing anything:
style type=text/css
@media (min-width: 480px) {
.artdirected {
width: 30px;
height: 30px;
background-image: image-set(url(small.png) 1x, url(small-hires.png) 2x);
}
}
@media (min-width: 600px) {
.artdirected {
width: 60px;
height: 60px;
background-image: image-set(url(large.png) 1x, url(large-hires.png) 2x);
}
}
/style
div class=artdirected/div
All the information is there. We just need to teach the preload
scanner to parse a subset of CSS and match a subset of selectors. If
you stay within the preloadable subset, then your images will be
loaded by the preload scanner. Otherwise, they'll just be loaded
normally.
Okay, here are some examples done up in as reasonable and compact a
manner as I can do, assuming certain syntaxes when they haven't yet
been created:
Use-case 1: Variable density.
src-N
img src-1=foo.5 .5x, foo1 1x, foo2 2x, foo3 3x src=foo1
PreloaderCSS
img src=foo1 id=foo
style
#foo { content: replaced image-set(foo.5 .5x, foo1 1x, foo2 2x,
foo3 3x); }
/style
Use-case 2: Art-direction (slightly different images based on layout
breakpoints)
src-N
img src-1=(width 30em) foo.5 .5x, foo1 1x, foo2 2x, foo3 3x
src-2=bar.5 .5x, bar1 1x, bar2 2x, bar3 3x
src=foo1
PreloaderCSS
img src=foo1 id=foo
style
@media (width 30em) { #foo { content: replaced image-set(foo.5
.5x, foo1 1x, foo2 2x, foo3 3x); } }
@media (width = 30em) { #foo { content: replaced image-set(bar.5
.5x, bar1 1x, bar2 2x, bar3 3x); } }
/style
Use-case 3: Variable-sized images
src-N
img src-1=100% (30em) 50% (50em) 33%; foo200 200, foo400 400, foo800
800, foo1200 1200, foo1600 1600 src=foo1
PreloaderCSS
img src=foo1 id=foo
style
#foo { content: replaced image-set(foo200 200, foo400 400,
foo800 800, foo1200 1200, foo1600 1600); }
@media (width 30em) { #foo { width: 100vw; }}
@media (30em = width 50em) { #foo { width: 50vw; }}
@media (width = 50em) { #foo { width: 33vw; }}
/style
These examples... do not look good.
The simplest one isn't much worse, granted. It suffers from the put
an id on it that makes working with label/input a minor chore,
but otherwise is mostly just shifting things around.
The second one is a bit more annoying. The additional syntax weight
of the CSS trappings add up a bit, even with only two options.
The third one is just more or less ridiculous. The added syntax
weight really shows itself here, with three largish lines to express
what src-N does in 5 tokens. The fact that the sizes are separated
from the sources is weird. The fact that you can only use a few units
(because you're no longer able to say evaluate these sizes in an MQ
context, so em units and the like are useless because they depend
on style resolution) is very confusing.
This is a subset of CSS, yes, but the line dividing what you can use
from what you can't is rather windy, rather than being clear-cut and
simple. People will regularly get this wrong.
Any argument that this is simpler to author, or easier for CMSes to
deal with, is rather laughable. It's just as hard, if not more so.
A further, and kinda killer, problem with this is that it *can't be
reasonably polyfilled*. I know as much as anyone that designing
around polyfills is often too limiting, but seriously, polyfilling
this requires a full CSS parser. What this actually means is that
people will be using custom attributes and PictureFill or whatever for
a long time. They'll be polyfilling for a long time regardless, but
the problem here is that they wont' be using a syntax compatible with
the real solution.
The one benefit of this proposal is that it potentially lets us
preload unrelated CSS images, if they happen to match the patterns we
specify (inline, id or class selector, etc.). That sounds like
something that would be good to do regardless, but doesn't by itself
buy us enough benefit to justify the rest of the pain of this
solution.
Do you have an alternative proposal aside from src-N? Recall that
src-N has been rejected by WebKit and therefore is no longer viable.
Adam
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Tue, Nov 12, 2013 at 12:08 AM, Jukka K. Korpela jkorp...@cs.tut.fi wrote: 2013-11-12 9:58, Adam Barth wrote: Unfortunately, we can't add new tags to head. If the parser sees a tag it doesn't recognize in the head, it creates a fake body tag and pushes the tag down into the body. But you could use style type=text/foobar.../style, with a suitable value for foobar, like x-imgset. This could even be handled with a polyfill in old browsers (JavaScript code that reads such elements and interprets their content). Maybe there's a CSS solution to this problem? Do we just need to make the preload scanner smarter about interpreting CSS? Adam
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Tue, Nov 12, 2013 at 12:29 AM, Jukka K. Korpela jkorp...@cs.tut.fi wrote: 2013-11-12 10:14, Anselm Hannemann wrote: no, a preload scanner will never (okay, never say never) interpret CSS. This is against the rule of it to improve performance before interpreting layout. This whole thing is about scanning *something* in early phase, so if some rules prevent from using style sheets for something that is really a stylesheet matter (unless we regard it as a client/server negotiation issue), change the rules. The rule that Anselm refers to does not exist. We can make the preload scanner smarter if we want to. It's just a matter of understanding the engineering constraints under which it operates. Given that I wrote the preload scanner that's used in WebKit and Blink, I have a pretty good grasp of those constraints. :) Adam
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Tue, Nov 12, 2013 at 9:22 AM, Markus Ernst derer...@gmx.ch wrote:
Am 12.11.2013 17:48 schrieb Markus Lanthaler:
On Tuesday, November 12, 2013 5:04 PM, Markus Ernst wrote:
We could define some ways to list set of images that could be
replaced for a given img element in HTML and then let CSS pick which
one to use for example.
style type=text/css
@media (min-width: 480px) {
img.artdirected {
use-src: 1;
}
}
@media (min-width: 600px) {
img.artdirected {
use-src: 2;
}
}
/style
img class=artdirected
src=small.jpg
src-1=medium.jpg
src-2=large.jpg
alt=Alternative text
[...]
This may be technically incorrect or incomplete; it's just a sketch of
the idea, based on my conviction that sources belong into the img
element, while MQs should be kept centralised.
Using URL templates this could be simplified even further. For example by
extending the meta element to allow it to set some form of global
configuration variables it would be possible to define images using a
simple
naming convention:
head
meta var=img-size content=small
meta var=img-size content=medium media=min-width: 480px
meta var=img-size content=large media=min-width: 900px
/head
body
img src=teaser-fallback.jpg src-t=teaser-{img-size}.jpg
img src=profile-fallback.jpg src-t=profile-{img-size}.jpg
/body
If a variable is set multiple times as in the case above, the latest
assignment wins. As soon as the closing head tag is encountered, the value
of all variables is known and they effectively become constants that can
be
used to fill the URL templates of the images in the document's body.
That looks really cool to me. Is there any reason why this kind of approach
is not part of the discussion?
We might even be able to make this work without inventing anything:
style type=text/css
@media (min-width: 480px) {
.artdirected {
width: 30px;
height: 30px;
background-image: image-set(url(small.png) 1x, url(small-hires.png) 2x);
}
}
@media (min-width: 600px) {
.artdirected {
width: 60px;
height: 60px;
background-image: image-set(url(large.png) 1x, url(large-hires.png) 2x);
}
}
/style
div class=artdirected/div
All the information is there. We just need to teach the preload
scanner to parse a subset of CSS and match a subset of selectors. If
you stay within the preloadable subset, then your images will be
loaded by the preload scanner. Otherwise, they'll just be loaded
normally.
What's most attractive to me about this approach is that it doesn't
require inventing anything new, which means the compatibility story
for older user agents is solid. You don't need a polyfill or anything
like that.
Adam
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Tue, Nov 12, 2013 at 10:17 AM, Markus Lanthaler
markus.lantha...@gmx.net wrote:
On Tuesday, November 12, 2013 6:50 PM, Adam Barth wrote:
We might even be able to make this work without inventing anything:
style type=text/css
@media (min-width: 480px) {
.artdirected {
width: 30px;
height: 30px;
background-image: image-set(url(small.png) 1x, url(small-hires.png)
2x);
}
}
@media (min-width: 600px) {
.artdirected {
width: 60px;
height: 60px;
background-image: image-set(url(large.png) 1x, url(large-hires.png)
2x);
}
}
/style
div class=artdirected/div
All the information is there.
Except if there are other, external stylesheets that might overwrite these
definitions
The preloader is just heuristic. There are many cases where it loads
resources that aren't needed by the page.
We just need to teach the preload
scanner to parse a subset of CSS and match a subset of selectors. If
you stay within the preloadable subset, then your images will be
loaded by the preload scanner. Otherwise, they'll just be loaded
normally.
What's most attractive to me about this approach is that it doesn't
require inventing anything new, which means the compatibility story
for older user agents is solid. You don't need a polyfill or anything
like that.
I see a number of other problems with this approach as well. E.g., how would
this work for videos?
That sounds like a separate problem that we can solve separately.
Neither srcset nor src-N nor picture address videos.
What about browsers not supporting media queries (or
CSS for that matter)?
The web site will likely need to do something different to support
those browsers. That's likely the case already if the web site wants
to support browsers that don't implement CSS.
With this solution you need to replace all img tags
with meaningless divs. Right clicking to save an image would break as well.
It's extremely common practice to use background-image to supply
images today. Perhaps we should solve the
right-click-to-save-a-CSS-background-image problem in a way that works
for all these uses.
On Tue, Nov 12, 2013 at 10:23 AM, matmarquis.com m...@matmarquis.com wrote:
This is possible using a set of proposals already underway, last I checked in
on them: http://nicolasgallagher.com/responsive-images-using-css3/
Considering the delay involved in skipping the preparser and waiting for CSS
to download (as well as the fact that the `src` *will* be prefetched,
resulting in a double-request), this really leaves us in the same position as
any number of script-based solutions—we’re just creating a responsive images
“engine” in CSS, rather than in JavaScript or inside an SVG.
Please read my proposal. I'm suggesting that we teach the preload
scanner how to understand a subset of CSS large enough to cover these
use cases. It doesn't involve any futuristic CSS technology. It just
requires adding smarts to existing implementations of existing
standards. You point about prefetching the src attribute is also
incorrect because there is no src attribute in my proposal. Fallback
isn't handled by src. It's handled by CSS.
This subject has come up a number of times on the respimg list, and it always
plays out largely the same way: an optimization like this would be beneficial
for sure (and I’m in favor of one myself), but in this context we’re looking
at creating an entire variable syntax specific to images.
My proposal did not include any new syntax. Please read my proposal
before trying to shoot it down. :)
Obviously there’s a huge amount of implementation overhead involved in
something like this, and making it a requirement in any proposal would create
a *huge* barrier to implementation vs. getting a simple *extendable* markup
pattern in place and building on that. Once we have a solution in place for
responsive images, it makes sense that it would become a consideration in
larger discussions such as
http://lists.w3.org/Archives/Public/www-style/2013May/0638.html
Given that I'm an implementor and you don't appear to be an
implementor, I'd like to ask you to believe me when I say that my
proposal is a smaller implementation burden than picture or src-N.
We don’t want the search for the all-time-perfect responsive image solution
to stand in the way of setting up the foundation for one, and we definitely
don’t want to create a set of solutions to larger problems that can only ever
apply to image sources.
My proposal doesn't involve inventing anything. It's just a proposal
to optimize a subset of CSS. These optimizations will benefit folks
interested in responsive images. They will also benefit existing
content that happens to fall into the subset without caring about
responsive images.
Adam
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Tue, Nov 12, 2013 at 10:40 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Nov 12, 2013 at 9:50 AM, Adam Barth w...@adambarth.com wrote:
We might even be able to make this work without inventing anything:
style type=text/css
@media (min-width: 480px) {
.artdirected {
width: 30px;
height: 30px;
background-image: image-set(url(small.png) 1x, url(small-hires.png) 2x);
}
}
@media (min-width: 600px) {
.artdirected {
width: 60px;
height: 60px;
background-image: image-set(url(large.png) 1x, url(large-hires.png) 2x);
}
}
/style
div class=artdirected/div
All the information is there. We just need to teach the preload
scanner to parse a subset of CSS and match a subset of selectors. If
you stay within the preloadable subset, then your images will be
loaded by the preload scanner. Otherwise, they'll just be loaded
normally.
What's most attractive to me about this approach is that it doesn't
require inventing anything new, which means the compatibility story
for older user agents is solid. You don't need a polyfill or anything
like that.
If you legitimately think this will work, I'm for it. If you just
think it's a vague maybe, I'd like to continue pursuing new syntax.
The hard part is deciding what to put in the optimized subset. We
already parse media queries in the preload scanner to find imported
stylesheets to load. We probably won't be able to support every media
query under the sun, but we could support maybe min-width, min-height,
and min-device-pixel-ratio (or whatever you think is best along these
lines).
For selector matching, we wouldn't be able to support anything that
needs to understand the structure of the tree (e.g., descendant
selectors or sibling selectors). I'd probably start with just single
class and id selectors.
In case it wasn't clear from the above, we wouldn't preload the image
until we'd encountered the div with the appropriate class name. When
scanning that start tag token, we'd simulate CSS selector matching in
the preload scanner to see if we've understood any rules that match.
None of the above is all that difficult, and it's probably something
we should do anyway to improve image preloading across the whole web.
Adam
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Tue, Nov 12, 2013 at 10:45 AM, John Mellor joh...@google.com wrote:
On Tue, Nov 12, 2013 at 5:50 PM, Adam Barth w...@adambarth.com wrote:
We might even be able to make this work without inventing anything:
style type=text/css
@media (min-width: 480px) {
.artdirected {
width: 30px;
height: 30px;
background-image: image-set(url(small.png) 1x, url(small-hires.png)
2x);
}
}
@media (min-width: 600px) {
.artdirected {
width: 60px;
height: 60px;
background-image: image-set(url(large.png) 1x, url(large-hires.png)
2x);
}
}
/style
div class=artdirected/div
Three downsides to that:
- Doesn't address viewport-switching (variable-sized images), though we may
be able to fix that by extending image-set to support src-N's
viewport-urls syntax.
Why doesn't it support variable-sized images? In example above, one
of the cases is 30x30 and the other is 60x60. Maybe I've
misunderstood what you mean by variable-sized images?
- Requires you to know the intrinsic aspect ratio of the images in advance.
That seems like something we should improve about CSS more generally.
- Slightly less semantic (can't include an alt attribute, etc).
- Most sites will end up just referencing all their images by #id, which is
fairly icky. Since we're inlining the presentation into the content anyway,
may as well inline it next to the relevant bit of the content.
These seem like minor concerns compared to the cost of inventing new
HTML elements, attribute, and semantics.
On Tue, Nov 12, 2013 at 5:50 PM, Adam Barth w...@adambarth.com wrote:
What's most attractive to me about this approach is that it doesn't
require inventing anything new, which means the compatibility story
for older user agents is solid. You don't need a polyfill or anything
like that.
Except that most user agents don't support image-set yet (only Chrome and
Safari 6+ IIRC).
No user agents support src-N or picture, so we're already ahead of
the game. :)
If we did want to split src-N up to separate presentation from content,
you'd probably want to put the size-viewport-list and media-querys into
inline CSS, and leave just the size-based-urls (which are pure content) in
the HTML. Then you'd end up with something like the following.
If you just have viewport-switching (and dpr-switching), it'd be:
style
.photo {
image-width: 100%;
}
/style
img class=photo srcs=160.jpg 160, 320.jpg 320, 640.jpg 640, 1280.jpg
1280, 2560.jpg 2560
(and as in src-N, you could use more complicated size-viewport-list
expressions like 100% (30em) 50% (50em) 33% if the image width is a
non-linear function of viewport width)
If you just have dpr-switching (fixed-width images), it'd be:
style
.photo {
image-width: 128px;
}
/style
img class=photo srcs=64.jpg 64, 128.jpg 128, 256.jpg 256
(where the ratio between the widths of the available images, and the
image-width from CSS, is used to calculate the density of each available
image)
If you have art direction and dpr-switching, it'd be:
style
.photo {
image-width: small 128px;
}
@media (min-width: 20em) {
.photo {
image-width: big 400px;
}
}
/style
img class=photo
srcs-small=s64.jpg 64, s128.jpg 128, s256.jpg 256
srcs-big=b200.jpg 200, b400.jpg 400, b800.jpg 800
(here the author has assigned names to each of their art direction cases
[optional if you only have one case], and provides an alternate list of
image srcs for each case)
This actually looks pretty reasonable (and unlike earlier proposals in this
thread, covers all use cases). One nice benefit over src-N is that the
size-viewport-list -- i.e. 128px or 100% or 100% (30em) 50% (50em)
33% -- doesn't get repeated for every image, if there are several images
with the same relationship between viewport size and image size.
These proposals all invent new syntax and semantics. I'd much rather
start with an approach that doesn't introduce new syntax or semantics
and just makes the web faster by optimizing existing content.
My main concern is that authors won't realise that the CSS must be inlined;
I'm not sure how to make that foolproof.
We'll have to write tutorials and the like. All these proposals have
a developer education component. Developers won't magically know how
to use src-N either.
Adam
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Tue, Nov 12, 2013 at 11:38 AM, li...@ericportis.com
li...@ericportis.com wrote:
On Tue, Nov 12, 2013 at 9:50 AM, Adam Barth w...@adambarth.com
(mailto:w...@adambarth.com) wrote:
We might even be able to make this work without inventing anything:
style type=text/css
@media (min-width: 480px) {
.artdirected {
width: 30px;
height: 30px;
background-image: image-set(url(small.png) 1x, url(small-hires.png) 2x);
}
}
@media (min-width: 600px) {
.artdirected {
width: 60px;
height: 60px;
background-image: image-set(url(large.png) 1x, url(large-hires.png) 2x);
}
}
/style
div class=artdirected/div
Would the style element have to reside inline, to reap the performance
benefits?
If you want the preload scanner to be able to load the images, you'll
need to put the URLs in a place where the preload scanner can see
them, which means inline.
Adam
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
Unfortunately, we can't add new tags to head. If the parser sees a tag it doesn't recognize in the head, it creates a fake body tag and pushes the tag down into the body. Adam On Mon, Nov 11, 2013 at 7:43 PM, Bruno Racineux br...@hexanet.net wrote: Here is a complementary approach to the src-N syntax, I'd like to present for discussion. The goal is: 1. Address all use cases in a similar way as src-N does without the 'N' part. 2. Cut the verbose to a 'strict' minimum with reusable OO definitions. 3. Provide a vocabulary that is easy to parse and easily interpretable by javascript. It's not src-N or srcset, because the new inline semantic refers to 'sizes' instead, and require only the one original 'src' for all images. First we provide the image set definitions in the head for the preloader as: imgset 1: 1080, 1024, 960, 900, 854, 840, 800, 720, 640, 600, 540, 500, 420, 300, 240; 2: 200, 150, 100, 75, 50; logo: small 150 1x 300 2x, medium 200 1x, large 250 1x; custom: /(?=\-)(.*)(?=\.)/s; //-- regex pattern value /imgset Set 1 and 2 define all widths available for those particular sets. It assumes the 'image-WxH.ext' format by default. (I omitted a regex for those, we'll consider this a default pattern for now) The third set (logo), is one that defines a keyword relationship with img sizes. (note: 'logo:small' is both 150px at 1x resolution and 300px at 2x resolution) Then 'custom', is the regex pattern used at the platform level for naming the different sizes. Here is the first img example using the 'image-WxH.ext' image name syntax. img width=600 height=300 src=image-600x300.jpg res=1x imgset=1 sizing=ratio sizes=100% (360px) 66% (800px) 33% The new 'res' attribute would define the pixel density the author chooses to provide. The 'imgset' attribute refers to the imgset target definition list by ID or keyword. The 'sizing' attributes provides the custom matching pattern for how images are stored, and for the browser to replace the original src with its current width+resolution match. Finally the 'sizes' attribute is similar to src-N as far as handling variable size imgs. The browser can figure out the width/height ratio given by the 'width' and 'height' attributes. Here is another example which use the imgset '2' with a pixel size, and indicated resolution at 1x and 2x: img width=100 height=100 src=gravatar-100x100.jpg res=1x,2x imgset=2 sizing=ratio sizes=50px (360px) 75px (800px) 100px Even though the breakpoint sizes are in pixel, the browser can do the math using the 'ratio' sizing and the given 'res' values. No need to specify multiple pixel densities in the imgset(s) when a pixel ratio is involved. Finally the 'custom' case which uses the 'logo' imgset as reference. img width=250 height=100 src=logo-large.jpg res=1x,2x sizing=custom imgset=logo sizes=small (360px) medium (800px) large The 'custom' regex pattern is used to determine what image name correspond to the appropriate breakpoint sizes. With the above applied to an iPhone 3, logo-large.jpg becomes logo-small.jpg, and stays logo-large.jpg for the iPhone 4. Overall this solution cuts off the fat by a very large margin. And the introduction of a regex way seem like a good approach (and probably the only one) to also remove the 'src' verbose, with the advantage of reusable definitions by multiple images. Also the head's imgset can be converted to (or even given as) json for javascript interpretation readiness. Anyhow, this is the complementary and optimized approach I am suggesting. -BR On 11/10/13 9:29 AM, Ilya Grigorik igrigo...@gmail.com wrote: On Sun, Nov 10, 2013 at 8:59 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: It's easy to look at something more complex than what you're used to and dismiss all the excess as unneeded, but it's really, seriously not in this case. The things I'm addressing are the things that RICG research found were common and necessary, no more and no less. Big +1 to that -- src-N addresses all the RICG use cases in a consistent and coherent way.. and is the only option that does so. Serving images in our new multi-device / responsive design world *is* a much harder problem and the complexity of src-N is simply a reflection of that.. Sticking our heads in the sand and pretending that this is not the case, or punting the problem down the road (as we've already done for the past few years), is not a sound strategy.
Re: [whatwg] The src-N proposal
On Fri, Nov 8, 2013 at 11:46 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 8 Nov 2013, Rafael Rinaldi wrote: It looks complex because it tries to solve something complex. I think there’s no way to avoid verbosity to solve such thing. The way you avoid complexity in such things is that you don't solve the overall problem, you solve small segments of the problem (e.g. in script or CSS), then pick the solution you want. So for example, we could have a script to handle image grids, another to handle simple cases where as the window gets wider you display more context in the image, etc. If all these scripts have some common features they all need (e.g. the ability to work with pre-parsing to say which image they need first, so it can be fetched early) then we can provide that common core. This is similar to AppCache vs Alex's ServiceWorkers. AppCache addresses a small set of use cases, probably not enough. ServiceWorkers provides the tools to address a lot of use cases, but isn't directly itself a solution; you use it to build solutions. Another example would be the WebForms2 repetition model, vs Rafael's template. The repetition model idea solved some specific use cases, but trying to make it solve all use cases would be a hugely complicated endeavour and would be really ugly. template provides a tool with which you can build specific solutions, but isn't itself a direct solution. I basically agree with Ian. Let's address the simple use cases first (i.e., device-pixel-ratio switching) and worry about the more complex use cases in the future. Adam
Re: [whatwg] The src-N proposal
On Sun, Nov 10, 2013 at 9:29 AM, Ilya Grigorik igrigo...@gmail.com wrote: On Sun, Nov 10, 2013 at 8:59 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: It's easy to look at something more complex than what you're used to and dismiss all the excess as unneeded, but it's really, seriously not in this case. The things I'm addressing are the things that RICG research found were common and necessary, no more and no less. Big +1 to that -- src-N addresses all the RICG use cases in a consistent and coherent way.. I don't think that's a valuable goal. My preference would be to address only the device-pixel-ratio use case in this iteration. and is the only option that does so. Serving images in our new multi-device / responsive design world *is* a much harder problem and the complexity of src-N is simply a reflection of that.. Sticking our heads in the sand and pretending that this is not the case, or punting the problem down the road (as we've already done for the past few years), is not a sound strategy. If we wait for agreement about how to address the other use cases, we won't ship anything for a long time. I'd rather ship something that's useful today and iterate to improve it in the future than not ship anything for a long time. Adam
Re: [whatwg] The src-N proposal
On Nov 10, 2013 11:39 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Sun, Nov 10, 2013 at 10:46 AM, Adam Barth w...@adambarth.com wrote: On Sun, Nov 10, 2013 at 9:29 AM, Ilya Grigorik igrigo...@gmail.com wrote: On Sun, Nov 10, 2013 at 8:59 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: It's easy to look at something more complex than what you're used to and dismiss all the excess as unneeded, but it's really, seriously not in this case. The things I'm addressing are the things that RICG research found were common and necessary, no more and no less. Big +1 to that -- src-N addresses all the RICG use cases in a consistent and coherent way.. I don't think that's a valuable goal. My preference would be to address only the device-pixel-ratio use case in this iteration. Can you explain why? It's for the reason in the second paragraph of my previous email: I don't think we'll get agreement about how to address the other use cases in the near term and I view the device-pixel-ratio use case as important to address in the near term. I believe the RICG's identified use-cases are both reasonable and minimal. If we address *only* the density case right now, significant fractions of *existing* responsive images code won't be able to migrate to the standardized solution, and will be stuck with hacks. We'll obviously never be able to satisfy 100% of use-cases, nor is anyone trying to. But just density isn't enough, based on the observed patterns in the wild. and is the only option that does so. Serving images in our new multi-device / responsive design world *is* a much harder problem and the complexity of src-N is simply a reflection of that.. Sticking our heads in the sand and pretending that this is not the case, or punting the problem down the road (as we've already done for the past few years), is not a sound strategy. If we wait for agreement about how to address the other use cases, we won't ship anything for a long time. I'd rather ship something that's useful today and iterate to improve it in the future than not ship anything for a long time. The RICG and related community has agreed on src-N, and the relevant Blink and FF devs have as well. The only holdout is WebKit, That's exactly the problem. The WebKit community has been clear they don't want to ship src-N. but they haven't expressed any technical objections, just aesthetic ones. (And, not to be rude, but I don't trust the aesthetic judgement of C++ hackers when applied to the web platform; at least, not over the judgement of actual JS and HTML hackers, who are generally fine with the look of src-N. People who write the web rather than write *in* the web have a long history of liking terribly-shaped APIs because they're more familiar to C++ coders.) (IE hasn't expressed an opinion one way or the other, as usual.) You might not find their reasons compelling, but that's largely beside the point. What's relevant is that they aren't willing to ship src-N. Maybe through additional discussion we could find a mutually agreeable approach for addressing the remaining use cases, but that appears unlikely to happen in the near term. I believe you're applying an inappropriately high standard of required agreement to this proposal, compared to what the usual required level is for something to be accepted. If Blink ships src-N and WebKit ships srcset, we'll have a mess on our hands. Authors will end up using both. If they do, they're likely to have different behavior in different browsers, which is an interoperability problem. The best solution I see to the above constraints is to ship device-pixel-ratio switching via srcset today and to continue to discuss how to address the remaining use cases in the future. Adam
Re: [whatwg] The src-N proposal
On Sun, Nov 10, 2013 at 1:53 PM, Ilya Grigorik igrigo...@gmail.com wrote: On Sun, Nov 10, 2013 at 12:58 PM, Adam Barth w...@adambarth.com wrote: I believe you're applying an inappropriately high standard of required agreement to this proposal, compared to what the usual required level is for something to be accepted. If Blink ships src-N and WebKit ships srcset, we'll have a mess on our hands. Authors will end up using both. If they do, they're likely to have different behavior in different browsers, which is an interoperability problem. The best solution I see to the above constraints is to ship device-pixel-ratio switching via srcset today and to continue to discuss how to address the remaining use cases in the future. srcset is a cul de sac with respect to these goals. Let's look at our options: (1) + srcset addresses resolution-switching. (2) + in theory, srcset provides basic facilities for viewport-switching - although none of the current implementations support it. (3) - srcset viewport-switching syntax is a disaster for real-world scenarios [1] Agreed. I recommend removing viewport switching from srcset and addressing only the device-pixel-ratio use case. (4) - srcset does not provide any easy way to extend itself for art direction That's ok. We'll just need to add another mechanism in the future to address art direction. By contrast, src-N is a superset: it covers (1) and (2), with same syntax even; it addresses (3); it enables (4). Unfortunately, src-N is no-go because WebKit refuses to implement it. Now, it's possible you'll convince them that it's not a grotesque perversion of the HTML language (which does seems a bit hyperbolic), but that seems unlikely to happen in the near term. Given the tenor of that discussion, I'd expect we'll need to come up with a new approach and involve stakeholders from the WebKit community earlier in the design process. We have Mozilla and RICG behind src-N, and I hope Blink can put its weight behind it also.. There's certainly interest in src-N from the Blink community, but we're unlikely to ship something here that WebKit refuses to implement. I hope we can all work with Webkit team to address their concerns and solve this problem once and for all. Me too. However, I don't want to wait for that to happen. I want to ship something that addresses the device-pixel-ratio use case in the near term and continue discussing how to address the remaining use cases. So far, as Tab has pointed out, the src-N concerns we've heard are all cosmetic, and I think those discussions are distracting us from the real conversation we should be having, which is... how is srcset planning to address its shortcomings in a better way than src-N? It's not. The only use case srcset will address is the device-pixel-ratio use case. Adam
Re: [whatwg] Proposal: location.parentOrigin
On Tue, Jul 16, 2013 at 4:14 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 17 Jul 2013, Tobie Langel wrote: On Wednesday, July 17, 2013 at 12:42 AM, Ian Hickson wrote: On Wed, 17 Jul 2013, Tobie Langel wrote: On Tuesday, July 16, 2013 at 7:53 PM, Ian Hickson wrote: Can't you do window.isSameOrigin by just trying to access window.location.href and seeing if you get an exception? Unfortunately not, because of the previously mentioned WebKit bug which logs an error message but doesn't throw (so there's no way of knowing whether an exception was thrown or not). We can trivially change that, if that's the only problem. Fixing that bug would be a great step forward. Adam? We're in the process of changing that now. You can follow our progress on this bug: https://code.google.com/p/chromium/issues/detail?id=17325 Adam
Re: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use
On Fri, Jul 12, 2013 at 11:35 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 7/12/13 2:15 PM, Ian Hickson wrote: What's not useful about the way it's defined? It's set to a specific string. I couldn't find where it was normatively set to anything. In cases when the hostname is non-ASCII, the Referer header will have it encoded in punycode. Is that defined anywhere? http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.36 which defines it syntactically as a URI, which means that if you have an IRI you have to convert it to an IRI before putting it in there. That's correct per spec (assuming the punycoding is required anywhere). The latter two are set separately than document.referrer: http://whatwg.org/html/#set-the-document's-address The thing is, people are comparing origins from postMessage to origins from document.referrer. See https://bugzilla.mozilla.org/show_bug.cgi?id=852796#c6. Also see https://bugzilla.mozilla.org/show_bug.cgi?id=720331. Also, as a note, nothing above makes it particularly clear that the URL that was originally to be fetched is not already punycode... Ah, well. If other browsers don't match this, file bugs on them. :-) shrug. It probably won't do much good, but: http://code.google.com/p/chromium/issues/detail?id=259920thanks=259920ts=1373653828 I don't think we're likely to change this behavior. We always use punycode for URLs except in the location bar. Why not change Firefox to use punycode in window.location? Adam
Re: [whatwg] Html5 Parser Tree Construction Stage
You're welcome to look at Blink's implementation of tree construction. That might be a good way of seeing what data structure might be useful. The work is split into two major objects: https://chromium.googlesource.com/chromium/blink/+/master/Source/core/html/parser/HTMLTreeBuilder.h https://chromium.googlesource.com/chromium/blink/+/master/Source/core/html/parser/HTMLConstructionSite.h The HTMLTreeBuilder dispatches the token and HTMLConstructionSite does the actual tree construction. Adam On Sun, Jun 23, 2013 at 3:02 AM, Mohammad Al Houssami (Alumni) mh...@mail.aub.edu wrote: Hello All, I am building an HTML5 parser according to the specs on the whatwg website. I am currently in the tree construction stage and it seems to be so complex to have a general view of what is happening by reading the specs or at least know what things are needed ( like node types element types and the variables of each..) Is there any place where these things are listed or maybe an explanation of the tree construction stage that explains what is happening during in a general view? Any help is much appreciated :) Mohammad
Re: [whatwg] scrdoc and session history don't play along in the spec
On Sun, Jun 23, 2013 at 6:42 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/23/13 1:15 AM, Adam Barth wrote: One tricky case here is what happens if you modify the srcdoc attribute: Ah, indeed. iframe id=foo srcdoc=aaa/iframe script [...] // Wait for the iframe to finish loading. document.getElementById(foo).srcdoc = bbb; [...] // Wait for the iframe to finish loading. document.getElementById(foo).contentWindow.document.body.innerHTML = ccc; /script What happens if you click the back button now? I believe Gecko's upcoming implementation will show aaa, but I haven't tested to make sure. That's because we navigated back in the history to about:srcdoc, which then looked at the srcdoc property and saw bbb even though the srcdoc property had aaa when that history entry was created. Ah, we're just storing the srcdoc text in the history entry for srcdoc loads, I think, precisely because you can't rely on the value of the attribute. I guess it depends on what you mean by rely. We just treat the about:srcdoc URL as something that, when fetched, retrieves the value currently stored in the srcdoc attribute. In this case, when you go back, we'll fetch about:srcdoc again and get the current value of the srcdoc attribute, bbb. Adam
Re: [whatwg] scrdoc and session history don't play along in the spec
On Fri, Apr 5, 2013 at 8:44 AM, Boris Zbarsky bzbar...@mit.edu wrote: The session history algorithm in the spec navigates to urls. As far as I can tell, on the face of it, this means that this testcase: iframe name=x srcdoc=aaa/iframe a target=x href=http://web.mit.edu; Click me, then later hit back /a should fail to go back. The good news is that at least WebKit's srcdoc implementation ignores the spec here and makes back work, and so will Gecko's. But the spec still needs to be fixed. Again, as far as I can tell; actually telling anything for sure about the navigation/shistory part of the spec is impossible. :( One tricky case here is what happens if you modify the srcdoc attribute: iframe id=foo srcdoc=aaa/iframe script [...] // Wait for the iframe to finish loading. document.getElementById(foo).srcdoc = bbb; [...] // Wait for the iframe to finish loading. document.getElementById(foo).contentWindow.document.body.innerHTML = ccc; /script What happens if you click the back button now? I believe that in WebKit and Blink, you'll get bbb. That's because we navigated back in the history to about:srcdoc, which then looked at the srcdoc property and saw bbb even though the srcdoc property had aaa when that history entry was created. If you implemented srcdoc with wyciwyg in Gecko, you'd probably get aaa because that's what you would have cached when you created the original history item. Adam
Re: [whatwg] iframe sandbox and allow-scripts
On Fri, Apr 12, 2013 at 4:56 PM, Ian Melven imel...@mozilla.com wrote:
Freddy Braun recently noticed that he could do the following in Firefox :
iframe id='foo' sandbox='allow-same-origin' src='inner.html'
(note no allow-scripts)
and then in the document containing the iframe:
var iframe = document.getElementById('foo');
iframe.contentWindow.eval(alert(document.location));
and the alert will fire, which he found surprising.
That's the behavior I would expect. You can also do the following:
var iframe = document.getElementById('foo');
iframe.contentWindow.alert(hello);
The allow-scripts sandbox flag doesn't block the script interfaces
inside the iframe. It just prevents content inside the iframe from
triggering script execution. In this case, the content outside the
iframe is the one triggering the script execution.
Adam
Re: [whatwg] Another issue in 12.2.5.5 parsing tokens in foreign content
On Thu, Apr 18, 2013 at 12:27 AM, Michael Day mike...@yeslogic.com wrote: Another issue regarding recent changes to 12.2.5.5 The rules for parsing tokens in foreign content. When a HTML start tag is seen (specifically b, big, blockquote, body, br, center, code, ...) the following procedure is given to recover from the parse error: If the stack of open elements does not have an element in scope that is a MathML text integration point, an HTML integration point, or an element in the HTML namespace, or if the stack of open elements has only one element, then process the token using the rules for the in body insertion mode. (fragment case) Since the stack of open elements always has html at the top of the stack, the element in scope algorithm will always find it, and as a result, the first part of the condition will always fail. Even in the fragment case? (Note the parenthetical remark in the spec about this text applying only in the fragment case.) Adam This seems unintentional, and depends upon the exact way in which the element in scope algorithm is defined. Perhaps rewriting this paragraph without reference to the element in scope algorithm would make the intent clearer? For example: If the stack of open elements does not any elements that are MathML text integration points, or HTML integration points, or that are in the HTML namespace, or if the stack of open elements has only one element ... Any thoughts? Best regards, Michael
Re: [whatwg] Fetch: Origin header
On Fri, Mar 8, 2013 at 2:23 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Mar 7, 2013 at 7:29 PM, Adam Barth w...@adambarth.com wrote: I don't have strong feelings one way or another. Generally, I think it's a good idea if the presence of the Origin header isn't synonymous with the request being a CORS request because that could limit our ability to use the Origin header in the future. Okay. So currently the mix of the Origin specification and the HTML specification suggests you either do Origin: /origin/ or Origin: null. However WebKit seems to do Origin: /origin/ or no header at all (for the privacy-sensitive cases). Ian also mentioned that we can not just put the Origin header into every outgoing request as that breaks the interwebs (per research you did for Chrome I believe?). What do you think we should end up requiring? I would recommend including an Origin header in every non-GET request (and, of course, in some GET requests because of CORS). Adam
Re: [whatwg] Fetch: Origin header
On Thu, Mar 7, 2013 at 9:07 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Mar 6, 2013 at 3:21 PM, Anne van Kesteren ann...@annevk.nl wrote: Unless PHP does not expose Origin under HTTP_ORIGIN in $_SERVER as one would expect... (It does btw.) So I also tested the fetch from an origin in the specification http://dump.testsuite.org/fetch/form.html and it turns out that only WebKit exhibits this behavior. Other browsers do not include Origin in a navigation that uses the POST method. Adam, is that something you think we should keep? I don't have strong feelings one way or another. Generally, I think it's a good idea if the presence of the Origin header isn't synonymous with the request being a CORS request because that could limit our ability to use the Origin header in the future. Adam
Re: [whatwg] Fetch: crossorigin=anonymous and XMLHttpRequest
WebKit hasn't implemented either, so we don't have any implementation
constraints in this area.
Adam
On Tue, Feb 26, 2013 at 3:35 AM, Anne van Kesteren ann...@annevk.nl wrote:
There's an unfortunate mismatch currently. new
XMLHttpRequest({anon:true}) will generate a request where a) origin is
a globally unique identifier b) referrer source is the URL
about:blank, and c) credentials are omitted. From those
crossorigin=anonymous only does c. Can we still change
crossorigin=anonymous to match the anonymous flag semantics of
XMLHttpRequest or is it too late?
--
http://annevankesteren.nl/
Re: [whatwg] Fetch: crossorigin=anonymous and XMLHttpRequest
Ah, my mistake. Kenneth is right. I didn't realize you were talking
about the crossorigin attributes.
Adam
On Tue, Feb 26, 2013 at 4:02 PM, Kenneth Russell k...@google.com wrote:
Are you referring to the crossOrigin attribute on HTMLImageElement and
HTMLMediaElement? Those are implemented in WebKit. It should be fine
to change crossOrigin=anonymous requests to satisfy (a) and (b). Any
server that satisfies these anonymous requests in a way compatible
with UAs' caching will ignore the incoming origin and the referrer.
-Ken
On Tue, Feb 26, 2013 at 2:52 PM, Adam Barth w...@adambarth.com wrote:
WebKit hasn't implemented either, so we don't have any implementation
constraints in this area.
Adam
On Tue, Feb 26, 2013 at 3:35 AM, Anne van Kesteren ann...@annevk.nl wrote:
There's an unfortunate mismatch currently. new
XMLHttpRequest({anon:true}) will generate a request where a) origin is
a globally unique identifier b) referrer source is the URL
about:blank, and c) credentials are omitted. From those
crossorigin=anonymous only does c. Can we still change
crossorigin=anonymous to match the anonymous flag semantics of
XMLHttpRequest or is it too late?
--
http://annevankesteren.nl/
Re: [whatwg] Fetch: cross-origin redirect to a data URL
On Mon, Feb 25, 2013 at 1:49 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Feb 25, 2013 at 4:30 AM, Adam Barth w...@adambarth.com wrote: I don't think there is a security problem with that. It's just a question of how much it complicates the model. Well currently for http://software.hixie.ch/utilities/cgi/data/data Chrome generates a network error if you hit Generate with the reason unsafe redirect. And that's a simple http to data URL redirect without CORS coming into play. Yes, that's to defend against a different sort of attack. In some browsers, like Firefox, data URLs inherit the security context of their authors. If a web site as an open redirect, an attacker might be able to trick the site into redirecting to a data URL of the attackers choice and thereby XSS the site. Chrome wouldn't be vulnerable to that attack because Chrome runs data URLs in unique origins, but Chrome blocks those sorts of redirects so that web sites don't use them and don't cause trouble for Firefox. Adam
Re: [whatwg] Fetch: cross-origin redirect to a data URL
I don't think there is a security problem with that. It's just a question of how much it complicates the model. Adam On Sun, Feb 24, 2013 at 10:32 AM, Anne van Kesteren ann...@annevk.nl wrote: Say img does a cross-origin request. The response to that request is a redirect with the appropriate CORS headers set. The new location is a data URL. Should that URL be tainted or not? I tend to think we should make that work. (By the way, if you're interested. I'm working on a new specification that merges HTML fetch and CORS, named Fetch. http://wiki.whatwg.org/wiki/Fetch has the rough outline so far, including an algorithm at the bottom. The idea is that everything in the platform that does network requests ties into that (in particular the fetch function which dispatches as appropriate).) -- http://annevankesteren.nl/
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Mon, Jan 14, 2013 at 5:34 PM, Jonas Sicking jo...@sicking.cc wrote: On Jan 9, 2013 11:59 PM, Adam Barth w...@adambarth.com wrote: To gather this information, I grepped the WebKit IDL files for CheckSecurity. Here's what I learned: [snip] I see no mention of document.domain handling in your description. Yeah, document.domain is no fun. :) How do you handle the case when script from one Window grabs a Node from another Window and then the document of one of the two Windows change its document.domain property? There isn't any code in WebKit that does anything special in this situation. Because there are no access checks for Node, the script can continue to use the Node interface as before. Also, in another email you mentioned that you had managed to implement the security restrictions on the Window object as a white-list rather than a black list by marking some interfaces as needs same-origin checks and then listing the functions that don't need it. Correct. Does this mean that you mark all interfaces that are implemented by the Window and Location objects as needs security checks? Including EventTarget? In WebKit, neither Location nor Window implement any other interfaces. Adam
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Wed, Jan 9, 2013 at 8:21 PM, Boris Zbarsky bzbar...@mit.edu wrote: Adam, thank you for taking the time to put this together. I really appreciate it. There are lots of things here where we can converge behavior no matter what happens with other pieces of the platform. On 1/9/13 5:58 PM, Adam Barth wrote: Generally speaking, I'd recommend exposing as few things across origins as possible. Yes, agreed. For what it's worth, I believe Gecko recently made history not accessible cross-origin anymore, so with any luck you'll be able to make this change too if desired... Do you have a link to the bug where that change was made? It's something I would definitely like to do if compatibility permits. We'd probably start with a measurement experiment... 6) In addition, the following APIs have extra security checks. All these APIs return a Node. Before returning the Node, they check whether the Node's document's origin is the same origin as the script calling the API. If not, they return null instead of the node. (We could potentially throw an exception here, but I'm just describing what WebKit does, not what I think the optimum design is.) Returning null for these is probably fine. I think I'd support making this list of things return null cross-origin. Just to check, do you make this determination based on the origin or the effective script origin (in spec terms)? The effective script origin. Adam
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Tue, Jan 8, 2013 at 5:56 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/8/13 8:14 AM, Boris Zbarsky wrote: On 1/8/13 2:09 AM, Ian Hickson wrote: In the spec's security model, origins are never relevant for elements except when we're looking at the element's data. Yes. I think the spec's security model is not viable long-term, for what it's worth, and think we should be designing a security model that is instead... Just to clarify this. You may want to talk to sicking and Mounir about what they discovered about security models in the course of getting partially-elevated-privileges web apps to work. I suspect we'll need more of that sort of thing as time goes on. Which means the security model will likely need to evolve. I'm not convinced of that. I understand that Gecko need to deal with these complications because of a number of Mozilla-proprietary APIs, but I don't know of anything in the web platform that forces other browsers to deal with these issues. If and when features are added to the platform that cause these sorts of problems, we can deal with the consequences. In the mean time, I don't think we should force other browser engines to implement a more complicated security model than necessary for the platform as it stands. Which in turn means that I believe we should not be designing APIs and other functionality around the current security model, especially if the dependency is non-obvious (and I would argue that any dependency not spelled out in the section describing the security model is non-obvious, because it's too easy to miss it when updating the security model). What I think we ahould be doing instead is designing with the assumption that some core set of things is true (and we can argue about what set that is), but making as few assumptions as possible in general. This paragraph was too abstract for me to understand. Do you have a concrete example? Put another way, I think we have good evidence that the security model in the spec, as well as that in every browser, Gecko included, is wrong in the same sense that Newtonian mechanics is wrong. The problem is that we don't know what our equivalent of special relativity is yet. I don't understand the analogy. The security model in the spec is the same one we implement in WebKit and it's been working well for WebKit for a while. If there are security vulnerabilities, hopefully Chromium's security bounty will encourage you to report them. :) More seriously, life gets complicated when you introduce an asymmetric access relation, which I understand exists in Gecko. However, the open web platform contains only a symmetric access relation, and I intent to argue against any attempt to introduce an asymmetric access relation into the platform. Reasoning about security in this context of a symmetric access relation is relatively straightforward, and to check that new APIs don't screw up the model consists only of checking that they don't contain objects that are visibile to multiple origins. We have a handful of legacy objects that are already visible to multiple origins, and it's true that they're annoying to deal with, but we've already invested the engineering effort required to make them secure in the current security model. Maybe I've lost the thread here, but I don't understand the problem you're trying to solve with this thread. The simplest solution is for contentDocument to return null when accessed from a different origin. Grepping WebKit's IDL files for [CheckSecurityForNode], it looks like this check is needed for contentDocument attribute and the getSVGDocument() method on the various interfaces that contain them. Adam
Re: [whatwg] Script-related feedback
On Mon, Jan 7, 2013 at 7:51 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 7 Jan 2013, Adam Barth wrote:
Why not just introduce a keyword or pragma to JavaScript that tells
the user agent to act as if the end of the Program production had been
reached, and that it should treat the remainder of the file as another
Program?
This could even be done in a backwards-compatible fashion by having
the syntax to do this be something that down-level clients ignore,
e.g.:
/*@BREAK*/
...or some such.
That approach is an in-band signal, which means it's vulnerable to
injection attacks.
If you can inject this, you can inject arbitrary code, so I don't see how
this would be a problem.
For example, consider a server that produces a JavaScript file of the
following form:
[...]
var userData = ?php echo santize($userData) ?;
[...]
Currently, the rules for sanitizing using input are relatively
straightforward (essentially, you just need to worry about a few special
characters).
Those simple rules would prevent anyone from inserting a pragma-like
comment, too, so that's fine.
However, if we implemented an in-band signaling we might well break
these sanitation algorithms.
How? I'm not suggesting changing any JS syntax, just making existing JS
syntax be used as a signal.
If making a comment do this is too dodgy, make it something like this:
breakParsing();
...and for down-level support, define an explicit breakParsing function
that does nothing. If someone can insert a function call into JS, you've
definitely lost already.
Working through some examples, that seems really strange:
foo();
breakParsing();
bar();
In this case, breakParsing() works a bit like yield() in other
programming languages: first foo() executes, then the event loop
spins, then bar() executes. However, if we wrap the code in an
anonymous function block (as would make sense for JavaScript):
(function() {
foo();
breakParsing();
bar();
})();
Now I get either get a parse error, if breakParsing() actually breaks
up the parsing, or breakParsing() does nothing, both of which are
surprising. Worse, other seemingly trivial syntactic transformation
also break the magic:
foo();
breakParsing.call();
bar();
Now the JavaScript parse won't recognize the magic breakParsing();
production, and my script executes slowly.
I guess I don't understand the advantage of trying to cram this into
JavaScript syntax. It's really got nothing to do with JavaScript as a
language and everything to do with providing an efficient way for web
sites to ask the browser to execute several JavaScript programs in
sequence.
HTTP already has an efficient mechanism for delivering several
JavaScript programs in sequence: multipart. Given that img and
iframe already support multipart, it seems much simpler just to make
script support multipart as well.
Adam
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
It seems like your arguments all originate from wanting to support an asymmetric access relation. Supporting an asymmetric access relation is a bad idea, and we shouldn't do it. I understand that Mozilla already has technology for implementing an asymmetric access relation and that you're using it to implement a number of current and future Mozilla-proprietary features. That's fine, of course, but if you're interested in having those features become part of the web platform, please don't be surprised when other browser vendors refuse to implement them because of their asymmetric access relation. As a consequence, I would recommend that you do not use asymmetric access relations in features that you would like other browser vendors to implement in the future. Adam On Wed, Jan 9, 2013 at 7:16 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/9/13 3:11 AM, Adam Barth wrote: I'm not convinced of that. I understand that Gecko need to deal with these complications because of a number of Mozilla-proprietary APIs, Actually, what I'm talking about here has nothing to do with APIs but everything to do with wanting to write web applications that have slightly more privileges than your typical web page. Again, you may want to talk to Jonas and Mounir for details. If and when features are added to the platform that cause these sorts of problems, we can deal with the consequences. My argument is that we should not lock ourselves out of adding such features in the future. In the mean time, I don't think we should force other browser engines to implement a more complicated security model than necessary for the platform as it stands. I'm not saying we should force anyone to implement any particular security model. I'm saying we shouldn't design/spec things that become completely insecure if the security model ever changes in any way and hence prevent evolution of the security model. Which means that we should assume as little as possible about what the security model guarantees us when specifying things. In my opinion. This paragraph was too abstract for me to understand. Do you have a concrete example? For example, Ian's argument is that you can skip security checks in various places because the security model does that already. My counter-argument is that we should define the behavior of those places by referencing the security model explicitly, so that if the security model changes we won't have to hunt down all the places that had implicit dependencies on it. Does that make more sense? Put another way, I think we have good evidence that the security model in the spec, as well as that in every browser, Gecko included, is wrong in the same sense that Newtonian mechanics is wrong. The problem is that we don't know what our equivalent of special relativity is yet. I don't understand the analogy. The current security model describes most common cases, but not some edge cases (see above about a slightly-elevated-privileges web app that can, say, touch nodes from one and only one different origin). More seriously, life gets complicated when you introduce an asymmetric access relation I agree. I believe, however, that for many apps based on web technology you in fact might need this. Again, Sicking and Mounir would know more. https://bugzilla.mozilla.org/show_bug.cgi?id=734891 has some of the things in it, but I'm not sure it's all of them. However, the open web platform contains only a symmetric access relation Yes, I understand that's how it stands now. I'm questioning the viability of this going forward, and especially questioning to what extent we should be intentionally making it impossible to change away from this model. and I intent to argue against any attempt to introduce an asymmetric access That is, of course, your right. ;) Maybe I've lost the thread here, but I don't understand the problem you're trying to solve with this thread. The simplest solution is for contentDocument to return null when accessed from a different origin. That's not enough. Window has the same problem: the document IDL getter needs to check that you're allowed to get the document of the relevant window, for example. Is the check you describe for contentDocument based on origin or effective script origin? -Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Wed, Jan 9, 2013 at 12:23 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/9/13 3:12 PM, Adam Barth wrote:
As I've stated several times on this thread (any many times over the
years), my opinion is that we should not expose an asymmetric access
relation to the web platform.
OK, let's agree to disagree on this one for now.
Do we at least agree that this code:
window.addEventListener.call(otherWindow, click, function() {});
should throw if and only window and otherWindow are not same-origin (for
some definition of same-origin, now that we have several different origins
involved...)?
This example does not appear to throw an exception in Chrome. It
appears to just returns undefined without doing anything (except
logging a security error to the debug console).
And if we do, do we agree that this needs to be specified somewhere?
Yes, but this example is unrelated to the example you started this
thread with. The WindowProxy and Location objects are special,
magical objects that work differently from other interfaces because
they are visible across origins. The Document interface (which is
what we started this thread discussing) is never visible across
origins and so does not have any of these complexities. Earlier in
this thread, you wrote that you didn't want to discuss Location:
---8---
I'm not touching Location with a 10-foot pole. That's all Bobby. ;)
Seriously, though, fitting Location into any sort of security setup is
somewhat hard.
---8---
The WindowProxy object is even more complex than the Location object.
I agree that fitting Location and WindowProxy into any sort of
security setup is difficult. That's why I don't want to infect the
rest of the platform with their complexity. (I again, I understand
that Gecko has already jumped of the cliff in this regard---I'm just
not interested in jump off as well.)
Adam
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Wed, Jan 9, 2013 at 1:28 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 9 Jan 2013, Adam Barth wrote: The Document interface (which is what we started this thread discussing) is never visible across origins and so does not have any of these complexities. Actually Document objects can be visible across origins per spec, but none of their properties ever are. For what it's worth, that doesn't appear to be necessary for web compatibility. Any time WebKit would return a Document to a script in another origin, WebKit returns null instead. Adam
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Wed, Jan 9, 2013 at 2:18 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/9/13 4:33 PM, Adam Barth wrote: For what it's worth, that doesn't appear to be necessary for web compatibility. Any time WebKit would return a Document to a script in another origin, WebKit returns null instead. The HTML spec requires that property access on documents use effective script origin for checks. Effective script origins are mutable. It is in fact possible to get your hands on a document in a different effective script origin in WebKit (thanks, document.domain). Those checks are neither required for compatibility nor security. The spec might say to perform the checks, but they aren't needed to build a secure, compatible browser. Adam
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Wed, Jan 9, 2013 at 2:24 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/9/13 5:19 PM, Adam Barth wrote: Those checks are neither required for compatibility nor security. The spec might say to perform the checks, but they aren't needed to build a secure, compatible browser. OK. So what checks do you believe are required, then? Just effective script origin checks on Window? I would really appreciate it if you would actually describe the security model you think the spec should have instead of us having to guess what parts you think are needed and which parts you think are not needed, with more gotchas and details all the time. Answering this question in detail would take a great deal of time. I can try to summarize how WebKit handles this issues. In general WebKit tries to follow the spec's approach to these security checks, although there are some difference for historical reasons (e.g., not throwing exceptions, exposing or not exposing certain properties across origins). Generally speaking, I'd recommend exposing as few things across origins as possible. For example, I view WebKit's not exposing Document across origins as better than the spec's exposing it, whereas I view WebKit's exposing window.history across origins as worse than the spec's not exposing it. IMHO, we should aim for exposing the minimal set of things across origins. To gather this information, I grepped the WebKit IDL files for CheckSecurity. Here's what I learned: 1) By default, DOMWindow (which might translate into Window or WindowProxy in the spec---I'd need to study that issue more carefully) needs to perform access checks. There are a number of properties that are white listed, similar to what's described in the spec (cross-origin readers get fresh copies of the underlying interfaces regardless of any changes made to the DOMWindow in JavaScript and these fresh copies have prototype chains that connect up with the *caller's* JavaScript prototypes, not the DOMWindow's JavaScript prototypes). 2) window.history, window.location, window.focus, window.blur, window.close, window.closed, window.length, window.window, window.frames, window.opener, window.parent, window.top, window.postMessage, and window.toString are whitelisted to be exposed across origins (often just the getters, not the setters). There's some additional complexity related to the names of nested browsing context and the indexed property getter, but I believe the description in the current spec is accurate. 3) The History interfaces works much like the DOMWindow interface (properties are blocked by default and certain whitelisted properties are visible across origins on the same fresh, pristine basis as the properties on DOMWindow). 4) history.back, history.forward, and history.go are whitelisted. 5) The Location interface works much like DOMWindow and History, but the only whitelisted property is the location.href setter. 6) In addition, the following APIs have extra security checks. All these APIs return a Node. Before returning the Node, they check whether the Node's document's origin is the same origin as the script calling the API. If not, they return null instead of the node. (We could potentially throw an exception here, but I'm just describing what WebKit does, not what I think the optimum design is.) A) HTMLEmbedObject#getSVGDocument() B) HTMLFrameElement#contentDocument C) HTMLFrameElement#getSVGDocument() D) HTMLIFrameElement#contentDocument E) HTMLIFrameElement#getSVGDocument() F) HTMLObjectElement#contentDocument G) HTMLObjectElement#getSVGDocument() H) DOMWindow#frameElement With regards to your original question about using Function.prototype.call to manipulate the this value passed to function, I don't remember the details of how we dealt with that issue. I'd have to write some careful test cases to study WebKit's behavior to give you a definitive answer. We might have either ignored the this value entirely (and always operated on the object that held the property originally) or we might have insisted on always checking whether the calling script was same-origin with the this parameter for the three interfaces (DOMWindow, Location, and History) where the caller could possibly have a reference to a cross-origin object to pass as this. In addition to everything described above, there are some additional security issues related to operator eval and function eval, but I've left them out here because they're not relevant for the HTML spec. I should also say that it's entirely possible we've screwed up our implementation of this security model. If you discover that we have, I'd prefer if you filed a security bug rather than telling the world on this public mailing list. :) Adam
Re: [whatwg] Location object identity and navigation behavior
On Mon, Jan 7, 2013 at 11:17 PM, Bobby Holley bobbyhol...@gmail.com wrote: On Mon, Jan 7, 2013 at 8:05 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 7 Jan 2013, Bobby Holley wrote: Aside from concerns about stack introspection, the main downside of this approach is that it's a blacklist, rather than a whitelist (like our other security code), so we'll have to be extra careful when implementing anything new on Location. Please keep that in mind when updating the spec. ;-) Can you elaborate on what is a blacklist? In the sense that we have to implement it as explicit per-method checks in C++. Our regular security model is an object-capability system enforced with wrappers across scope boundaries (using a whitelist), which, as previously discussed, doesn't jive with the current spec for Location. So if something new is ever added to nsLocation, we're going to need to remember to add a security check. The way we handle this in WebKit is with an IDL attribute [CheckDomainSecurity] on the interface that instructs the code generator to generate these security checks for each method automatically. Individual methods can be whitelisted using the IDL attribute [DoNotCheckDomainSecurity]. That's all much easier than implementing a secure JavaScript wrapper. (I understand that some existing Mozilla-proprietary features require you to spend the engineering effort to build secure JavaScript wrappers, but nothing in the web platform requires other browser engines to make that investment.) Adam
Re: [whatwg] Proposal: Loading and executing script as quickly as possible using multipart/mixed
On Mon, Dec 10, 2012 at 11:52 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 3, 2012, at 11:19 PM, Adam Barth w...@adambarth.com wrote: On Mon, Dec 3, 2012 at 9:57 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 3, 2012, at 2:11 PM, William Chan (陈智昌) willc...@chromium.org wrote: Unless I am misunderstanding, SPDY will not solve this problem. SPDY uses prioritized multiplexing of streams. It seems to me like SPDY could make this case work better: script async src=path/to/script-part1.js/script script async src=path/to/script-part2.js/script script async src=path/to/script-part3.js/script Specifically the individual script chunks could be ordered and prioritized such that all of script-part1.js transfers before any of script-part3.js. That's harder to do with HTTP because the scripts could be loading on wholly separate HTTP connections, while SPDY will use one connection to the server. That being said, I do not know if SPDY will actually achieve this. Presumably it makes sense for it to serialize within a given priority level, at least a priority level that's likely to correspond to resources that are only atomically consumable, like scripts. But I don't know if SPDY implementations really do that. It also has disadvantage (3): ---8--- (3) This approach requires the author who loads the script to use different syntax than normally used for loading script. For example, this prevents this technique from being applied to the JavaScript libraries that Google hosts (as described by https://developers.google.com/speed/libraries/). ---8--- Yes, but I presumed that multiple script tags is less deviation than the iframe approach. Perhaps that is not the case. Note that in the case of systematically named parts, a single inline script could document.write() the relevant sequence of external script tags, if verbosity is the concern. But it would indeed be different. Do you expect the multipart idea would work with no syntax change in the markup currently embedding the libraries? If so, how? Content negotiation? UA sniffing? Yes, using UA sniffing at first and eventually dropping support for old clients. Adam
Re: [whatwg] Script-related feedback
On Wed, Dec 19, 2012 at 2:27 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 3 Dec 2012, Adam Barth wrote: Currently, there are a number of ways to load a script from the network and execute it, but none of them will actually load and execute the script as fast as physically possible. Consider the following markup: script async src=path/to/script.js/script In this case, the user agent will wait until it receives the last byte of script.js from the network before executing the first byte of script.js. It had better, since JavaScript requires that syntax errors in the lasy byte prevent execution of the first byte. The main ingredient that we're missing is a way for the author to signal to the user agent which chunks of scripts are safe to execute in parallel with loading subsequent chunks from the network. Fortunately, the web platform already has a mechanism for breaking a single HTTP response body into chunks that are processed sequentially: multipart/mixed. For example, if an HTTP server provides a multipart/mixed response to a request for an image, the img element will display each part of the response in sequence, animating the image. Similarly, if an HTTP server provides a multipart/mixed response to a request for an HTML document, the user agent will display each part of the response sequentially. One way to address this use case is to add multipart/mixed support to the script element. Upon receiving a multipart/mixed response to a request for a script, the script element must execute each part of the response as they become available. This behavior appears to be consistent with the definition of multipart/mixed http://tools.ietf.org/html/rfc2046#section-5.1.3. To load and execute a script as quickly as possible, the author would use the following markup: script async src=path/to/script.js/script The HTTP server would then break script.js into chunks that are safe to execute sequentially and provide each chunk as a separate MIME part in a multipart/mixed response. This seems like an overly complicated way of solving this problem. Why not just introduce a keyword or pragma to JavaScript that tells the user agent to act as if the end of the Program production had been reached, and that it should treat the remainder of the file as another Program? This could even be done in a backwards-compatible fashion by having the syntax to do this be something that down-level clients ignore, e.g.: /*@BREAK*/ ...or some such. That approach is an in-band signal, which means it's vulnerable to injection attacks. For example, consider a server that produces a JavaScript file of the following form: [...] var userData = ?php echo santize($userData) ?; [...] Currently, the rules for sanitizing using input are relatively straightforward (essentially, you just need to worry about a few special characters). However, if we implemented an in-band signaling we might well break these sanitation algorithms. To make this secure, we'd probably want some sort of randomized delimiter (perhaps declared via a pragma at the top of the file), but then we would have just re-invented multipart/mixed. Adam
Re: [whatwg] [mimesniff] Sniffing archives
On Mon, Dec 3, 2012 at 11:59 PM, Julian Reschke julian.resc...@gmx.de wrote: On 2012-12-04 08:40, Adam Barth wrote: On Mon, Dec 3, 2012 at 12:39 PM, Julian Reschke julian.resc...@gmx.de wrote: On 2012-11-29 20:25, Adam Barth wrote: These are supported in Chrome. That's what causes the download. From Can you elaborate about what you mean by supported? Chrome sniffs for the type, and then offers to download as a result of that sniffing? How is that different from not sniffing in the first place? They might otherwise be treated as a type that can be displayed (rather than downloaded). Also, some user agents treat downloads of Do you have an example for that case? ZIP archives differently than other sorts of download (e.g., they might offer to unzip them). Out of curiosity: which? Safari. Adam
Re: [whatwg] Making cross-origin iframe seamless= (partly) usable
On Fri, Nov 30, 2012 at 6:57 PM, Ian Hickson i...@hixie.ch wrote: On Sat, 26 May 2012, Adam Barth wrote: [CSP] CSP doesn't seem to include any features that would let you limit who is allowed to iframe you, so I don't think CSP as designed today provides a solution for the per-origin part. Could it be extended? The current plan is for X-Frame-Options to become a CSP directive. CSP is quite extensible. The only hard restrictions are that new directives conform to this grammar (yes, error handling for parsing is also defined): directive = *WSP [ directive-name [ WSP directive-value ] ] directive-name= 1*( ALPHA / DIGIT / - ) directive-value = *( WSP / VCHAR except ; and , ) Philosophically, the current plan is to use CSP for things that might be called content restrictions, i.e., for restricting what a document might otherwise be able to do. As I wrote on the wiki [1], it's not a great match for this use case because here we're loosening restrictions rather than tightening them. Of course, this philosophy might evolve over time, so I wouldn't necessarily treat it as a hard-and-fast rule. [X-Frame-Options] This doesn't let you chose on a per-origin basis whether you can be framed either (since you don't get an Origin header in the request, and the X-F-O header only gives a thumbs-up or thumbs-down in general). I'm dubious about extending X-F-O since it lacks a spec and so how exactly to change it in a backwards-compatible way is unclear and getting it wrong would be very dodgy. On Thu, 12 Apr 2012, Ojan Vafai wrote: we could add a special http header and/or meta tag for this, like x-frame-options, but for the child frame to define it's relationship to the parent frame. Yeah. It seems to me like the best solution is to have a new HTTP header, with the four following values being allowed: Seamless-Options: allow-shrink-wrap Seamless-Options: allow-styling Seamless-Options: allow-shrink-wrap allow-styling Seamless-Options: allow-styling allow-shrink-wrap (Split on spaces, ignore unknown tokens.) Assuming that these are order independent, it's slightly more idiomatic for HTTP to use , as a delimiter. Then for the per-origin control, we would extend CSP to have a flag for limiting who is allowed to embed you (subsuming X-Frame-Options, essentially). That's already planned for CSP (e.g., http://dvcs.w3.org/hg/user-interface-safety/raw-file/tip/user-interface-safety.html#frame-options is one current proposal). For the case of things that can be embedded by anyone but only seamlessly by paying clients, I would recommend putting the origin in the URL, and then limiting the embedding to that URL using CSP. Is this a viable direction? Yeah, I can see how you ended up with an HTTP header. I wonder if it would make sense to align this stylistically with CORS. For example: Access-Control: allow-shrink-wrap, allow-styling I guess it depends how costly you think it is to mint new HTTP headers rather than having fewer, harder working headers. Adam [1] http://wiki.whatwg.org/wiki/AllowSeamless
[whatwg] Proposal: Loading and executing script as quickly as possible using multipart/mixed
== Use case == Load and execute script as quickly as possible. == Discussion == Currently, there are a number of ways to load a script from the network and execute it, but none of them will actually load and execute the script as fast as physically possible. Consider the following markup: script async src=path/to/script.js/script In this case, the user agent will wait until it receives the last byte of script.js from the network before executing the first byte of script.js. In principle, the user agent could finish executing script.js sooner if it could overlap some of the execution time with some of the network latency, for example by executing a chunk of the script while waiting for the bytes for the next chunk to arrive from the network. Unfortunately, without additional information, the user agent doesn't know where safe chunk boundaries are located. Picking an arbitrary byte boundary is likely to cause a syntax error, and even picking an arbitrary JavaScript statement boundary will change the semantics of the script. The user agent needs some sort of signal from the author to know where the safe chunk boundaries are located. == Workarounds == The simplest work around is to break your script into several pieces: script async src=path/to/script-part1.js/script script async src=path/to/script-part2.js/script script async src=path/to/script-part3.js/script Now, script-part1.js will execute before the user agent has received the last byte of script-part3.js. Unfortunately, this approach does not make efficient use of the network. Specifically, if the three parts are retrieved from the network in parallel, then the user agent might receive a byte from script-part3.js before receiving all the bytes of script-part1.js, wasting network bandwidth (because the bytes from script-part3.js are not useful until all of script-part1.js is received an executed). A more sophisticated workaround is to use an iframe element rather than a script element to load the script: iframe src=path/to/script-in-markup.html/iframe In this approach, script-in-markup.html is the following HTML: script [... text of script-part1.js ...] /script script [... text of script-part2.js ...] /script script [... text of script-part3.js ...] /script Now the bytes of the script are retrieved from the network in the proper order (making efficient use of bandwidth) and the user agent can overlap execution of the script with network latency (because the script tags delineate the safe chunks). This approach is used in production web applications, including Gmail, to load and execute script as quickly as possible. If you inspect a running copy of Gmail, you can find this frame---it's the one with ID js_frame. Unfortunately, this approach as a number of disadvantages: (1) Creating an extra iframe for loading JavaScript is not resource efficient. The user agent needs to create a number of extra data structures and an extra JavaScript environment, which wastes time as well as memory. (2) Authors need to write their scripts with the understanding that the primary callers of their code will do so from another frame. For example, the instanceof operator might not work as expected if they ask whether an object from the caller (i.e., from the parent frame) is an instance of a constructor from the callee's environment (i.e., from the child frame). (3) This approach requires the author who loads the script to use different syntax than normally used for loading script. For example, this prevents this technique from being applied to the JavaScript libraries that Google hosts (as described by https://developers.google.com/speed/libraries/). == Proposal == The script element should support multipart/mixed. == Details === The main ingredient that we're missing is a way for the author to signal to the user agent which chunks of scripts are safe to execute in parallel with loading subsequent chunks from the network. Fortunately, the web platform already has a mechanism for breaking a single HTTP response body into chunks that are processed sequentially: multipart/mixed. For example, if an HTTP server provides a multipart/mixed response to a request for an image, the img element will display each part of the response in sequence, animating the image. Similarly, if an HTTP server provides a multipart/mixed response to a request for an HTML document, the user agent will display each part of the response sequentially. One way to address this use case is to add multipart/mixed support to the script element. Upon receiving a multipart/mixed response to a request for a script, the script element must execute each part of the response as they become available. This behavior appears to be consistent with the definition of multipart/mixed http://tools.ietf.org/html/rfc2046#section-5.1.3. To load and execute a script as quickly as possible, the author would use the following markup: script async src=path/to/script.js/script The HTTP
Re: [whatwg] Loading and executing script as quickly as possible using multipart/mixed
On Mon, Dec 3, 2012 at 6:15 PM, Kyle Simpson get...@gmail.com wrote: Adam- To load and execute a script as quickly as possible, the author would use the following markup: script async src=path/to/script.js/script The HTTP server would then break script.js into chunks that are safe to execute sequentially and provide each chunk as a separate MIME part in a multipart/mixed response. I like the spirit of this idea, but one concern I have is about the script load and readystate events. It seems that authors will want to know when each chunk has finished executing (in the same way they want to know that scripts themselves finish). Sure, you could imagine firing progress events or other sorts of events before or after each chunk executes. Adam
Re: [whatwg] Proposal: Loading and executing script as quickly as possible using multipart/mixed
On Mon, Dec 3, 2012 at 9:57 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 3, 2012, at 2:11 PM, William Chan (陈智昌) willc...@chromium.org wrote: Unless I am misunderstanding, SPDY will not solve this problem. SPDY uses prioritized multiplexing of streams. It seems to me like SPDY could make this case work better: script async src=path/to/script-part1.js/script script async src=path/to/script-part2.js/script script async src=path/to/script-part3.js/script Specifically the individual script chunks could be ordered and prioritized such that all of script-part1.js transfers before any of script-part3.js. That's harder to do with HTTP because the scripts could be loading on wholly separate HTTP connections, while SPDY will use one connection to the server. That being said, I do not know if SPDY will actually achieve this. Presumably it makes sense for it to serialize within a given priority level, at least a priority level that's likely to correspond to resources that are only atomically consumable, like scripts. But I don't know if SPDY implementations really do that. It also has disadvantage (3): ---8--- (3) This approach requires the author who loads the script to use different syntax than normally used for loading script. For example, this prevents this technique from being applied to the JavaScript libraries that Google hosts (as described by https://developers.google.com/speed/libraries/). ---8--- Adam Generally speaking, a browser will map a single resource request to a single stream, which would prevent chunked processing by the browser without multipart/mixed. One could imagine working around this by splitting the single resource into multiple resources, and then relying on SPDY priorities to ensure sequential delivery, but that is suboptimal due to having limited priority levels (4 in SPDY/2, 8 in SPDY/3), and many of them are already used to indicate relative priority amongst resource types ( https://code.google.com/p/chromium/source/search?q=DetermineRequestPriorityorigq=DetermineRequestPrioritybtnG=Search+Trunk ). On Mon, Dec 3, 2012 at 1:40 PM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Dec 3, 2012 at 10:14 PM, Adam Barth w...@adambarth.com wrote: The HTTP server would then break script.js into chunks that are safe to execute sequentially and provide each chunk as a separate MIME part in a multipart/mixed response. Is it expected that SPDY will take much longer than getting this supported in all browsers? Or am I missing how SPDY will not address this problem? -- http://annevankesteren.nl/
Re: [whatwg] [mimesniff] Sniffing archives
On Mon, Dec 3, 2012 at 12:39 PM, Julian Reschke julian.resc...@gmx.de wrote: On 2012-11-29 20:25, Adam Barth wrote: These are supported in Chrome. That's what causes the download. From Can you elaborate about what you mean by supported? Chrome sniffs for the type, and then offers to download as a result of that sniffing? How is that different from not sniffing in the first place? They might otherwise be treated as a type that can be displayed (rather than downloaded). Also, some user agents treat downloads of ZIP archives differently than other sorts of download (e.g., they might offer to unzip them). Adam
Re: [whatwg] Adding crossorigin= to more elements
On Thu, Nov 29, 2012 at 6:44 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 29 Nov 2012, Boris Zbarsky wrote: Anyway, this is somewhat moot to me because it'll all have to be defined by whatever spec it is that currently says that a CSS sheet on http: can't import an image on file:, etc. Heh. Does it affect things like CSP in any way? No idea. Adam? I'm not sure I have all the context for this question, but generally CORS and CSP don't really interact with each other. If something is blocked by CSP, the user agent never gets to the point where it wonders about CORS. Adam
Re: [whatwg] [mimesniff] Treating application/octet-stream as unknown for sniffing
On Wed, Nov 28, 2012 at 10:30 PM, Gordon P. Hemsley gphems...@gmail.com wrote: Based on my reading of the source code, it seems that Gecko treats a resource served as 'application/octet-stream' as an unknown type which is sniffed as if no Content-Type was specified. Are there security implications with doing this? Yes, there are very large security consequences. I'm sorry that I don't have time to respond to all of these threads in detail, but I'm worried that you don't understand the consequences of the changes you're proposing to this specification. I'm not sure how to help you succeed here, but tweaking things in the spec without a compelling reason for doing so is not likely to lead to a useful specification. I spent a great deal of time and effort studying the behaviors of many user agents and of a massive amount of content on the web. I'm certainly willing to believe that the spec can be improved, but if you don't understand these sorts of basic things about content sniffing, I worry that changes that you make to the spec won't be improvements. Adam
Re: [whatwg] [mimesniff] Sniffing archives
These are supported in Chrome. That's what causes the download. From your comment, it's not clear to me if you are correctly reverse engineering existing user agents. The techniques we used to create this list originally are quite sophisticated and involved a massive amount of data [1]. It would be a shame if you destroyed that work because you didn't understand it. Adam [1] http://www.adambarth.com/papers/2009/barth-caballero-song.pdf On Thu, Nov 29, 2012 at 10:42 AM, Gordon P. Hemsley gphems...@gmail.com wrote: To be clear, I'm asking this because I would like to remove the sniffing of archive types from the mimesniff spec if there aren't any valid usecases. On Wed, Nov 28, 2012 at 12:18 PM, Gordon P. Hemsley gphems...@gmail.com wrote: The mimesniff spec currently includes signatures for ZIP, gzip, and RAR archive formats. However, no major browser seems to support them natively (they all prompt for download), and it's not clear whether the type detection is a product of the browser code or the OS, or whether it is used beyond choosing an appropriate file extension for the download. Are there any valid usecases for explicitly sniffing archive formats instead of letting them default to application/octet-stream like other binary files would? Note that Henri Sivonen has previously raised the issue that ZIP-based formats (like office suite documents), for example, would be misleadingly sniffed as ZIP files, and there is no easy way around that. -- Gordon P. Hemsley m...@gphemsley.org http://gphemsley.org/ • http://gphemsley.org/blog/ -- Gordon P. Hemsley m...@gphemsley.org http://gphemsley.org/ • http://gphemsley.org/blog/
Re: [whatwg] Support of link rel=prefetch
I consider it not working on Chrome for Android a bug. It's something we'd like to fix. Adam On Tue, Nov 27, 2012 at 10:52 AM, Laurent Perez l.lauren...@gmail.com wrote: Hi I'm testing the prefetch attribute of link tags described at http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-prefetch I've only seen it work on Firefox desktop and mobile, on Chrome desktop, and on Android 4.0 stock browser. Mobile Safari, Opera, IE10 or Chrome for Android do not support it. Has this feature been abandoned because of lack of vendors interest ? laurent http://laurentperez.fr J2EE tips and best practices
Re: [whatwg] [mimesniff] Handling container formats like Ogg
I included H.264 sniffing in the spec because some implementors specifically asked for it (and it wasn't all that complicated). For Ogg, I'd wait until implementors ask you to include it. Adam On Mon, Nov 26, 2012 at 2:59 PM, Gordon P. Hemsley gphems...@gmail.com wrote: Container formats like Ogg can be used to store many different audio and video formats, all of which can be identified generically as application/ogg. Determining which individual format to use (which can be identified interchangeably as the slightly-less-generic audio/ogg or video/ogg, or using a 'codecs' parameter, or using a dedicated media type) is much more complex, because they all use the same OggS signature. It would requiring actually attempting to parse the Ogg container to determine which audio or video format it is using (perhaps not unsimilar to what is done for MP4 video and what might have to be done with MP3 files without ID3 tags). Would this be something UAs would prefer to handle in their Ogg library, or should I spec it as part of sniffing? -- Gordon P. Hemsley m...@gphemsley.org http://gphemsley.org/ • http://gphemsley.org/blog/
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Fri, Nov 23, 2012 at 3:04 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 12 Nov 2012, Justin Novosad wrote: For many types of apps, DOM-based rendering is uncompetitively slow [so we should make text rendering in canvas more controllable] This seems like something we should fix, not something we should work around by having people use canvas instead. Using canvas has all kinds of terrible side-effects, like reducing the likely accessibility of the page, making searcheability much worse, etc. Also, do you have any metrics showing the magnitude of this problem on real-world sites that might consider using canvas instead? The metrics I've seen show that the magnitude of this problem is approximately 8x (to the extent that it's sensible to represent the magnitude with a number). As far as I can tell, the issue really boils down to the DOM being retained mode and canvas being immediate mode. As the size of the underlying model grows, uploading the entire model into the DOM becomes increasingly uncompetitive with having the application manage the model and drawing using immediate mode because the application can use application-specific knowledge to avoid having to process large portions of the model. I'm unsure what details I'm able to share about these experiments. Justin might know better what we're able to share, but the outcomes are roughly: 1) Uploading the entire document model into DOM (say for a model that requires 1 million elements to represent) causes the application to become completely unusable. Memory consumption goes off the charts, hit testing noticeably lags, etc. We've been working to improve performance here, but there are limits to what we'll be able to achieve. For example, DOM is always going to be a less memory efficient than an application-specific representation. On some rendering benchmarks, a variety of browsers are able to render these models at about 8 fps. 2) Remarkably, the current best candidate is a rendering pipeline that attempts to use the DOM in immediate mode. The application performs some application-specific processing to determine which portions of the model can actually affect what's drawn on screen, and then the application uses innerHTML to create DOM for that portion of the model. (They've experimented with a bunch of choices and innerHTML appears to be the fastest way to use the DOM as an immediate mode API.) Using this pipeline, the application uses reasonable amounts of memory and hit testing, etc, aren't impacted. This pipeline gets about 20 fps. 3) Once they've moved from (1) to (2), you can understand why the next logical step is to use a real immediate mode API, like canvas or WebGL. Approach (2) is totally nutty: there's no way the right design is to build up a giant string of markup and then run it through the parser for every frame. Using canvas, the application has no trouble achieving 60 fps. I think the real question here is how do we want applications with very large models to render? Do we really want them to upload their entire models into DOM? If not, how can we provide them with a high-quality immediate model rendering pipeline. Adam
Re: [whatwg] [mimesniff] The X-Content-Type-Options header
On Mon, Nov 19, 2012 at 10:17 AM, Julian Reschke julian.resc...@gmx.de wrote: On 2012-11-17 19:17, Adam Barth wrote: ... I would prefer if the spec described what implementations actually do rather than your opinion about what they should do. To answer your specific questions: ... That works well if something is widely supported already. It works less well if you have one initial and one incomplete implementation only. Which implementation is initial and which is incomplete? AFAIK, both IE and Chromium consider their implementation of this feature done. 1) Don't bother dropping the X-. Everyone who implements this feature uses the X- and dropping it is just going to cause unnecessary interoperability problems. There's no *need* to drop it, but if research on this topic leads to the conclusion that the functionality is needed, but the current X- prototype isn't sufficient anyway it might be worth considering. Currently, I don't see a use case for dropping the X- prefix. Perhaps there's one I don't understand? Adam
Re: [whatwg] [mimesniff] The X-Content-Type-Options header
On Mon, Nov 19, 2012 at 10:41 AM, Julian Reschke julian.resc...@gmx.de wrote: On 2012-11-19 19:27, Adam Barth wrote: On Mon, Nov 19, 2012 at 10:17 AM, Julian Reschke julian.resc...@gmx.de wrote: On 2012-11-17 19:17, Adam Barth wrote: ... I would prefer if the spec described what implementations actually do rather than your opinion about what they should do. To answer your specific questions: ... That works well if something is widely supported already. It works less well if you have one initial and one incomplete implementation only. Which implementation is initial and which is incomplete? AFAIK, both IE and Chromium consider their implementation of this feature done. initial - the one done first, and by the vendor that invented the functionality incomplete - the one that copies one part and not the other part of he behavior of the initial implementation I can't speak for the IE team, but I can tell you that I don't view the Chromium implementation as either initial or incomplete. 1) Don't bother dropping the X-. Everyone who implements this feature uses the X- and dropping it is just going to cause unnecessary interoperability problems. There's no *need* to drop it, but if research on this topic leads to the conclusion that the functionality is needed, but the current X- prototype isn't sufficient anyway it might be worth considering. Currently, I don't see a use case for dropping the X- prefix. Perhaps there's one I don't understand? A use case for *renaming* (which might be more than dropping the prefix) actually would be saving bytes on the wire. Another one would be to make it possible to make incompatible changes to the field value syntax, when needed. I don't have any interest in making any incompatible changes to this feature in Chromium at this time. Adam
Re: [whatwg] [URL] DOM API Feedback
On Wed, Nov 14, 2012 at 10:54 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Nov 8, 2012 at 5:58 PM, Adam Barth w...@adambarth.com wrote:
On Thu, Nov 8, 2012 at 6:22 AM, Alex Russell slightly...@google.com wrote:
- username and password properties are missing
- There aren't any provided comparison functions. I.e., there's no way
to tell if two URL objects reference the same absolute URL, if
one references a path in the same domain, etc.
The notion of the same absolute URL is a bit slippery. It depends
on how well you understand various URL components (e.g., octal
encodings of IP addesss). We could define something, of course, but
we'd just need to do so carefully.
Yeah, it would be useful to have some use cases and examples here to
work from. E.g. I suspect we may want to have a method at some point
that considers these equal:
http://x/?testtest2
http://x/?test2test
even though they would always be considered strictly distinct
currently (and some servers reportedly rely on this distinction).
Yes, the http://url.spec.whatwg.org/#urlquery interface lets you get
at parsed URL parameters. I don't think there's currently a way to
turn them into form data objects, but that would make sense.
We might also want to add a bulk setter that takes a Dictionary.
Concrete suggestions for URLQuery are very much welcome. For behavior too.
get()/getAll() are clear.
set() not so much:
?xyx=5y
set(x,1)
what happens? Or with set(x, [1,2])? And set(x, [1,2,3]? Idea:
?x=1yy
?x=1yx=2y
?x=1yx=2yx3
So set() replaces values in order, removes parameters for which no
values are set, and adds parameters if there are no existing
parameters.
I think that calls for add() as well, which simply appends a
parameter, irrespective of what is there now.
Having multiple parameters with the same name seems like a bit of an
edge case to me. I wonder if we can get a better API by treating it
as an edge case? Here's a proposal:
add(foo, bar) --- Appends a parameter foo=bar to the existing
query string (even if there's already a parameter foo earlier.)
set({
foo: bar,
qux: baz
}) --- Blows away the existing query string and replaces it with
foo=barqux=baz.
In this approach, set() doesn't support having multiple parameters
with the same name. If you need that, you need to use add().
Adam
Allowing new FormData(URLQuery) makes sense to me.
That's covered in step 1 of
http://url.spec.whatwg.org/#constructors. If there's no explicit
base, the URL is resolved relative to about:blank. To me, that seems
better that implicitly using the document's base URL. You can always
supply the document's base URL from document.baseURI if you want.
Yeah, that was my thinking too.
--
http://annevankesteren.nl/
Re: [whatwg] Location object identity and navigation behavior
On Thu, Nov 8, 2012 at 10:21 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/8/12 6:09 PM, Adam Barth wrote: I don't think I quite understand what you mean, but the way this works in WebKit is that each Window object has its own Location object. That's not how it works in Presto and Trident, as far as we can tell based on testing with ==. In those, each WindowProxy has its own Location object. The location object operates on the current Window for the WindowProxy. Yes. _That_ all browsers are consistent on, and is totally not what the spec says right now. In the spec, there is one Location per Window, and the object operates on the Window it's associated with. The fact that this does not match any browsers is what makes us suspect the spec is not web-compatible. In WebKit at least, it would be a security vulnerability to expose JavaScript objects that belong to Document B to Document A because that would give Document A access to the prototype objects for Document B. You presumably have a solution for this situation for the WindowProxy case, right? Certainly Gecko does, and we would be using the same solution for Location if we tie the lifetime of a Location to the lifetime of a WindowProxy. The WindowProxy is a special, magical object because references to it magically change which JavaScript object they refer to over time. If possible, I would like to avoid infecting other objects with its magic. Adam
Re: [whatwg] Location object identity and navigation behavior
On Fri, Nov 9, 2012 at 12:06 PM, Bobby Holley bobbyhol...@gmail.com wrote:
On Fri, Nov 9, 2012 at 11:33 AM, Adam Barth w...@adambarth.com wrote:
That was my opinion for a while, too, but I eventually decided it was
necessary in Gecko.
Can you explain why you think it is necessary? In WebKit, the
WindowProxy is the only object that has this magic.
As noted, the Location object is the only object whose security
characteristics don't match its scope. This requires a lot of extra goop in
our compartment-based security model, and the goop is brittle (recently
forcing us to release two out-of-band updates, 16.0.1 and 16.0.2). We've got
enough belt-and-suspenders code now that I'm not particularly worried, but I
still want to make Location just like any other object from a security
perspective.
If UAs were consistent or the spec matched reality, this would be a
different story. But given that we probably need to change the spec to
either the Trident/Presto model or the Gecko/WebKit model, I support the
former, because we've historically had problems implementing the latter
securely. Do you feel that it would be difficult to implement the former
securely in WebKit?
That depends on the questions I asked earlier.
Also, FWIW, from the perspective of an average web-developer, IMO it makes
much more semantic sense to have one Location per WindowProxy if the
Location object describes the WindowProxy. But I doubt many people touch
this stuff in practice.
I don't think the average web developer will hit this case because it
depends on interacting with the Location object in an inactive
document.
We don't want to move objects between scopes. That causes many
security complications that we don't want to deal with.
Are you able to just update references, like you do with WindowProxy?
That's the magic I don't want to proliferate.
That's
essentially what we're doing. We actually create a new object in the new
scope and update all the old references to point to it.
Can you answer the questions in my previous email?
Which ones? AFAICT Boris answered all of them except for the testcase thing
(which I answered). Did I miss some?
Maybe I didn't receive your email. I gave some example code and asked
which values were printed:
---8---
Consider the following case:
== Document A ==
script
Object.prototype.foo = A1;
window.location.bar = A2;
function f() {
var loc = window.location;
print(loc.foo); // print is a magic function that lets me see this value
print(loc.bar);
}
/script
== Document B ==
script
Object.prototype.foo = B1;
window.location.bar = B2;
/script
1) Document A is displayed in browsing context X.
2) Browsing context X is navigated and now displays document B.
3) Function f is called.
What values are printed?
---8---
Adam
Re: [whatwg] Location object identity and navigation behavior
On Fri, Nov 9, 2012 at 9:43 AM, Bobby Holley bobbyhol...@gmail.com wrote: On Fri, Nov 9, 2012 at 9:30 AM, Adam Barth w...@adambarth.com wrote: On Thu, Nov 8, 2012 at 10:21 PM, Boris Zbarsky bzbar...@mit.edu wrote: You presumably have a solution for this situation for the WindowProxy case, right? Certainly Gecko does, and we would be using the same solution for Location if we tie the lifetime of a Location to the lifetime of a WindowProxy. The WindowProxy is a special, magical object because references to it magically change which JavaScript object they refer to over time. If possible, I would like to avoid infecting other objects with its magic. That was my opinion for a while, too, but I eventually decided it was necessary in Gecko. Can you explain why you think it is necessary? In WebKit, the WindowProxy is the only object that has this magic. Right now, the Location object is the only object whose security characteristics are not guaranteed to match its global, which is a major pain point for us. I think the current spec language would be the most ideal approach, but as noted I doubt it'll fly on the web. FWIW, this turned out to be much simpler to implement than I thought. We've already worked out where we need to put the logic to make WindowProxy update appropriately, and we already had code to move objects like Location between scopes (which we needed to do for document.write). I'd imagine WebKit has the former, though I'm not sure about the latter. We don't want to move objects between scopes. That causes many security complications that we don't want to deal with. Can you answer the questions in my previous email? Adam
Re: [whatwg] Location object identity and navigation behavior
On Fri, Nov 9, 2012 at 12:26 PM, Bobby Holley bobbyhol...@gmail.com wrote: On Fri, Nov 9, 2012 at 12:17 PM, Adam Barth w...@adambarth.com wrote: I don't think the average web developer will hit this case because it depends on interacting with the Location object in an inactive document. Agreed. Maybe I didn't receive your email. Here's a link to it in the archives: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-November/037850.html Thanks for the link. Somehow the message got routed to spam. It's possible we could implement that in WebKit, but the implementation would be very delicate. We currently implement similar security checks for Location because Location is visible across origins. The main difficulty would be implementing the WindowProxy-like re-writing of existing references. I understand that implementing that behavior in Gecko is much easier than in WebKit because Gecko makes extensive use of JavaScript wrapper objects. We have avoided introducing similar wrapper objects in WebKit because they're quite subtle and can lead to security vulnerabilities if used incorrectly. I don't fully understand why the current behavior is fragile in Gecko. The approach we use in WebKit is quite simple---we just perform an access check before doing any sensitive operations. This access check is required in any case because the underlying Location object is visible across origins. I guess the issue must be that Gecko performs the access check based on some property of the JavaScript object. In WebKit, we simply perform the access check based on the operation we're actually about to perform, irrespective of what API was used to trigger the action. Adam
Re: [whatwg] [URL] DOM API Feedback
On Thu, Nov 8, 2012 at 6:22 AM, Alex Russell slightly...@google.com wrote: Howdy all, Anne asked me to send feedback on the DOM API for the new URL spec ( http://url.spec.whatwg.org/#api) to this list. Here goes: First, I love that this looks sane, like what you need most of the time, and will plumb through to the browser's parsing algorithm without requiring me to re-write this sort of thing (badly) every time I need it. +1 for adding a good DOM API! Next, nicely done on having a meaningful constructor! I do wonder if the url parameter should be optional as well as the base, since you may either want to build a URL using a URL object (to be serialized later). Looking at what URL/URLUtils provides, I noted a couple of things I'd like to see that I miss from google-urlhttp://code.google.com/p/google-url/source/browse/trunk/src/gurl.h(a.k.a. GURL, the URL library we use in Chrome): - GetWithEmptyPath() GetOrigin() (despite their terrible C++ naming) are hugely useful for doing comparisons. I could imagine that there's some http://url.spec.whatwg.org/#dom-url-origin is the equivalent to GURL's GetOrigin(). - username and password properties are missing - There aren't any provided comparison functions. I.e., there's no way to tell if two URL objects reference the same absolute URL, if one references a path in the same domain, etc. The notion of the same absolute URL is a bit slippery. It depends on how well you understand various URL components (e.g., octal encodings of IP addesss). We could define something, of course, but we'd just need to do so carefully. - Is there any attempt to parse query parameters and/or return a form data object from them? Yes, the http://url.spec.whatwg.org/#urlquery interface lets you get at parsed URL parameters. I don't think there's currently a way to turn them into form data objects, but that would make sense. We might also want to add a bulk setter that takes a Dictionary. Also, what's the default base URL? If I'm in a document with a base set, are instances that don't specify one relative to the origin of the window object from which the instance is created? I ask, because in the caes of: new URL(/thinger.html); I'd expect identical calls like that to have different toString() values if executed on foo.com and bar.com. It was unclear to me if that's the case today. That's covered in step 1 of http://url.spec.whatwg.org/#constructors. If there's no explicit base, the URL is resolved relative to about:blank. To me, that seems better that implicitly using the document's base URL. You can always supply the document's base URL from document.baseURI if you want. Adam
Re: [whatwg] Location object identity and navigation behavior
On Thu, Nov 8, 2012 at 10:19 AM, Bobby Holley bobbyhol...@gmail.com wrote:
The current spec for the Location object doesn't match reality. At the
moment, the spec says that Location is a per-Window object that describes
the associated Document. However, in our testing, it appears that none of
the user-agents (Gecko, WebKit, Trident, Presto) do this [1]. Instead, all
implementations of Location describe the active document in the browsing
context (that is to say, the referent of the WindowProxy). This suggests
that the spec's current language is likely not web-compatible.
If the Location object describes the browsing context, we're left to
consider whether there should be one Location object per Window or one
Location object per browsing context. Gecko and Webkit currently do the
former, and Trident and Presto do the latter (see again [1]). I would like
to change Gecko's behavior here [2], because would simplify a lot of
security invariants and generally make things more sane. How do WebKit
folks feel about this?
I'm not sure I quite understand what you mean here. Can you describe
an experiment that would distinguish these cases? I looked at [1],
but it was too complicated for me to understand quickly.
Consider the following case:
== Document A ==
script
Object.prototype.foo = A1;
window.location.bar = A2;
function f() {
var loc = window.location;
print(loc.foo); // print is a magic function that lets me see this value
print(loc.bar);
}
/script
== Document B ==
script
Object.prototype.foo = B1;
window.location.bar = B2;
/script
1) Document A is displayed in browsing context X.
2) Browsing context X is navigated and now displays document B.
3) Function f is called.
What values are printed?
If Location follows the WindowProxy, an interesting question is what
happens to expando properties on navigation. I did some testing, and UAs
seem to have pretty inconsistent behavior here [3]. As such, I think the
sanest policy is simply to clear expandos on Location each time the page is
navigated. This is the approach I've taken in the patches in [2].
I don't think I quite understand what you mean, but the way this works
in WebKit is that each Window object has its own Location object. The
location object operates on the current Window for the WindowProxy.
In WebKit at least, it would be a security vulnerability to expose
JavaScript objects that belong to Document B to Document A because
that would give Document A access to the prototype objects for
Document B.
Adam
Re: [whatwg] Improving autocomplete
On Fri, Oct 26, 2012 at 12:43 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Oct 26, 2012 at 9:24 AM, Elliott Sprehn espr...@gmail.com wrote: [...] I'm missing the scenario that requires such interference from a web developer. Can't a UA just offer to autocomplete a form for me once it finds one? (Or in other words, unless I'm missing something this seems like a solution without a provided use case.) When should the UA offer to fill in the form (e.g., to select which address they would like to use for shipping this particular order)? In particular, Elliott wrote: Authors can also display no forms at all to users of a browser who implements this proposal for one click checkout experiences which are important on mobile devices. Adam
Re: [whatwg] Document referrer and script entry point
To answer these questions, you need to reverse engineer the behavior of various user agents, compare them, and then pick a consensus behavior that ideally is both interoperable between user agents and compatible with existing content. I'm happy to change WebKit to such a consensus behavior, but I don't have the time right now to help you reverse engineer the behavior of WebKit-based user agents. Adam On Mon, Oct 22, 2012 at 5:32 AM, Bobby Holley bobbyhol...@gmail.com wrote: Any WebKit folks want to weigh in on this one? Ian, what do you think from a spec perspective? On Tue, Oct 9, 2012 at 4:59 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 10/9/12 9:45 AM, Bobby Holley wrote: I'd like to change Gecko to implement the alternate behavior - that is to say, making document.referrer refer to the script entry point at the time of navigation. Specifically for navigation via the location object. It's not quite clear to me what should happen for navigation via click() on an anchor or .submit() on a form, and those are a somewhat separate discussion from this one. -Boris
Re: [whatwg] Details on window.open
On Sun, Oct 7, 2012 at 3:32 AM, David Bruant bruan...@gmail.com wrote: I've been searching on the web for complete documentation about window.open and I have some unanswered questions. 1) what are the rules for popup blockers? Is every call to window.open blocked in modern browsers or are there exceptions? I don't think the spec requires an specific behavior. Generally speaking, user agents can be configured as to which sorts of popups they block. Most user agents block popup that were not initiated during a user gesture. 2) About the third argument, is there a somewhat interoperable overlap in implementations or is it just an intricable mess? 3) Is what is returned a instance of Window or WindowProxy? WindowProxy. The web platform never returns a direct reference to a Window object. By that I mean that if one browsing context A opens C and B window.open C too changing the URL (and reloading), is A supposed to have access to the new C or only the old browsing context? The new C. 4) About step 4 of The rules for choosing a browsing context given a browsing context name [1]: If the given browsing context name is not |_blank| and there exists a browsing context whose name http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#browsing-context-name is the same as the given browsing context name, and the current browsing context is allowed to navigate http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#allowed-to-navigate that browsing context, and the user agent determines that the two browsing contexts are related enough that it is ok if they reach each other, What does related enough mean? That varies by implementation. How is it implemented in different browsers? That's a long, complicated topic. Some user agents track units of related browsing contexts. For example, Chrome ensures that units of related browsing contexts are not split across process boundaries. In Chrome, the search of related enough browser contexts stops at process boundaries. then that browsing context must be the chosen one. If there are multiple matching browsing contexts, the user agent should select one in some arbitrary consistent manner, such as the most recently opened, most recently focused, or more closely related. What is the consistent manner in each implementation? You might need to run some experiments to answer this question for yourself. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#the-rules-for-choosing-a-browsing-context-given-a-browsing-context-name
Re: [whatwg] Spec for location object needs to make some properties unforgeable; need supporting WebIDL changes
Also valueOf. Adam On Mon, Sep 24, 2012 at 10:10 PM, Boris Zbarsky bzbar...@mit.edu wrote: Turns out, some things care about at least the .href and .toString of Location objects for security-check purposes. So they need to be unforgeable. But of course WebIDL doesn't provide a way to make anything other than readonly attributes unforgeable. It seems like it needs to. In terms of current UA behavior for Location, it is full of weird. The only interoparable part seems to be that href and toString can't be effectively redefined. In IE and Gecko, neither can any of the other IDL properties of Location objects. So we have indications that making everything on this interface unforgeable is sufficiently web-compatible. Specifically, on the attached testcase, I see the following behavior: Opera: * toString is not an own prop, is a configurable prop on the proto, but defineProperty on the object for it fails with an exception due to it not being configurable(!) * href is a non-configurable own prop * assign/replace/reload are normal props on the proto * The rest are normal accessor props on the object itself. Chrome: * toString is a non-configurable readonly own prop * href is a non-configurable own prop for which defineProperty silently does nothing. * assign/replace/reload are just like toString * The rest are normal data props on the object, except defineProperty does not change the value, which it should for normal props. Safari: * toString is a non-configurable readonly own prop and also a non-configurable writable prop on the proto. Except location.hasOwnProperty(toString) returns false. * href is a non-configurable readonly own prop * assign/replace/reload are just like toString except writable, so defineProperty can change the value. * The rest are all readonly non-configurable props on the object itself. Gecko: * It's all weird, because location is actually a bizarro proxy object (e.g. it has no __proto__ property, returns weird stuff that can't be stringified from Object.getPrototypeOf()). * The key part is that trying to redefine _any_ of the properties that live on Location.prototype on the location object itself is disallowed in Gecko. IE9: * All properties throw when getting property descriptors on location object. * Some properties are configurable on the proto and some are not. * All properties throw when trying to redefine. Including non-IDL properties. Setting expandos works fine, though. * All properties claim to not be own properties. -Boris
Re: [whatwg] Spec for location object needs to make some properties unforgeable; need supporting WebIDL changes
On Mon, Sep 24, 2012 at 11:31 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 9/25/12 2:24 AM, Adam Barth wrote: Also valueOf. We'd just need to add that on the interface to make it work, right? I'm not sure what needs to be done in spec-land to make valueOf work correctly, but in implementation-land it needs the same unforgability mitigations as toString. Here are a couple test suites that might be helpful: http://trac.webkit.org/browser/trunk/LayoutTests/fast/dom/Window/Location In particular the location-override-* and location-shadow-* tests. Also http://webblaze.cs.berkeley.edu/tests/window-location/ has a test suite (which might overlap substantially with the former). Adam
Re: [whatwg] Spec for location object needs to make some properties unforgeable; need supporting WebIDL changes
On Tue, Sep 25, 2012 at 10:15 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 9/25/12 12:54 PM, Adam Barth wrote: I'm not sure what needs to be done in spec-land to make valueOf work correctly, but in implementation-land it needs the same unforgability mitigations as toString. Well, one thing that needs to happen is that its behavior needs to be specced. Should it do the same thing as the canonical Object.prototype.valueOf does? Yeah, it doesn't need to do anything special. It just need to not be changeable by the page. Adam
Re: [whatwg] Spec for location object needs to make some properties unforgeable; need supporting WebIDL changes
On Tue, Sep 25, 2012 at 4:58 PM, Cameron McCormack c...@mcc.id.au wrote: Boris Zbarsky: So we have indications that making everything on this interface unforgeable is sufficiently web-compatible. OK. I propose then that we allow [Unforgeable] on the interface, which means: * attributes get own, non-configurable accessor properties (with setters if they are not readonly attributes), and no property on the prototype * operations get own, non-configurable, non-writable properties, and no property on the prototype * the stringifier gets an own, non-configurable, non-writable toString property, and no property on the prototype * there is an own, non-configurable, non-writable valueOf property that just returns this I think that's the least amount of crazy. This would make Location.prototype empty. Is that OK? That looks like what Chrome does: $ location.__proto__.hasOwnProperty(href) false $ location.__proto__.hasOwnProperty(host) false Adam
Re: [whatwg] Security restriction allows content thievery
On Thu, Sep 6, 2012 at 9:53 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 7 Sep 2012, Fred Andrews wrote: I think the aim is to have the URL of the page that includes these data: URLs sent to the tracking server? Ah, I see. So say you have a page A, which itself contains a data: URL, and you load that data: URL as page B, and in B there is a link to another resource C, the argument here is that in the network request for C, the referrer information should be of A, rather than B? That's an interesting idea... Any browser vendors want to chip in on this? We're unlikely to implement that in WebKit. We'd like to keep documents created by data URLs in a unique origin and avoid leaking privileges (including the privilege to send a certain Referer into the iframe). Adam
