[whatwg] Driveby typo notice
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-resource When the user agent has completely fetched of the entire media resource s/ of//
Re: [whatwg] Captions, Subtitles and the Video Element
On 17.7.09 02:15, Ian Hickson wrote: I think this particular case can be a victim of the 80% rule. Fair enough, probably. Jeff
Re: [whatwg] Captions, Subtitles and the Video Element
On 15.7.09 17:56, Ian Hickson wrote: On Thu, 19 Feb 2009, Ian Fette wrote: However, there's a lot of uses for subtitles / captions that cannot be met with subrip. No styling (beyond the bare basics), no karaoke commands, no alpha, no nice handling for collisions, margins, shadow colors, specifying encoding, etc. I disagree that we should have author-controlled styling here. While I could maybe be convinced to have something basic like colour and maybe positioning, I think it is important that we let the subtitles be under the control of the user and the user agent, as they are, for instance, on TVs. Providing a way for authors to select different voices would make sense, but if we allow arbitrary styling we are going to have all kinds of problems, like lacking the ability to take subtitles and convert them to braille without losing context, or losing the ability to trivially convert subtitles for use in other contexts like TV subtitles. (For the few authors who really want to go crazy, they can already overlap HTML onto theirvideo and do whatever crazy stuff they want to do.) By way of a use case for at least color and positioning, there's a certain part of the third (?) Austin Powers movie wherein the color and position of foreign-language subtitles plays an important part in the artistic merits (lack thereof, arguably) of the scene. How would you suggest a movie-viewing site use video to display these? It seems unreasonable to say that the site must include special-case handling for this particular movie clip's subtitles; it's more likely they would be mangled in some manner and the semantic content (lack thereof) would be lost. By the way, I have no idea how foreign-language translations of the movie handle this scene. It's possible they simply subtitle the subtitles and avoid the more complicated problems this scene arguably presents. Jeff
Re: [whatwg] HTML 5 video tag questions
On 12.7.09 23:20, Ian Hickson wrote: If people really want to push Apple into supporting Theora, the best way to do it would be to just keep using it as if it was the common codec, and _not_ provide another fallback forvideo-supporting UAs -- then things would work fine it non-video- supporting UAs like IE (through fallback flash support insidevideo), and would work fine in Theora-supporting UAs, but Safari would be left in the cold. I'm fine doing this for myself: partly because it's pressure on Apple; perhaps mostly because I choose to make embedding videos that I can watch in-browser easy for myself, and because I don't particularly care if some portions of my audience are unable to see such videos and also choose not to download a browser that will display them (fallback content provides a download link -- I haven't made the effort to handle Safari4-sans-XiphQT yet, see supra). That said, my position will be uncommon, and I'm not particularly interested in making use of video right now harder for those who don't share it -- even if it comes at the expense of added pressure on Apple. Jeff
Re: [whatwg] HTML 5 video tag questions
On 11.7.09 12:54, Gregory Maxwell wrote: ...snip... Precisely. Jeff
Re: [whatwg] HTML 5 video tag questions
On 10.7.09 17:44, Ian Hickson wrote: The design is based around the assumption that we will eventually find a common codec so that fallback won't ever be needed in supporting UAs. So has anyone ever actually pointed out the elephant in the room here, that we might never do so? I can't remember if so. Maybe HTML5: Galaxy Quest (cf. Captain Taggart's line) just isn't going to happen in the foreseeable future. (I'm also not convinced that we substantially hurt ourselves by making fallback content the final source.) Jeff
Re: [whatwg] Issues with Web Sockets API
On 26.6.09 16:49, Michael Nordman wrote: Progress bars are routinely implemented without get hi-level application acks from the other side. XMLHttpRequest.upload.onprogress is one such example. That they can be implemented this way does not imply they must be implemented this way. I don't see why the acks users will pretty much invariably have (if they're implementing something so complex as to want data-sent events) layered atop the base WebSocket don't suffice for this (and more accurately than simple out-of-the queue status notifications can establish). diagnostics Cell-phone signal strength bars are a form of diagnostics... existence proof of diagnostics being a significant use case. Is WebSocket the optimal way to satisfy that use case? (Also, to be clear, I wasn't suggesting that diagnostics aren't interesting, but they seem quite orthogonal to the primary use case of supporting two-way message passing.) This info about the status of the WebSocket would be easy to provide to callers of this API. There are easily found valid use cases for this additional status info. What compelling reason is there to not do so? Seems like low-hanging fruit if you ask me. The use case may be valid, but I don't see it as compelling. I don't see the gain as worth the added complexity to the interface, which at present is exactly as simple as it can be to support two-way message passing. I expect the messages passed will usually follow send-ack sequencing (in one direction or the other, and particularly for users who care about exact data transmission), in which case reception of an ack signals progress has been made. Jeff
Re: [whatwg] Issues with Web Sockets API
On 26.6.09 13:52, Michael Nordman wrote: There isn't a way to determine if the WebSocket is successfully sending the postMessage data? For all the caller knows, its just backing up and not going anywhere. You can't really know data has been successfully sent until you get a response that acknowledges it. Getting it on the wire doesn't mean it'll actually be received; I'm not really sure how much value knowing that's happened actually has, other than for doing network diagnostics (which hardly seems a use case to support). postMessage() may want another exception condition... 'too much data pending exception'... consider calling postMessage in a while(true) loop... at some point the system is going to have to give up queing the data if its not actually making its way out on the wire. Nothing prevents the data from being thrown in a FIFO queue until it actually can be sent, and I don't see a reason why OOM in the event queueing failed should be handled differently from any other OOM. Jeff
Re: [whatwg] do not encourage use of small element for legal text (was: Pre-Last Call Comments)
Do you seriously believe any client in an industry where he has to step carefully enough to worry about typographical formatting of legal notices is fool enough to follow a not-even-recommendation in the HTML5 specification over what his lawyer tells him is the correct thing to do? Jeff
Re: [whatwg] Captions, Subtitles and the Video Element
On 20.2.09 05:54, Lachlan Hunt wrote: Greg Millam wrote: * All timed text tracks encoded in the video file are added to the list, as an implicit caption element. I'm not entirely sure what you mean, but I don't think implying a new element in the HTML based on text tracks within the media file is a good idea, and nor is it necessary. Instead, the UA just needs to obtain a list of available text tracks by combining those embedded within the media file with those linked to from the HTML, and make them all available to the user. I think I agree with this; that caption or whatever would magically appear in the DOM as media data is downloaded (and in an unpredictable manner, from the point of view of the page author) seems baroque and unexpected. Jeff
Re: [whatwg] eventsource/RemoteEventSource wierdness
On 17.2.09 22:53, Jonas Sicking wrote: This could also replace the IMHO awkwardeventsource element. I don't understand the value of having this element at all. It seems to me that if the only way you can use an API is through script, then making the API into an element is adding extra complexity to the HTML language for little to no gain. I seem to recall reading once that it's not the case that the only way you can use the API is through script -- sort of. At one time I believe the intent was that an onmessage attribute on body would allow you to have handlers without needing to run script to set them. You would of course still need script to execute for the handler to run. That said, I don't think that reason is at all compelling. As far as any list of features to cut (spin into other specifications) goes, I would rate this one fairly high on it, particularly if the element API were scrapped in favor of a pure-script API. There are interactions with the current task-queueing mechanism in HTML5, to be sure, but eventsource is mostly a consumer of those mechanisms, not a contributory component of it. I don't think eventsource's removal would affect the continuing evolution of the queueing mechanism in any meaningful way. Jeff
[whatwg] Small ddition to 7.4.2.1, postMessage's security considerations for authors
The spec should mention that even after MessageEvent.origin's value has been checked, MessageEvent.data should also be checked for structural correctness, because if the target window contains an XSS hole, improper validation of incoming messages could result in the target window's XSS hole being propagated into the sender's window as well. For example, consider a site A which requests a particular string of JSON data from site B, which it then parses into an object using eval(). If site B is subvertible, the response JSON string may instead be arbitrary script which would be executed by site A *as* site A's code. Proper validation by site A would mean checking that the sent string actually is JSON and not arbitrary syntactically-correct JavaScript. (Ignore the fact that the site shouldn't be unserializing JSON data using eval(), and further ignore that structured data-passing makes this particular use obsolescent. Other instances of contamination may be possible depending on the sent data and its structure, and this was just the simplest example to explain.) Jeff
Re: [whatwg] Cross browser automated tests
Sylvain Pasche wrote: As a starting point, the testing environment and API would need to be defined. I'm thinking of the following requirements: * Possible for browser vendors to integrate these tests in their testing frameworks Hrm, I neglected to mention this on the other thread, but this requirement can't fly. It discourages creating libraries for common testing functions (or even just for non-testing functions, e.g. how Mochitests all have access to the entire MochiKit framework) and using them declaratively (hardcoded script versus dynamic addition with callback schemes), which just makes life harder if you're writing tests. Jeff -- Life would be so much easier if humans had a natural affinity for remembering 128-bit integers.
[whatwg] postMessage tests updated (again)
http://web.mit.edu/jwalden/www/whatwg/postMessage-v3.zip Same instructions as last time -- unzip, start an HTTP server on port serving postMessage/ as its root directory, set up proxy autoconfig with a PAC URL of http://localhost:/proxy.js, navigate to http://localhost:/tests/dom/tests/mochitest/whatwg/index.html, and click the Run Tests link. Spec progress since the last iteration mean that I don't think this tests anything which isn't in the latest HTML5 spec. The IDNness of origins was the big thing last time, and since then the spec's changed to say that origin always uses IDN and never punycode, so these tests now, I believe, only test spec behavior. Again note that a bunch of the origin tests currently fail in Mozilla due to URL-parsing generosity, so unless you exactly match those generosities you won't pass the tests, because they expect to fail and will report errors if they don't. It shouldn't be hard to deal with that manually, and changing the tests to expect success rather than failure is pretty trivial. Questions, comments, concerns, bugs, yadda yadda, etc. welcome as responses to this email... Jeff -- Life would be so much easier if humans had a natural affinity for remembering 128-bit integers.
Re: [whatwg] link rel=icon width= height=
Ian Hickson wrote: This is a proposal to add height and width attributes to link specifically for the case of rel=icon, so that authors can provide multiple icons and let the UA decide which to use based on their size (without having to download them all to find out which is best). Opinions? Given that link/ is more intended as a generic element, I'm somewhat leery of adding attributes specifically for one individual use of it. If you're going to add an attribute (but see below), I think it makes sense that it be something that any use of link/ could use to store extra data -- so an opaque attribute whose semantics are specified by the rel attribute of the link. Maciej Stachowiak wrote: I would suggest a sizes attribute which can take a list of sizes (with x as a width/height separator), or a keyword such as any or scalable to indicate a scalable format suitable for any size. link type=icon type=application/svg sizes=any href=whatwg.svg link type=icon type=image/microsoft.vnd.icon sizes=16x16 32x32 href=whatwg.ico link type=icon type=image/x-apple-icons sizes=16x16 32x32 64x64 128x128 256x256 512x512 href=whatwg.icns link type=icon type=image/png sizes=59x60 href=whatwg.png This might require that existing browsers cope correctly (or exploit duplication/error behaviors), but could a MIME parameter address this without needing another attribute at all? That's the most narrowly scoped change I can imagine that would address the need. link rel=icon type=application/svg; sizes=any href=whatwg.svg link rel=icon type='image/microsoft.vnd.icon; sizes=16x16,32x32' href=whatwg.ico link rel=icon type='image/x-apple-icons; sizes=16x16,32x32,64x64,128x128,256x256,512x512' href=whatwg.icns link rel=icon type=image/png; sizes=59x60 href=whatwg.png Restrictions on what a parameter value may be (basically can't contain any separators or whitespace) are a touch confounding here because you don't have any separators unless you quote; that probably factors into the equation here. Jeff -- Life would be so much easier if humans had a natural affinity for remembering 128-bit integers.
[whatwg] The origin of pages on the local file system
It was brought up during the latest postMessage patching in Mozilla that the HTML5-mandated origin for file: URIs groups all local file system pages into a single origin. Pages are increasingly being used in application-like contexts, and if Java is any example, grouping all files into the same origin will eventually be problematic (if one even chooses to argue it isn't now). (Firefox 3's postMessage will be intentionally non-conforming with respect to file: pages in that sending a message to a file: page will only work if you use * as the targetOrigin, in the interests of not having different security behaviors.) Firefox 3 changes from an all-files-are-same-origin model to a contains-based model, roughly this in at least some cases: a file may load any file which is a sibling of it, and it may load any file which is a descendant of the file's parent directory. I'm certain I'm horribly mangling what actually happens in practice in at least some situations, based on what I've read of the security comparison functions, but this is at least a start at describing the behavior for specification. The original bug was https://bugzilla.mozilla.org/show_bug.cgi?id=230606, but follow dependencies and read comments to see what sort of issues were actually encountered in practice and couldn't be ignored without breaking wide swathes of content. Jeff -- Life would be so much easier if humans had a natural affinity for remembering 128-bit integers.
Re: [whatwg] postMessage feedback
(sigh, messed up sender address so the original got rejected from the whatwg list, apologies for the duplicate message...) Ian Hickson wrote: I haven't changed the target of the event, it's still the Document object. This is a little odd, though, would people rather I made it the body element with an auto-forward to the Window object, like the 'load' event and so forth? That would allow onmessage= handles to be written. I've mentioned this on IRC but should probably mention it here so it's in the record, so to speak. I don't see a strong use case for an onmessage attribute. Event handler attributes are useful for quick little things, but accepting messages from other sites seems neither quick (aside from free-for-all walls I can't think of things you'd want to do that wouldn't be fairly involved) nor little (you need the origin check at a minimum, then you have to do whatever you're going to do, and it's a lot to stuff in an attribute -- and if you're just delegating to another method, why not just set the method as handler programmatically?). I don't think having to do it via script is particularly burdensome. Jeff
Re: [whatwg] postMessage feedback
Maciej Stachowiak wrote: If anything this event should dispatch to the window, not the document, since that is what gets the postMessage call. But posting to the document and bubbling to the window seems ok too. The event currently doesn't bubble to accommodate event-source: http://lists.whatwg.org/htdig.cgi/commit-watchers-whatwg.org/2008/000436.html So right now, either you use a bubbling listener (capturing works too, although the web may end up dictating that that's a bug that won't be fixt) on the document or a capturing listener (ugh) on window or you don't get it. I'm not entirely sure why the event doesn't bubble for postMessage; it seems like a postMessage event doesn't necessarily have to do the same thing as an event-source event, but maybe there's precedent here that I don't know. As far as I can tell the event is dispatched at the document only because Opera's original implementation had postMessage on document. I sort of prefer dispatching to the window as well, but that change would have to be made ASAP to make Firefox 3. It's a one-line change (+30ish for addEventListener calls in tests, also easy to do), as is the bubbling change, but it's extraordinarily late for us to make these changes (async cuts it very, very fine as-is), and nobody would be happy if the spec converged on something that Firefox 3 didn't actually implement. Jeff -- Life would be so much easier if humans had a natural affinity for remembering 128-bit integers.
Re: [whatwg] A suggestion, if postMessage becomes async
Anne van Kesteren wrote: How is omitting the argument any less explicit than providing a * as argument? I would prefer we keep that part of the API as is. It's far easier to forget to provide the origin than it is to accidentally provide *. If you omit an origin with this API, one way or another you're going to get an exception (either a syntax error or a not-enough-arguments error, depending on how DOM bindings work in the browser). Jeff
[whatwg] A suggestion, if postMessage becomes async
Make the targetOrigin argument non-optional. * would mean don't care while anything else would specify an origin (or result in a syntax error). If this is done, it's no longer possible to have time-of-check/time-of-use issues (in the async case) without the web developer explicitly choosing to do so. This change shouldn't be any more than 5-10 lines, and fixing existing testcases to adjust for this change is straightforward. Jeff P.S. -- The work needed to make the change I note above is substantially less than the work needed for an async postMessage. I did a trial implementation+test fixup for async postMessage in https://bugzilla.mozilla.org/show_bug.cgi?id=430251. I found my implementation added roughly 40 more lines of code -- not great but not too bad. Far more substantially, adjusting tests to the change, particularly tests looking to perform numerous steps in a particular sequence, was slow and painful. My conclusions are that back-and-forth communication with async postMessage is substantially harder than it is with sync postMessage, while async postMessage is moderately more difficult to implement than sync postMessage.
Re: [whatwg] ApplicationCache add/remove and relative URIs
Anders Carlsson wrote: The spec for the add and remove ApplicationCache methods does not say what to do about how relative URIs should be resolved. I think it would be most intuitive to resolve them agains't the URI o the document that the ApplicationCache object is associated with. Generally I believe URIs have been resolved against the URI of the document that the script that invoked the method is associated with. For example, if I have origin A and pages A_1 and A_2, a script on A_1 that uses, say, A_2.XMLHttpRequest.open with a relative URI will have that URI resolved against A_1.location.href. Similar precedent applies to loading scripts or iframes, calculating the sender's URI for events dispatched by postMessage, and other such uses. Think of it this way: a relative URI used from script is lexically scoped to the document that loaded the script, and any relative URIs used have the same semantics any time that code executes -- they're not dependent on the location of the document associated with the ApplicationCache, which might or might not be what you actually expected it to be at runtime. What you suggest goes against a lot of precedent, from my point of view. If only for consistency, I think we're better off making relative URIs be lexically scoped such that they're resolved against the location of the document in which the script is executed. Jeff
Re: [whatwg] Request: window.postMessage should be async
Peter Kasting wrote: Here's another problem an async API would automatically address: https://bugzilla.mozilla.org/show_bug.cgi?id=416912 That *should* be handled by a slow-script dialog, and the fact that it isn't is simply a bug. That the bug is triggered using postMessage is in my opinion not relevant to this discussion. Jeff
Re: [whatwg] Request: window.postMessage should be async
Peter Kasting wrote: It doesn't matter if the stack will not _commonly_ be too deep, or if it isn't too deep for the callers that you know about right now -- it might be too deep at some point (after someone else changes the caller code, for example), and your sync handler will blow up. So put it in the contract for the API you're designing on top of postMessage that you shouldn't call the method without some generous number of frames available. (Doesn't assuming you'll need to consume lots of stack frames work against your argument that postMessage receivers will usually do computation out-of-band anyway?) I don't see why this problem requires a technical solution rather than a social one. (I should have mentioned this in the first message, thanks for prompting me to bring it up now.) And the very sorts of things you'd want postMessage for are frequently cases where others will write mashups and use your code in ways you hadn't planned. No, but *they* plan how they're going to use it, and they can adjust to not call with near-full stacks. For this reason, I think talking about the common case misses the point -- a sync API is completely useless to anyone trying to write _any_ serious code defensively, large app or small, because it cannot be made safe except by using setTimeout to make it async, at which point synchronicity has bought you nothing. safe is a misnomer. There's nothing security-related about this, except in the case that you write your code and create some inconsistency that a stack overflow leaves around which causes vulnerabilities (but really, you should have been careful about that already, e.g. what if the browser naturally runs out of memory at that point and stops your script? a malicious page could make this happen, with some effort). All that happens is an exception, and you can catch and deal with it in the rare case that it happens. I prefer not to have APIs that force you to take action if you don't want to shoot yourself in the head. Not catching an exception isn't shooting yourself in the head, it's just doing nothing; I think this is hyperbole. If you're still not convinced that coders would care, remember that stack depths vary by interpreter, too. I believe in pocket IE you have a ridiculously small stack depth [12?]. This surprises me, but realistically, no device is going to be able to afford to have such a low stack depth going forward anyway. Color me skeptical that mobile devices will have such small recursion limits in the foreseeable future. Moore makes many problems go away fairly quickly; I don't think we should penalize tomorrow for a limitation of today. Also, just because stack overflow is more common on mobile devices doesn't make stack overflow not a special case. Given the number of websites relying on this feature right now (0?), how do you know what the special cases are? Not the special case, a special case: stack overflow. I don't think a decent-sized percentage of web developers worry about stack overflow significantly more often than they worry about it from thinkos that accidentally cause infinite recursion. Jeff
Re: [whatwg] Request: window.postMessage should be async
Eric Seidel wrote:
1. JS content authors will want an async API.
Sometimes, for the large applications; small apps won't care. As you note, the
workaround of immediately packaging up a setTimeout continuation isn't
difficult. I tend to think worrying about the N-1 case is designing a bit too
much for the special cases, personally. Special cases aren't special enough to
break the rules.[0] Further, nothing says browser implementations must or will
continue to enforce hard limits on recursion.
function messageHandler(messageEvent) {
// We assume calling into our complex functions might run out of stack
space, so we just handle this in a timeout:
setTimeout(0, function() { realMessageHandler(messageEvent) } );
}
function realMessageHandler(messageEvent) {
// handle the message...
// and, reply to the message
messageEvent.source.postMessage(response message);
}
Furthermore, note that the above behavior is actually *insecure* if the handler
authenticates the sender and discloses some secret in his response, because
|messageEvent.source| may have been navigated to a different origin. Making
the API async basically requires the optional origin argument always be
provided to postMessage, adding API complexity. If a piece of information
doesn't have to be [present] for the system to [usually] work, sooner or later
it won't be [and the system won't work].[1]
I forsee JS authors implementing their own asynchronous behavior, as
shown above.
I do, too, in some cases; I just don't think it's worth sacrificing simplicity
or security in the common case for the special, rare case.
2. JS engine implementors will want an async API.
I would rather we didn't prevent FireFox or Safari
Firefox, the second f isn't capitalized. :-)
(Only possible for frames which are not of the same origin. Same-origin
frames already assume they can grab at each others innards in a
synchronous manner.) postMessage imposes a NEW requirement that all
connected frames to be run from the same thread (or somehow synchronize
the threads after the first postMessage() call is made).
Wrong; if a window can get a reference to another window, same-origin or not,
run-to-completion already requires synchronous behavior. If some piece of JS
is in flight, every client-side change it can detect *must* be one it has
caused.
This requirement would seem even worse for Microsoft, since IE8 looks like
it's multi-process. A synchronous postMessage would require IE8 to keep
all frames which have references to each other in the same process.
postMessage imposes no new requirement for the appearance of synchrony, no
matter how the implementation chooses to achieve it.
Asynchrony was brought up in a separate thread ([whatwg] reply() extension to
postMessage()) two months ago, before the source-navigation discussion made this
secret-exposure danger more easily noticeable. I made basically the same arguments then
as I make now; I also noted that sync can replicate async (again ignoring the uncommon
case of being right at the recursion limit), whereas the reverse is not true:
I think I favor sync postMessage over async because async capabilities
are a strict subset of sync capabilities. You can always use setTimeout
with the sync model to get async behavior; if the model is async you
can't replicate sync behavior.
Note also that nothing prevents an implementation with a recursion limit from
requiring that postMessage always guarantee enough available frames to dispatch
the setTimeout continuation, although nobody I know has actually done this.
In sum, I think worrying about recursion limits is the wrong thing to do, sync
behavior is more flexible, and we shouldn't sacrifice security for the uncommon
recursion-limit case.
Jeff
0. Python, thy name is AWESOME. http://www.python.org/dev/peps/pep-0020/
1. Astonishingly PEP 20 doesn't have any dicta related to security, but
http://www.wiretip.com/?about comes to the rescue, with a few tweaks.
[whatwg] Web author docs for postMessage, updated postMessage tests
== Documentation == I've written up some documentation on how to use postMessage; suggestions, comments, etc. appreciated. http://developer.mozilla.org/en/docs/DOM:window.postMessage == Tests == I updated and expanded the tests I posted earlier to accommodate uri/domain-origin and the optional targetOrigin argument to postMessage: http://web/jwalden/www/whatwg/postMessage-v2.zip Same rules for use apply as before -- unzip somewhere, start up a local web server on port serving the postMessage/ directory as its root directory, turn on proxy autoconfig with the URL http://localhost:/proxy.js, and load and run http://localhost:/tests/dom/tests/mochitest/whatwg/index.html to see what passes and fails. The tests basically follow the spec or guard Mozilla-specific tests assuming you follow the spec. There are some cases where Mozilla doesn't follow the spec, however, and won't be able to do so before Mozilla 2, so unless you fail those tests exactly like Mozilla does they'll show up as failures when you run the tests. First, most of the problems you'll likely encounter relate to the value of .origin for IDN origins. HTML5 is silent on whether the value should be IDN, punycode, or even a chimeric mixture. I think .origin should never be punycode (authors shouldn't be forced to know about punycode, allowing either would require multiple origin comparisons, and also, Unicode ASCII), and the tests expect that (or, for the places where we fail that, they expect the opposite and mark that situation as a todo). If you do anything other than exactly match Mozilla behavior, you'll see tests listed as failures. Second, test_postMessage_closed.html fails if a popup blocker is enabled. Make sure to run this with the blocker disabled to actually make it do its tests right. Third, the tests require a very strict parsing of the optional targetOrigin argument to postMessage which rejects various malformed URIs. Unless you match Mozilla's behavior exactly, you'll see some errors here -- some quite likely erroneous. Note also that some of these tests check handling when this argument is punycode and when it's IDN; make sure you pass both. I apologize in advance if you find test_postMessage_origin.xhtml a little confusing to read; I don't especially like it either. However, it was the easiest way I could think of to run a whole lot of similar tests without lots of code-copying. I'm guessing existing URL parsers are lax because existing content is lax; for postMessage there's no existing content, so I'd like to see this done right from the start (or at least described that way in the spec, since Mozilla isn't in a position to switch to stricter parsing until Mozilla 2). Fourth, .origin for posts from data: URIs in Mozilla is the origin of the window that opened the data: URL, which is not what HTML5 wants (data: URLs each have origins distinct from all other origins in existence). Mozilla really isn't in a position to make a change to such fundamental security-conscious code right now, so this is expected to fail and marked as todo. If you do the right thing or don't do what we do, you'll get a failure on test_postMessage_special.xhtml. (I've documented Mozilla's behavior at the aforementioned link and noted that it's all but certainly going to change, and I've discouraged authors from using postMessage on pages at data: URIs for now. This isn't optimal, but I don't really think it's that huge a burden.) Fifth, I interpreted present and not null to mean that an explicit |undefined| second argument is converted to the string undefined and thus causes a syntax error to be thrown, based on a literal interpretation of the words in the phrase. Comments, questions, suggestions for more tests, etc. are all appreciated. Jeff
Re: [whatwg] Web author docs for postMessage, updated postMessage tests
http://web/jwalden/www/whatwg/postMessage-v2.zip Sigh: http://web.mit.edu/jwalden/www/whatwg/postMessage-v2.zip Jeff
Re: [whatwg] Web author docs for postMessage, updated postMessage tests
Jeff Walden wrote: == Tests == http://web.mit.edu/jwalden/www/whatwg/postMessage-v2.zip Fourth, .origin for posts from data: URIs in Mozilla is the origin of the window that opened the data: URL, which is not what HTML5 wants I seem to have misread or misremembered how data: URIs are handled by HTML5, so this part was wrong; I updated the tests in the file at the above location to revert the change. Now there's an explicit, un-Mozilla-guarded check that http://localhost:; == the .origin of an event posted from a data: window to its opener which is located on http://localhost:. Jeff
Re: [whatwg] reply() extension to postMessage()
Ian Hickson wrote: ...this behavior could cause some somewhat nasty infinite recursion. So what if we made reply() asynchronous so that the the reply message event doesn't need to be dispatched on the original message posting document until after the original postMessage from the sender is finished processing? This problem exists today with postMessage() too. Do people think we should go fully asynchronous? Frankly, I'm not all that worried about someone accidentally triggering infinite recursion; it's easy enough to detect (by the error that's hit? I don't know IE/Opera behaviors here), and setTimeout is easy enough to use. I think I favor sync postMessage over async because async capabilities are a strict subset of sync capabilities. You can always use setTimeout with the sync model to get async behavior; if the model is async you can't replicate sync behavior. Jeff
[whatwg] drawImage with non-existent images
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-the-canvas.html#drawimage: If the image argument is an HTMLImageElement object whose complete attribute is false, then the implementation must raise an INVALID_STATE_ERR exception. This is all well and good in the case where the image being drawn has the same origin as the document where the canvas resides, but if the two have different origins, this makes it possible to determine the existence of an image on a foreign server. This exception must only be thrown if the image element's origin is the same as that of the document containing the canvas being modified. (You can already determine image existence by seeing how an image affects page layout, but this still seems like a reasonable behavior anyway.) Jeff
Re: [whatwg] Fixed a security problem with postMessage()
Ian Hickson wrote: * message.domain isn't actually enough to verify any security, given that on shared hosts one IP address can map to several hostnames and thuspeople can end up running servers on different ports that respond torequests from domains they don't own. * message.uri can leak information, e.g. if the user's password is in the query component of the URI. Good catches on both; I agree these changes make sense. I've replaced both with .origin, which is intended to return the scheme://hostname/ or scheme://hostname:port/ (when the port is non-standard) of the origin of the source document. I assume you meant without the trailing slash, given that that's actually part of the path? This doesn't sound like it should be too hard to implement, although the manual splicing-out of the username/password from the origin is slightly worrying (if entirely necessary) from a careful-manipulation-is-tricky point of view. I don't see any other option, tho, on that point. Jeff
Re: [whatwg] postMessage: event.source allows navigation of sender
I'm a bit late to this party due to turning off list email because I didn't think I could handle it in addition to all the other email I receive. I just reenabled it to not miss anything; we'll see how this actually goes this time around. :-\ Adam Barth wrote: On Feb 7, 2008 4:32 AM, Hallvord R M Steen [EMAIL PROTECTED] wrote: One case I'm still somewhat concerned about is that one is allowed to set the location of any top-level window according to the ancestor policy, Yes. I think there is a lot of room for improvement in this part of the navigation policy. While to an extent it seems there's agreement that the ancestor policy works well enough to not worry overly much about postMessage exposing the sender's window, the top-level window thing is a pretty big hole that breaks dumping content in an iframe if that content can't be trusted. postMessage exposing the sender isn't that meaningful if you can just change the toplevel site, even if the location bar changes correspondingly. (Really, who looks at the location bar on even dynamic, JSy pages other than after an intentional navigation? I doubt I do.) That said, I think a reply() method might be a better idea than a source property. I'm not sure how meaningful that would be for MessageEvent generically, but I guess source had that problem already for server-sent events. Do note it's more spec burden due to determining sender identity (could be mitigated by equating reply with calling postMessage on the proposed-hidden source property); dynamic scope-dependent behavior is no fun that way. It seems like a better solution is to improve the navigation policy for top-level windows. That way, web sites don't have to fight the losing battle of controlling references to their windows. Agreed. One possibility is to prevent one frame from navigating another if the frames are in different units of related browsing contexts. This doesn't help the iframe case, which is something that, say, Facebook or any site that embeds Google Maps would care about -- or, indeed, any site that wanted to display some other site in an iframe. The subsequent _unrelated proposal would need an extension for frames/iframes for this to be a complete solution. Jeff
Re: [whatwg] A potential slight security enhancement to postMessage
The original message never showed up, sadly, so the threading's going to be a bit wrong here, unfortunately. Currently postMessage is great for sending authenticated messages between frames. The receiver knows exactly where each message came from. However, it doesn't provide any confidentiality guarantees. When you're posting a message to a window, you have no way of knowing who is listening on the other end, because the same-origin policy prevents you from reading the domain and URI of that window. The window may have been showing a page loaded from foo.com the last time you received a message from it, but it might be displaying content from bar.com now; if you send it a message, you don't whether the message will be received by foo.com or bar.com. I noted in IRC discussion that postMessage being sync allows a challenge-response protocol to be safely used here, and you can determine the target's identification using domain/uri on the responding message; counterresponse was that's somewhat complicated. Fair enough; I'm not sure if super-security is the main use case for this feature or not (lightweight collaboration seems more likely to me, but I don't really know), so I'm hesitant to comment too much on it. The postMessage API could be extended to provide confidentiality by adding some optional arguments: void postMessage(in DOMString message, [optional] in DOMString domain, [optional] in DOMString uri); If domain or uri are specified, the browser would only deliver the message if the recipient's location matches the specified domain and/or URI. (Being able to specify the URI allows sites to differentiate between http and https URIs.) This seems reasonable enough. For privacy, postMessage should be designed not to reveal the domain or URI of the receiving window, so if there is a mismatch, the message should be silently dropped. Silent dropping is definitely good. Providing the domain and URI for replies should be easy since these values are already parameters of the event. True -- problem is requiring people use them, since they're not forced to do so now. Jeff
Re: [whatwg] A potential slight security enhancement to postMessage
Aaron Boodman wrote:
Not necessarily. You could do something like this:
window.createMessageReceiver(http://www.google.com;)
.addEventListener(post-message, function() {
...
}, fase);
Could probably come up with a better method name, and I forget the
name of the event to use with PostMessage, but I hope you get the
idea.
Ah, yes, hadn't given it enough thought to think of that idea. Adding yet
another object type to the HTML5 system seems suboptimal, but it would address
the problem. A whitespace-separated string of URIs (or prefixes? or domains?
domains is least complicated but doesn't address protocol, and possibly not
port) seems like a reasonable way to do it.
If you tell people they have to read x property before y
property, they will just do:
// spec says we have to read this first
var foo = event.domain;
alert(event.message);
That'd be the fear, yes. It depends to an extent on how the documentation's
worded, which is the problem this is originally trying to avoid.
Jeff
Re: [whatwg] A potential slight security enhancement to postMessage
Maciej Stachowiak wrote: The more convenient version of that would be to require clients to describe allowed senders when registering for the event in some way. I thought about this, but then we necessarily lose the familiarity of the standard event-listener registration process, which outweighs the convenience in my book. Also, I half-think my suggestion is over-paranoia, and I don't give it enough credence to consider inventing a listener-registration process. That would seem more like a convenience and less like a hoop to jump through. The key, tho, is that this really isn't a hoop to jump through. Excluding toy public message board demos, can you describe a use case for postMessage where it is not necessary to know the identity of the sender? To know the identity you have to check domain or uri, and there's no reason not to do that before getting the sent data. I also see a message to this list from Collin Jackson which *should* have arrived in my inbox hours ago but hasn't, and I don't see it in my spam folder. I'm going to give it another half-day or so to appear, and at that point I'll do my best to respond without destroying the threading too much. The ideas suggested there are at first glance orthogonal to my original suggestion, and I also need time to fully formulate a response. Jeff
[whatwg] A potential slight security enhancement to postMessage
I briefly wrote up some documentation on postMessage for the Mozilla Developer Center: http://developer.mozilla.org/en/docs/DOM:window.postMessage If you pull it up, you'll note two places where I include big, huge, overbearing, somewhat-exaggerating injunctions about first checking the domain/uri/source properties of the received message before trusting the sent data. Writing those got me thinking: what if we could enforce not touching the data before verifying the sender's identity? Specifically, what if we required that either .domain or .uri be read prior to allowing .data to be successfully accessed, say, without throwing a security error? (No reason comes to mind for .source to participate in this scheme, either to throw or to allow access to .data, but I haven't given it serious thought.) This would prevent unknowing misuse of this functionality, and safe uses wouldn't be affected. I think this would only apply to the event dispatched by postMessage, not to MessageEvent, as the latter is same-origin and there's no harm to a same-origin MessageEvent. Thoughts? A no-harm slight increase of the ability to prevent incorrect use of postMessage, or excessive nannying? Jeff
[whatwg] postMessage support now in Firefox trunk, implementation issues, feedback, tests
, in this case. If we ever changed the behavior of data: URLs, I suspect we'd hit the logic to return an empty string. * event.domain when document.domain has been changed The value of event.domain is the original domain for the page, not the value to which document.domain may have been set. * handling a postMessage-dispatched MessageEvent by throwing Any exceptions thrown by exception handlers when postMessage is called on a window are ignored; they are not propagated up to an exception handlers. In particular, this happens regardless of the origin of the window whose script threw an exception, even if it is identical to that of the window that called postMessage. It doesn't seem like a good design to me to have to check for a pending exception and only allow it if the target had the same origin; best to avoid the problem entirely and just unconditionally prevent any exceptions from propagating rather than introduce the possibility of error in determining when an exception may be safely propagated. (Also consider that if you were to propagate in the cross-origin case you'd have to make sure the thrower hadn't set any properties on the exception, or at least that said properties would not be accessible to the postMessage caller.) (One last note that's relevant yet not relevant: if you're wondering what Mozilla does for chrome content that runs with elevated privileges, we forcibly make the source of the dispatched events null. In this way chrome can postMessage chrome or content, but no method is provided for response or even for referring to the sender. To respond, the target window must be able to get a reference to the sending window some other way.) That covers everything I ran into while implementing this; comments, suggestions for other tests, complaints about test bugs, suggestions for error message clarifications, yadda yadda are all greatly appreciated! Jeff Walden P.S. -- Mailman, you suck for not using using the various vendor-specific and standard forms of pre-wrap on the ASCII emails you display, and I refuse to acquiesce to your demands for line breaks in what I type.
[whatwg] MessageEvent.domain, document.domain on a page whose URI has no domain (e.g. data:text/html, ...)
The spec as currently written says that document.domain in a document located at a URI with no domain is null: data:text/html,scriptalert(document.domain);/script Safari and Opera both alert the empty string for this; Firefox alerts null. There's also a domain property on MessageEvent, used with the cross-document postMessage API. The exact value of this property isn't quite clear in the current spec (which says the document has no domain but doesn't say what that translates into on the MessageEvent interface), but Opera and Safari both agree that the domain property should be the empty string when the page that calls postMessage is a data: URL. It seems that, for consistency, document.domain and MessageEvent.domain should both be the empty string in this case, for greatest cross-browser compatibility with the least change to the status quo, with the only change needing to happen in Firefox. Jeff
[whatwg] object, broken content, fallback
http://biesi.damowmow.com/object/011.html Firefox 2 shows FAIL. Firefox 3 currently shows PASS. WebKit nightly shows a broken image icon. Opera 9.25 shows PASS. http://www.whatwg.org/specs/web-apps/current-work/multipage/section-embedded0.html#the-object For the moment ignoring that WebKit's using @type instead of the server-sent type of the object producing the PASS/FAIL/icon (contrary to current HTML5 and HTTP RFC 2616), it seems that WebKit isn't displaying fallback content when the primary content contains errors -- malformed images, in this case -- where recent Firefox and Opera are. The spec doesn't currently address falling back for malformed content, i.e. malformed images, invalid XML (maybe?), content a plugin handler declines to handle (?, dunno whether this is expressible in NPAPI or ActiveX or whether that question's too implementation-dependent), etc. I tend to think it should since a broken-image icon's not particularly useful, but I don't care strongly one way or the other. Jeff
Re: [whatwg] More on postMessage
Gorm Haug Eriksen wrote:
I agree that postMessage should have been on the window and not on the
document, but why would you like to have the method on yourWindow
instead of the otherWindow you post the message to?
The benefit is that you don't have to punch holes through your existing
security infrastructure to do it. If you're in your code, you can have a
reference to an |otherWindow| that's not same-origin as you, but you can't do
any of the following (and probably more) with it:
var secretProperty = otherWindow.secretProperty; // stolen!
for (var i in otherWindow)
{
// if you get here, you know some of otherWindow's
// properties -- information leak
}
otherWindow.trustedProperty = subverted; // oops!
delete otherWindow.importantInfo; // DOS
For you to need to use postMessage on otherWindow, you need to be able to do
many of these things -- but the entire browser security model is based on not
allowing you to do this if the window you've called it on isn't same-origin
with you. You have to punch a hole in this security to allow getting, calling,
or enumerating postMessage, but only if the object off which the property is
gotten is a Window. You also have to make the property appear
ReadOnly/DontDelete externally, so you can't screw with windows that try to
call postMessage on you. Also, how does this restriction work with other
windows which are same-origin? Do they see only the original postMessage
binding, or do they see any modifications that window makes to it? What if a
different window, same-origin, makes that modification? What if windows
pre-HTML5 wanted to communicate via a postMessage binding? This gets
complicated pretty quickly, and to do it all you have to punch a hole through
security, and wi
th the fragility of that hole (only on Window, only if postMessage, only with
the original binding or only if it hasn't been overridden -- and I'm not at all sure
that's enough) and the specific criteria for that hole to exist, it's going to be easy to
accidentally allow more than you wanted to allow.
In contrast, passing a different-origin value into a function is already
allowed, and you don't need to do anything special to make it possible. The
only security modification to allow the cross-origin-ness is to make
postMessage ignore origins. This is *vastly* simpler, easier to implement, and
hence safer and more secure.
I'll agree that calling postMessage on the other window feels like a better and
more intuitive API for users, but if implementers have to make such invasive
and potentially-unsafe changes to do it, I think it's the wrong way to do it.
Jeff
[whatwg] More on postMessage
In my previous email regarding HTML5's postMessage (section 6.4, cross-domain communication), I suggested changing the API to |yourWindow.postMessage(message, otherWindow)|. I have a few more questions/suggestions after playing around with an implementation of this in Mozilla (bug postMessage for anyone who cares); I somewhat hope to get this in 1.9. First, I think placing |otherWindow| as the first argument and |message| as the second is more aesthetically pleasing than the other way around, tweaking the suggestion I made last time. I don't have a strong reason for this beyond its being analogous to the traditional security model in the literature (which seems good enough to me in the absence of strong reasons going the other way): yourWindow . postMessage ( otherWindow , message ) ; actor doesverbto object Second, in the interests of explicitness, we should be clear about the exact values of event.domain and event.uri. Two concerns: how does setting document.domain interact with the computed value for event.domain, and what are the contents of event.domain in the presence of default and non-default ports? I think the answers to these two concerns must be as follows. Setting document.domain must have no effect on the value of event.domain, in the interests of web hosts who host content on subdomains of their main domain, e.g. myhomepage.webhost.com and webhost.com (else it would allow spoofing in pages which listened for cross-domain messages but didn't check the uri). The contents of event.domain must include the port number iff it is not the default port number for the protocol (80 for http, 443 for https) and must omit it otherwise. Third, with the modified API, the following is possible: // kidFrame is same-origin wrt window window.frames.kidFrame.postMessage(otherWindow, message); With the current design, this would basically allow a window to send an event which looks as though it has been created by another (same-origin, or joined-principals via document.domain) window, with a different event.uri. Since the two windows are same-session this probably isn't a real concern, but I think it's worth mentioning that the change makes it possible to send a message from a window different from the one currently executing the script. Fourth, and probably most importantly, is the event dispatched by postMessage dispatched synchronously (event fired and processed before postMessage returns) or asynchronously? I interpret the current wording to mean synchronously, in accordance with the DOM 3 Events section on reentrance, but I'd like to be clear that's the intended interpretation. Jeff
[whatwg] Omission of frame reflection by name onto |window| in ECMAScript browsers
Apparently, the windows associated with frames contained within a document are added as properties to the containing document's window; the property name is the frame's name (or id, too? I don't know), and the property value is the frame's window object. Here's an example, since that's an unintelligible mouthful: http://mxr.mozilla.org/mozilla/source/dom/tests/mochitest/dom-level0/test_crossdomainprops.html?force=1raw=1 Section 4.2.4 notes that ECMAScript-enabled implementations must perform this mapping, but using numeric indexes within the document, not with their names. I think the omission of name-based frame-window lookup is an omission, so that needs to be added. Note that a description of this behavior should note behavior when a frame whose name is a number is contained within a document (and not at the corresponding index), e.g.: html body iframe name=1 src=.../iframe !-- window[0], but is it also window[1]? -- iframe name=foo src=.../iframe !-- is this window[1], or only window.foo? -- /body /html Jeff
