Re: [XHR] Redirects
On 14.09.2010 18:52, Darin Fisher wrote: ... That's a good point. Note, resolving the Location header is only one of the issues. Another is knowing what HTTP method to use in response to a redirect. ... Always the same as for the original request, except for 303 :-).
Re: [XHR] Redirects
On 9/15/10 12:13 AM, Julian Reschke wrote: On 14.09.2010 18:52, Darin Fisher wrote: ... That's a good point. Note, resolving the Location header is only one of the issues. Another is knowing what HTTP method to use in response to a redirect. ... Always the same as for the original request, except for 303 :-). Can I assume the smily face implies that you know that in fact that's not what browsers do? ;) -Boris
Re: [XHR] Redirects
On 15.09.2010 09:58, Boris Zbarsky wrote: On 9/15/10 12:13 AM, Julian Reschke wrote: On 14.09.2010 18:52, Darin Fisher wrote: ... That's a good point. Note, resolving the Location header is only one of the issues. Another is knowing what HTTP method to use in response to a redirect. ... Always the same as for the original request, except for 303 :-). Can I assume the smily face implies that you know that in fact that's not what browsers do? ;) Yes. However, I was only 50% joking. Are we sure that XHR should behave the same? Best regards, Julian
Re: [XHR] Redirects
On 9/15/10 1:10 AM, Julian Reschke wrote: Yes. However, I was only 50% joking. Are we sure that XHR should behave the same? Why should it behave differently from every single other HTTP request the browser makes? That seems like adding complexity for the sake of complexity... -Boris
Re: [XHR] Redirects
On 15.09.2010 10:16, Boris Zbarsky wrote: On 9/15/10 1:10 AM, Julian Reschke wrote: Yes. However, I was only 50% joking. Are we sure that XHR should behave the same? Why should it behave differently from every single other HTTP request the browser makes? That seems like adding complexity for the sake of complexity... What browsers do today is a bug per spec. Use cases for XHR are not identical to surfing web pages. There are protocols/implementations that expect method names to be preserved for 301/302 (*), and an XHR2 with sane redirect handling should at least make it possible to talk to these servers. Best regards, Julian (*) For instance, when Apache/mod_dav 302-redirects a PROPFIND request, the expectation *indeed* is that the redirect request is a PROPFIND.
Re: [XHR] Redirects
On 9/15/10 1:37 AM, Julian Reschke wrote: What browsers do today is a bug per spec. Well, yes, but they implemented it that way as a specific workaround for broken servers, no? Use cases for XHR are not identical to surfing web pages. There are protocols/implementations that expect method names to be preserved for 301/302 (*), and an XHR2 with sane redirect handling should at least make it possible to talk to these servers. OK, I almost buy this argument. I feel that we should require opt-in to this behavior difference, though, not do it by default. -Boris
Re: [XHR] Redirects
On 9/15/10 2:40 AM, Julian Reschke wrote: Well, yes, but they implemented it that way as a specific workaround for broken servers, no? I'm not sure about that. Hmm, fair. I just looked up the history of this code in Gecko, and the best I can give you is https://bugzilla.mozilla.org/show_bug.cgi?id=48202#c6 and https://bugzilla.mozilla.org/show_bug.cgi?id=48202#c30 So it's possible that the original behavior was just an oversight that then got copied. Someone with access to a browser version control system from before 1998 would need to look to make sure... -Boris
Re: [XHR] Redirects
On 9/15/10 2:47 AM, Boris Zbarsky wrote: So it's possible that the original behavior was just an oversight that then got copied. Someone with access to a browser version control system from before 1998 would need to look to make sure... It's also possible that no UA implementor was willing to implement the MUST NOT requirements below: If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued. and If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued. (RFC 2616 sections 10.3.2 and 10.3.3). How do you expect this to work in the XHR context? Is user for purposes of those two clauses the script that triggered the XHR, or the person actually represented by the user-agent (browser, say) in question? Then again, I guess they already ignore that MUST NOT clause for 307 redirects... So maybe they would just do the same thing here. Gotta love specs that really can't be implemented as written in sane ways. -Boris
Re: [XHR] Redirects
On 15.09.2010 11:56, Boris Zbarsky wrote: On 9/15/10 2:47 AM, Boris Zbarsky wrote: So it's possible that the original behavior was just an oversight that then got copied. Someone with access to a browser version control system from before 1998 would need to look to make sure... It's also possible that no UA implementor was willing to implement the MUST NOT requirements below: If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued. and If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued. (RFC 2616 sections 10.3.2 and 10.3.3). How do you expect this to work in the XHR context? Is user for purposes of those two clauses the script that triggered the XHR, or the person actually represented by the user-agent (browser, say) in question? Then again, I guess they already ignore that MUST NOT clause for 307 redirects... So maybe they would just do the same thing here. Gotta love specs that really can't be implemented as written in sane ways. For XHR I'd argue that once the caller requests control over redirects, he's responsible to do it right. With respect to 2616 and the text you quoted above: the WG is aware of this problem, see http://trac.tools.ietf.org/wg/httpbis/trac/ticket/238. Best regards, Julian
[widgets] Next call is September 23
There will be no widget call on September 16; the next call is September 23. All of the open Issues and Actions for widgets are available at the following http://www.w3.org/2008/webapps/track/products/8 The higher priority Actions/ToDos are: = Packaging and Configuration spec: need implementation data to complete the Implementation Report and move the spec forward: http://dev.w3.org/2006/waf/widgets/imp-report/ = Digital Signature spec: Need implementation data to complete the Implementation Report and move the spec forward: http://dev.w3.org/2006/waf/widgets-digsig/imp-report/ = Widget Interface spec a. September 28 is the comment deadline for the LCWD: http://www.w3.org/TR/2010/WD-widgets-apis-20100907/ b. Response needed for Addison's comment: http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0728.html = URI Scheme spec: address LC comments, complete scheme registration process http://dev.w3.org/cvsweb/2006/waf/widgets-uri/ = view-mode Media Feature spec: http://dev.w3.org/2006/waf/widgets-vmmf/ a. Need implementation data to complete the Implementation Report: b. Ask CSS WG to review the test cases http://www.w3.org/2008/webapps/track/actions/576 =Updates spec: status and plan for next publication http://dev.w3.org/2006/waf/widgets-updates/ -Art Barstow
[widgets] Widgets - WARP, Widgets Updates and Digital Signatures
FYI, Nathan and others discussed Nathan's e-mail on the device-apis list: http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/0034.html On 9/3/10 1:52 PM, ext Nathan wrote: Hi All, Simply wondering why WARP, Widgets Updates and Digital Signatures aren't used to deploy js applications which run in the main browser context? seems like a nice solution that would work webscale, and which would provide further user security, identification of trusted apps and cover the other half of CORS which is informing and protecting the user. Perhaps one of the vendors has already implemented in the main context? Best, Nathan
[IndexedDB] IDBCursor.update for cursors returned from IDBIndex.openCursor
I think it's clear what IDBCursor does when created from IDBObjectStore.openCursor or IDBIndex.openObjectCursor: it modifies the objectStore's value and updates all indexes (or does nothing and returns an error if all of that can't be done while satisfying the constraints). But what about IDBCursor.update when created from IDBIndex.openCursor? I see two options: we could modify the value within the objectStore's value that corresponds to the objectStore's key path or we could do like above and simply modify the objectStore's value. More concretely, if we have an object store with a id key path and an index with a fname key path, and our index.openCursor() created cursor is currently on the {id: 22, fname: Fred} value (and thus cursor.key == Fred and cursor.value == 22), let's say I wanted to change the object to be {id: 23, fname: Fred}. In other words, I want id to change from 22 to 23. Which of the following should I write? 1) calling cursor.update(23) or 2) calling cursor.update({id: 23, fname: Fred}) The former seems to match the behavior of the IDBObjectStore.openCursor and IDBIndex.openObjectCursor better (i.e. it modifies the cursor.value). The latter intuitively seems like it'd be more useful. But to be honest, I can't think of any use cases for either. Can anyone else? If not, maybe we should just make this unsupported for now? Btw, http://www.w3.org/TR/IndexedDB/#widl-IDBCursor-update probably needs to include some other errors as well since we need to return something when a constraint can't be met with the new value. Also, I'll note that while writing this code, I've gotten confused a couple times about what is the key and what is the value for Index cursors. I'm a bit concerned web developers will as well. J
ISSUE-123 (feature strings): Rationale for feature strings [DOM3 Events]
ISSUE-123 (feature strings): Rationale for feature strings [DOM3 Events] http://www.w3.org/2008/webapps/track/issues/123 Raised by: Doug Schepers On product: DOM3 Events Simon Pieters http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0125.html: [[ What's the use case for extended feature strings for event types (hasFeature('Events.click', ''))? Opera, WebKit and Gecko don't support this. [1] What's the use case for feature strings for event interfaces (hasFeature('KeyboardEvent', '') or hasFeature('Events.KeyboardEvent'))? The spec says it's for backwards compatibility, but Opera, WebKit and Gecko don't support this. [2] It's easier to test for event interfaces by checking if the interface object exists as a property on the global object, i.e. window.KeyboardEvent. (Opera currently doesn't expose KeyboardEvent on window, but that's something we should fix.) ]]
ISSUE-124 (reword examples): Remove RFC2119 keywords from examples [DOM3 Events]
ISSUE-124 (reword examples): Remove RFC2119 keywords from examples [DOM3 Events] http://www.w3.org/2008/webapps/track/issues/124 Raised by: Doug Schepers On product: DOM3 Events Simon Pieters http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0125.html: [[ RFC2119 keywords in examples is bad style. Please replace RFC2119 keywords in non-normative sections and examples with other words. ]]
ISSUE-125 (DOM Views): Consider dropping DOM Views reference for HTML5 defaultView [DOM3 Events]
ISSUE-125 (DOM Views): Consider dropping DOM Views reference for HTML5 defaultView [DOM3 Events] http://www.w3.org/2008/webapps/track/issues/125 Raised by: Doug Schepers On product: DOM3 Events Simon Pieters http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0125.html: [[ { The defaultView is an object which implements the AbstractView interface of the Document's DocumentView interface, which serves as a reference to the containing frame or window. } I think the idea is to drop support for DOM Views. HTML5 has added defaultView on the Window interface. http://html5.org/tools/web-apps-tracker?from=4947to=4948 ]]
ISSUE-126 (isTrusted): Consider changing 'trusted' to 'isTrusted' [DOM3 Events]
ISSUE-126 (isTrusted): Consider changing 'trusted' to 'isTrusted' [DOM3 Events] http://www.w3.org/2008/webapps/track/issues/126 Raised by: Doug Schepers On product: DOM3 Events Simon Pieters http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0125.html: [[ Gecko has a property called isTrusted that does the same as trusted, and seems to be used in the wild. [4][5] Please rename trusted to isTrusted. [4] http://software.hixie.ch/utilities/js/live-dom-viewer/saved/610 [5] http://www.google.com/codesearch?q=event%5C.isTrusted+lang%3Ajs ]]
ISSUE-127 (cancelBubble / srcElement): Consider adding cancelBubble and srcElement [DOM3 Events]
ISSUE-127 (cancelBubble / srcElement): Consider adding cancelBubble and srcElement [DOM3 Events] http://www.w3.org/2008/webapps/track/issues/127 Raised by: Doug Schepers On product: DOM3 Events Simon Pieters http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0125.html: [[ Looking at [6], I notice that Opera and WebKit have cancelBubble and srcElement. WebKit and Gecko have more constants on Event. [6] http://software.hixie.ch/utilities/js/live-dom-viewer/saved/611 ]]
ISSUE-128 (preventDefault): Define preventDefault to account for pre-propagation default actions [DOM3 Events]
ISSUE-128 (preventDefault): Define preventDefault to account for pre-propagation default actions [DOM3 Events] http://www.w3.org/2008/webapps/track/issues/128 Raised by: Doug Schepers On product: DOM3 Events Simon Pieters http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0125.html: [[ The definition of preventDefault does not talk about default actions that happen before the event propagation (like 'change' on checkboxes). ]]
ISSUE-129 (event constructors): Revist event constructors [DOM3 Events]
ISSUE-129 (event constructors): Revist event constructors [DOM3 Events] http://www.w3.org/2008/webapps/track/issues/129 Raised by: Doug Schepers On product: DOM3 Events Simon Pieters http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0125.html: [[ An idea for creating events is to support [Constructor] on all event IDLs, which makes the createEvent method unnecessary. Maybe we could even make the arguments to the constructor be called to initFooEvent() directly, so instead of doing var e = document.createEvent('MouseEvents'); e.initMouseEvent('click', ...); foo.dispatchEvent(e); you could do foo.dispatchEvent(new MouseEvent('click', ...)) Another thing we could change is to make all but the first arguments to initFooEvent() optional and let them have sensible defaults, so that if all you care about is the event type, you can include just the first argument. If the constructor is called with no arguments, then initFooEvent() would not be called. ]]
ISSUE-130 (Web IDL): Consider using Web IDL for the IDL fragments [DOM3 Events]
ISSUE-130 (Web IDL): Consider using Web IDL for the IDL fragments [DOM3 Events] http://www.w3.org/2008/webapps/track/issues/130 Raised by: Doug Schepers On product: DOM3 Events Simon Pieters http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0125.html: [[ I think this specification should use WebIDL for the IDL fragments. ]]
ISSUE-131 (defaultView load ): Define load event to fire on defaultView [DOM3 Events]
ISSUE-131 (defaultView load ): Define load event to fire on defaultView [DOM3 Events] http://www.w3.org/2008/webapps/track/issues/131 Raised by: Doug Schepers On product: DOM3 Events Simon Pieters http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0125.html: [[ { Note: for legacy reasons, the load event does not propagate to the defaultView in HTML implementations. } It's *fired* on the defaultView in HTML implementations, as specified in HTML5. ]]
ISSUE-132 (event.returnValue): Consider adding event.returnValue [DOM3 Events]
ISSUE-132 (event.returnValue): Consider adding event.returnValue [DOM3 Events] http://www.w3.org/2008/webapps/track/issues/132 Raised by: Doug Schepers On product: DOM3 Events Hallvord R. M. Steen http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0142.html: [[ IE lets you prevent the default action of an event by setting event.returnValue to false. Since both Opera and WebKit support this property it might be a good idea to standardise it? ]]
DOM3 Events Comments
Hi, Folks- I appreciate all the comments on DOM3 Events so far. I'm filing each of them in Tracker, though it may take me a few days to file a bug; however, I am reading all of them, and will get around to filing them all. Currently, the WebApps Tracker sends the emails for each filed issue to public-webapps, rather than www-dom, regardless of the product. I've asked our Systems Team if this can be changed for DOM3 Events issues, but I don't know if that's possible or easy to do. In the meantime, if you are going to respond directly to the Tracker emails, please take the time to change the TO: field to www-...@w3.org (though you should feel free to BCC public-webapps if you like). That will make it much easier to track the issues. Thanks- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Re: ISSUE-126 (isTrusted): Consider changing 'trusted' to 'isTrusted' [DOM3 Events]
On 09/15/2010 08:55 PM, Web Applications Working Group Issue Tracker wrote: ISSUE-126 (isTrusted): Consider changing 'trusted' to 'isTrusted' [DOM3 Events] http://www.w3.org/2008/webapps/track/issues/126 Raised by: Doug Schepers On product: DOM3 Events Simon Pietershttp://lists.w3.org/Archives/Public/www-dom/2010JulSep/0125.html: [[ Gecko has a property called isTrusted that does the same as trusted, and seems to be used in the wild. [4][5] Please rename trusted to isTrusted. [4] http://software.hixie.ch/utilities/js/live-dom-viewer/saved/610 [5] http://www.google.com/codesearch?q=event%5C.isTrusted+lang%3Ajs ]] IIRC, .trusted was used because XBL2 has that. But we should probably change both D3E and XBL2 to have isTrusted. -Olli
Re: ArrayBuffer and ByteArray questions
On 9/7/10 10:08 PM, Darin Fisher wrote: On Tue, Sep 7, 2010 at 5:23 PM, Kenneth Russell k...@google.com mailto:k...@google.com wrote: On Tue, Sep 7, 2010 at 4:19 PM, Nathan nat...@webr3.org mailto:nat...@webr3.org wrote: Jian Li wrote: Hi, Several specs, like File API and WebGL, use ArrayBuffer, while other spec, like XMLHttpRequest Level 2, use ByteArray. Should we change to use the same name all across our specs? Since we define ArrayBuffer in the Typed Arrays spec ( https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html), should we favor ArrayBuffer? In addition, can we consider adding ArrayBuffer support to BlobBuilder, FormData, and XMLHttpRequest.send()? which reminds me, I meant to ask if the aforementioned TypedArray spec should be brought in to webapps / w3c land? seems to complement the other base types used in webidl etc rather well + my gut reaction was why isn't this standardized within w3c? There's no particular reason why the Typed Array spec is being standardized in the Khronos group, aside from the fact that these array-like types originated in the WebGL spec and have evolved to meet use cases specified by WebGL. We have been hoping that they would have uses outside of WebGL, and some discussions have occurred with working groups such as TC39 to see how they might be better specified and standardized. We'd be open to hosting the spec development elsewhere. Vlad mentioned to me off-list that Mozilla has implemented an experimental mozResponseArrayBuffer on XHR objects, and will likely do the same on the File API to add a readAsArrayBuffer alongside readAsBinaryString etc. -Ken It sounds like ArrayBuffer is the name that is gaining traction (to circle back to Jian's original question about naming). In fact, readAsArrayBuffer / ArrayBuffer is used with FileReader, and will be the names going forward. ArrayBuffer is gaining traction as the used name :) -- A* -Darin