Re: IndexedDB, what were the issues? How do we stop it from happening again?
On Friday, March 15, 2013 at 4:11 AM, Jarred Nicholls wrote: On Thu, Mar 14, 2013 at 10:19 PM, Alex Russell slightly...@google.com (mailto:slightly...@google.com) wrote: On Thu, Mar 14, 2013 at 6:36 PM, Glenn Maynard gl...@zewt.org wrote: Workers exist explicitly to allow you to do expensive synchronous stuff without janking the main thread. (Often, the expensive synchronous stuff will just be a bunch of calculations, so you don't have to explicitly break it up into setTimeout-able chunks.) The entire reason for most async (all?) APIs is thus irrelevant in a Worker, and it may be a good idea to provide sync versions, or do something else that negates the annoyance of dealing with async code. My *first* approach to this annoyance would be to start adding some async primitives to the platform that don't suck so hard; e.g., Futures/Promises. +1. Libraries cover that fairly well; albeit I think we all would enjoy such things to be first-class citizens of the platform. I've seen some good looking implementations and some decent control flow libraries. I use https://github.com/caolan/async a lot in node projects. Saying that you should do something does not imply that doubling up on API surface area for a corner-case is the right solution. I agree. It may have seemed like a good and simple idea at first - well intentioned for sure - but upon reflection we have to admit it's sloppy, a greater surface area to maintain, and the antithesis of DRY. It's not what I personally would expect from a modern, quality JS api, and I'm probably not the only web dev to share that feeling. At the risk of making a blanketed statement using anecdotal evidence, I would claim that overindulgence from modern libraries in existence today has raised the expectations of web devs in how the web platform architects new apis. Node.js comes with sync and async APIs (for good reasons) and I haven't heard anyone complain that this wasn't DRY. --tobie
Re: Streams and Blobs
After pondering this over for a few days, here's what I propose.
For an async XHR, if .responseType is set to stream, then when we
reach the HEADERS_RECEIVED state .response is set to a Stream object.
(See more about this below)
As data is being downloaded, we add the data to the end of the Stream
and then fire the normal ProgressEvent events on the XHR object.
Putting data into the Stream might cause other actions to happen,
including firing of events. These actions thus happen before the
ProgressEvent is fired on the XHR object.
For a sync XHR in Workers, if .responseType is set to stream when
XHR.send() is called, we block until the HEADERS_RECEIVED state is
reached. At that point we return from the .send() function and return
a newly constructed Stream object. Note that reading from the Stream
object should likely not be permitted synchronously, even within
workers. So all that's synchronous here is waiting until we reach the
HEADERS_RECEIVED state.
There is an additional issue that needs to be resolved however. What
does the following code do?
var xhr = new XMLHttpRequest();
xhr.open(GET, url);
xhr.send();
xhr.onreadystatechange = function(e) {
if (xhr.readyState != xhr.HEADERS_RECEIVED) {
return;
}
xhr.response === ; // true
xhr.responseType = stream;
xhr.response instanceof Stream; // true or false?
xhr.responseType = text;
xhr.response === ; // true or false?
}
We normally allow setting .responseType during the readystatechange
handler for the HEADERS_RECEIVED state transition. But it seems silly
if you have to wait for the event handler to exit before you can get
at the Stream object. But it also seems weird that xhr.response would
synchronously change into a Stream object when .responseType is set to
stream.
Granted, we do currently synchronously change .response from empty
string to null when .responseType is set to something other than or
text. But it seems weird to allow setting .responseType to stream,
grabbing the Stream object, and then setting .responseType to
something else.
I guess we could always make the Stream object immediately produce an
error if .responseType is changed to something other than stream.
As far as I can tell this problem exists in all solutions for using
streams that have been discussed so far. I.e. it's not specific to any
properties of the above proposal.
/ Jonas
Re: RfR: Web Workers Test Cases; deadline March 28
On Thu, 14 Mar 2013 20:34:52 +0100, Arthur Barstow art.bars...@nokia.com wrote: This is a WG-wide Request for Review [RfR] for the tests Microsoft and Opera submitted for the Web Workers CR [CR]: http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/ http://w3c-test.org/webapps/Workers/tests/submissions/Opera/ Simon (Web Workers' `Test Facilitator`) proposed in [1] the tests are sufficient to test the CR's exit criteria. If you have any comments, please send them to public-webapps-testsu...@w3.org by March 28. I've looked at all the files in http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/ , below are my comments. http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/WorkerGlobalScope_ErrorEvent_message.htm assert_not_equals(err.message, undefined); assert_not_equals(err.message.indexOf(ErrorMessage), -1); I think this assertion should be removed. The spec doesn't require any particular text in the message argument of onerror, so it doesn't make sense to check the value in a test, beyond checking that it is a string. I'd suggest the following assertion instead of the two above: assert_equals(typeof err.message, 'string'); (Same thing in Worker_ErrorEvent_message.htm.) The WorkerGlobalScope_ErrorEvent tests are not testing ErrorEvent at all, but are testing WorkerGlobalScope#onerror and its arguments. I suggest renaming these tests and their description to be less confusing as to what they are testing. http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/WorkerGlobalScope_EventTarget.htm title WorkerGlobalScope implements EventTarget /title var t = async_test(Test Description: WorkerGlobalScope implements EventTarget); This doesn't affect what the test does, but in the spec the interface inherits from EventTarget, rather than implements it. assert_regexp_match(target, /\[object (.*?)Worker(.+?)\]/); This should be instead: assert_equals(target, '[object WorkerGlobalScope]'); http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/WorkerGlobalScope_removeEventListener.htm This has trailing junk that should be removed. This test also appears to be brittle as to whether it produces a result (I often get Not Run result). It appears to have to do with timing -- it sets a setTimeout that may or may not be longer than the timeout set in setup(). Other tests use the same pattern. I would recommend having a fixed number in setTimeout of, say, 100ms, and do this for all tests that contain `time * 2`. (Some tests do this already.) setTimeout(t.step_func(VerifyResult), time * 2); change to setTimeout(t.step_func(VerifyResult), 100); That appears to give more stable results for me. I also recommend changing the timeout in setup() in all tests to 2000ms since it might take some time to load the worker file, and I seem to get Not Run sometimes (when loading a test the first time) for some tests even if they're just waiting for a message event. http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/WorkerLocation_hash_nonexist.htm var t = async_test(Test Description: WorkerLocation hash attribute returns an empty string when there is no lt;querygt; component in input URL.); change to var t = async_test(Test Description: WorkerLocation hash attribute returns an empty string when there is no query component in input URL.); (Similarly in other files, search for `lt;`.) worker.postMessage(EvalScript); EvalScript is not defined. I think the whole line can be removed. (Same error in some other files.) http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/WorkerNavigator_appName.htm var description = WorkerNavigator appName: Returns the name of the browser: + window.navigator.appName; Remove window.navigator.appName from the description since it complicates comparing results of tests between browsers if the names of the tests differ between browsers. (Similarly for the other WorkerNavigator tests.) Test names should be fixed strings. The spec now has a 'language' member for WorkerNavigator but there's no test for it. There are some tests (e.g. the ErrorEvent tests) that are almost identical, connect to the same worker, get the same data, and only differ in what they check. This seems to be an inefficient way of doing things and makes the test suite take longer than necessary to run. I would recommend folding such tests together into one file and have separate test_async() objects for each thing that is to be tested. http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/Worker_ErrorEvent_type.htm All the Worker_ErrorEvent tests are wrong in that the ErrorEvent.js file catches the runtime error in onerror and then returns true, which means that the error is handled, and no error event should be fired on the worker object (in the
Re: security model of Web Components, etc. - joint work with WebAppSec?
On 3/14/13 8:16 PM, ext Charles McCathie Nevile wrote: On Thu, 14 Mar 2013 18:15:14 +0100, Dimitri Glazkov dglaz...@chromium.org wrote: On Thu, Mar 14, 2013 at 7:10 AM, Hill, Brad bh...@paypal-inc.com wrote: Is there time available on the April F2F agenda for discussion of this? If not in WebApps, would relevant WG members be willing to join us if we found time to discuss in WebAppSec’s timeslot Thursday or Friday? http://www.w3.org/wiki/Webapps/April2013Meeting#Potential_Topics Shows agenda wide open so far. Should we just plop something into one of the slots? Yep, that's a reasonable thing to do... I allocated a slot for the joint meeting on Thursday from 2:30-3:00. If anyone thinks more time is needed, please speak up. Please use public-webapps@w3.org for _all_ Web Components discussions and I encourage feedback, comments, etc. in _advance_ of the meeting. FYI Brad, Dimitri and the Editors have created a suite of Web Components specs. The set of specs that have already been published is: * Web Components Introduction http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html * HTML Templates http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html * Shadow DOM http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html There is at least one unpublished ED (not sure if this is ready yet for security review): * Web Components (link rel=components and Components API) https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/components/index.html Dimitri - if you can think of specific areas of potential security concerns you would like reviewed or if I missed any specs, please let us know. -Thanks, ArtB cheers Chaals
Re: Streams and Blobs
On Fri, Mar 15, 2013 at 10:07 AM, Jonas Sicking jo...@sicking.cc wrote: For a sync XHR in Workers, if .responseType is set to stream when XHR.send() is called, we block until the HEADERS_RECEIVED state is reached. At that point we return from the .send() function and return a newly constructed Stream object. Note that reading from the Stream object should likely not be permitted synchronously, even within workers. So all that's synchronous here is waiting until we reach the HEADERS_RECEIVED state. I think this is very weird. XMLHttpRequest governs network transfers. If XMLHttpRequest just terminates at that point, something is missing. -- http://annevankesteren.nl/
WebSocket API - server initiated close
Hi, If a client app connects to a server through WebSocket API, and server sends a close frame, how is the client app notified? Does the client stack automatically respond with a close frame, then raise a close event? Meanwhile, if the client app is invoking send() while the server close frame arrives, what happens? The paragraph about bufferedAmount implies that send() won't fail, is that correct? Thanks, Zhong Yu
[FileAPI]
Hello, I have a few suggestions (for Blob URL) for you, because in my experience, they should be part of the specification. *The events:* Currently it is not possible not to know if a Blob URL has been loaded by the browser, whether it is an image, a file download, etc.. For example, currently, I am developing a text editor allowing my users to save their changes, using an anchor. No method allows me to notify the user that the file has been saved (by changing the color of the editor tab, for example, like Notepad++). In addition, these events could be useful to ensure that the Blob URL is loaded only once. *The name of the file:* A file name may likewise be very useful. I think a consideration of option as BlobURL.name and/or based on the value of the download attribute of an anchor to which the Blob URL is attached. *The full path of the file:* Currently, according to my tests on Firefox, I noticed the inability to specify the full path of the file, converts all Firefox : / by underscores. I am not suggesting that when the user clicks, the file is saved to the specified path directly but offers a prompt browser to save the file to the specified path, just like a Save as. In my opinion, the full path chosen by the user should be able to be recovered, for example, for monitoring the integrity of the application. It should be specified, either by the download attribute value or by a Blob URL property. Well, that's all for now, if you have any questions, do not hesitate to contact me, I will answer with pleasure. Cordially, Michaël Rouges
[webcomponents] linking using link rel=components href=...?
Hey all, I searched the archive at http://lists.w3.org/Archives/Public/public-webapps/ and checked out the https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html#definitions and https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html specs, but couldn't find anything about this in them: are there provisions in the spec (or is it in the works) to add a new link type so that if some person A defines a stack of useful templates, and person B wants to use those templates, they can include them on their own page using link rel=templates href=http://personA/templates.html; (or rel=components, or some other relation name that makes sense for the role the link plays)? I was thinking about this in terms of using web components for something like Mozilla's Popcorn Maker, where it would be really cool if we could define all our components as templates, and then tell everyone this is our collection of templates, go grab popcorn.webmaker.org/templates.html if you want to use these on your own pages!. I really love the idea of web components, but it feels like being able to share them in the same way you can share .js or ..css files would make them ridiculously powerful on the future web =) - Mike Pomax Kamermans Mozilla Foundation
RE: security model of Web Components, etc. - joint work with WebAppSec?
As I mentioned in my introductory message, I am specifically interested in the security model of components loaded cross-origin - do they get complete control of the application / DOM into which they are loaded? Does an application have any ability to restrict or explicitly pass capabilities to a cross-origin component? -Brad Hill -Original Message- From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Friday, March 15, 2013 7:20 AM To: Hill, Brad; Dimitri Glazkov Cc: public-webapp...@w3.org; public-webapps Subject: Re: security model of Web Components, etc. - joint work with WebAppSec? On 3/14/13 8:16 PM, ext Charles McCathie Nevile wrote: On Thu, 14 Mar 2013 18:15:14 +0100, Dimitri Glazkov dglaz...@chromium.org wrote: On Thu, Mar 14, 2013 at 7:10 AM, Hill, Brad bh...@paypal-inc.com wrote: Is there time available on the April F2F agenda for discussion of this? If not in WebApps, would relevant WG members be willing to join us if we found time to discuss in WebAppSec's timeslot Thursday or Friday? http://www.w3.org/wiki/Webapps/April2013Meeting#Potential_Topics Shows agenda wide open so far. Should we just plop something into one of the slots? Yep, that's a reasonable thing to do... I allocated a slot for the joint meeting on Thursday from 2:30-3:00. If anyone thinks more time is needed, please speak up. Please use public-webapps@w3.org for _all_ Web Components discussions and I encourage feedback, comments, etc. in _advance_ of the meeting. FYI Brad, Dimitri and the Editors have created a suite of Web Components specs. The set of specs that have already been published is: * Web Components Introduction http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html * HTML Templates http://dvcs.w3.org/hg/webcomponents/raw- file/tip/spec/templates/index.html * Shadow DOM http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html There is at least one unpublished ED (not sure if this is ready yet for security review): * Web Components (link rel=components and Components API) https://dvcs.w3.org/hg/webcomponents/raw- file/tip/spec/components/index.html Dimitri - if you can think of specific areas of potential security concerns you would like reviewed or if I missed any specs, please let us know. -Thanks, ArtB cheers Chaals
CfC: move WebApps' test suites to Github; deadline March 22
As you probably know, the HTMLWG recently moved its test suite to GitHub (GH). Tobie, Robin, Odin, Ms2ger and others propose WebApps do the same and this is a Call for Consensus to do so. Odin defined the new testing process for GH in [Proposal] and this will replace most, if not all, of the testing processes already agreed [Testing]. (Some things like using testharness.js will remain the same.) Assuming this CfC passes: * [Proposal] will likely be updated as we gain experience with GH and may be replaced by more general information like https://github.com/w3c/web-platform-tests/blob/master/README.md. * The root of the repository will be the same as HTML(WG): https://github.com/w3c/web-platform-tests and each of WebApps' specs will have its own subdir. For example the Web Storage test suite would be https://github.com/w3c/web-platform-tests/webstorage/. * WebApps' hg test repository https://dvcs.w3.org/hg/webapps/ will become Read-only (i.e. write access will be turned off). * Tobie, Robin, Odin and Ms2ger will do the work of the move (Test Facilitators are not required to do the work). If you have any comments or concerns about this CfC, please reply to this e-mail by March 22 at the latest. Positive response is preferred and encouraged, and silence will be considered as agreement with the proposal. -Thanks, AB [Proposal] http://www.w3.org/wiki/Webapps/Submitting_tests [Testing] http://www.w3.org/2008/webapps/wiki/Testing
WebSocket API - server initiated close
(sorry if this is a repost, I think my prev message got lost) Hi, If a client app connects to a server through WebSocket API, and server sends a close frame, how is the client app notified? Does the client stack automatically respond with a close frame, then raise a close event? Meanwhile, if the client app is invoking send() while the server close frame arrives, what happens? The paragraph about bufferedAmount implies that send() won't fail, is that correct? Thanks, Zhong Yu
[editing] table manipulation commands
Hi, I would like to propose adding some basic table manipulation commands to the editing spec [1]. Something along the lines of: execCommand(InsertColumnsBefore, false, numColumns); execCommand(InsertColumnsAfter, false, numColumns); execCommand(DeleteSelectedColumns, false); execCommand(InsertRowsBefore, false, numColumns); execCommand(InsertRowsAfter, false, numColumns); execCommand(DeleteSelectedRows, false); These are common table operations supported by many rich text editors, but there doesn't seem to be any support for them in browsers. The DeleteSelectedColumns command seems a bit weird because there's no way to actually select columns, and support for multi-range selection seems to be going away [2], but I think for now if it deletes the column where the caret is currently at, it should be good for now. Another command I would like to propose is: execCommand(JustifyColumns, false, left); execCommand(JustifyColumns, false, center); execCommand(JustifyColumns, false, right); execCommand(JustifyColumns, false, justify); Note: The JustifyColumns command wouldn't be necessary if we can instead come up with a reasonable way to select columns. Thoughts? Thanks, Shezan [1] https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html [2] https://bugzilla.mozilla.org/show_bug.cgi?id=753718
Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec
I have added onipointerlockchange and onpointerlockerror to the partial document IDL in the pointer lock specification. Webkit currently only defines these event handler attributes on document. Unless a reason is raised to add them elsewhere, I do not plan to add additional attributes elsewhere, for reasons discussed in fullscreen specification primarily regarding the confusing when releasing exiting due to an element being removed from the DOM, and confusion over multiple listener points. https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html https://dvcs.w3.org/hg/pointerlock/diff/86bc101925d8/index.html On Thu, Mar 14, 2013 at 12:05 PM, Simon Pieters sim...@opera.com wrote: On Thu, 10 Jan 2013 18:24:52 +0100, Boris Zbarsky bzbar...@mit.edu wrote: And if so, which objects should they be on? Window? Documents? Elements? Currently event handlers are available on all of Window, Document and HTMLElement even if the relevant event just fires on one of them, so I suggest we do that. -- Simon Pieters Opera Software
Re: Streams and Blobs
On Mar 15, 2013 5:33 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Mar 15, 2013 at 10:07 AM, Jonas Sicking jo...@sicking.cc wrote: For a sync XHR in Workers, if .responseType is set to stream when XHR.send() is called, we block until the HEADERS_RECEIVED state is reached. At that point we return from the .send() function and return a newly constructed Stream object. Note that reading from the Stream object should likely not be permitted synchronously, even within workers. So all that's synchronous here is waiting until we reach the HEADERS_RECEIVED state. I think this is very weird. XMLHttpRequest governs network transfers. If XMLHttpRequest just terminates at that point, something is missing. It is definitely different, but I don't see any actual problems with it. I.e. I don't think it'll be hard for authors to understand, nor do I think it'll lead to subtle bugs. / Jonas
Re: Streams and Blobs
On Fri, Mar 15, 2013 at 5:07 AM, Jonas Sicking jo...@sicking.cc wrote: For an async XHR, if .responseType is set to stream, then when we reach the HEADERS_RECEIVED state .response is set to a Stream object. (See more about this below) As data is being downloaded, we add the data to the end of the Stream and then fire the normal ProgressEvent events on the XHR object. Putting data into the Stream might cause other actions to happen, including firing of events. These actions thus happen before the ProgressEvent is fired on the XHR object. This isn't guaranteed. Progress events are queued tasks, and the other actions (such as EventSource's onmessage) are also typically queued tasks. Since they're from different task sources, the order the tasks are performed is unspecified. For a sync XHR in Workers, if .responseType is set to stream when XHR.send() is called, we block until the HEADERS_RECEIVED state is reached. At that point we return from the .send() function and return a newly constructed Stream object. Note that reading from the Stream object should likely not be permitted synchronously, even within workers. So all that's synchronous here is waiting until we reach the HEADERS_RECEIVED state. Synchronous XHR returns when it reaches DONE. Returning at HEADERS_RECEIVED would be strange and inconsistent. Not supporting synchronously reading from streams is also strange. We should definitely be able to support this, just like we support other synchronous I/O in workers. Even if we don't tackle exposing this right away, having an API design incapable of supporting it would be a serious mistake. This all seems to be bending and twisting XHR, and imposing arbitrary restrictions, in order to try to make the API work in the way you first envisioned it. The approach I've suggested doesn't require these contortions and restrictions. I guess we could always make the Stream object immediately produce an error if .responseType is changed to something other than stream. Specifically, I'd recommend that when readyState isn't UNSENT, setting responseType to stream should fail, and if readyState is set to stream then setting it to something else should fail. That is, once the request is started it's too late to change into or out of stream mode. -- Glenn Maynard
Pointer lock updated with clarification of lock and focus requirements.
After discussion with Olli Pettay I have clarified portions of the pointer lock specification. https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html https://dvcs.w3.org/hg/pointerlock/diff/6543d83c0b74/index.html When requesting pointer lock, this paragraph replaces previous statements regarding the target being in the DOM tree. Pointer lock must succeed only if the target is in the active document of a browsing context which is (or has an ancestor browsing context which is) in focus by a window which is in focus by the operating system's window manager. The target element and its browsing context need not be in focus. In Requirements, clarification was added that focus MAY be shifted out of a document and into others without exiting lock: The Pointer Lock API must exit the pointer lock state if the target is removed from its document, or the user agent, window, or tab loses focus. Moving focus between elements of active documents, including between browsing contexts, does not exit pointer lock. E.g. using the keyboard to move focus between contents of frames or iframes will not exit. Feedback and suggestions welcome.
Re: Streams and Blobs
On Fri, Mar 15, 2013 at 2:36 PM, Glenn Maynard gl...@zewt.org wrote: I guess we could always make the Stream object immediately produce an error if .responseType is changed to something other than stream. Specifically, I'd recommend that when readyState isn't UNSENT, setting responseType to stream should fail, and if readyState is set to stream then setting it to something else should fail. That is, once the request is started it's too late to change into or out of stream mode. That would mean not supporting the ability to choose to handle a response as a Stream based on metadata in the response. That was the reason we decided to support setting .responseType in the HEADERS_RECEIVED state to other values. I don't see why the same reasons doesn't apply here. / Jonas
Re: Streams and Blobs
On Fri, Mar 15, 2013 at 7:23 PM, Jonas Sicking jo...@sicking.cc wrote: Specifically, I'd recommend that when readyState isn't UNSENT, setting responseType to stream should fail, and if readyState is set to stream then setting it to something else should fail. That is, once the request is started it's too late to change into or out of stream mode. That would mean not supporting the ability to choose to handle a response as a Stream based on metadata in the response. That was the reason we decided to support setting .responseType in the HEADERS_RECEIVED state to other values. I don't see why the same reasons doesn't apply here. Change readyState != UNSENT above to readyState HEADERS_RECEIVED. That means you have a last chance to change to or from stream mode during the HEADERS_RECEIVED onreadystatechange event, after headers are available and before any of the body is read, but once you're in LOADING or DONE, stream mode is locked in (or out). (This should apply to both of the XHR models we've been discussing.) -- Glenn Maynard
