Re: [XHR] Redirects

2010-09-15 Thread Julian Reschke

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

2010-09-15 Thread Boris Zbarsky

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

2010-09-15 Thread Julian Reschke

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

2010-09-15 Thread Boris Zbarsky

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

2010-09-15 Thread Julian Reschke

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

2010-09-15 Thread Boris Zbarsky

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

2010-09-15 Thread Boris Zbarsky

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

2010-09-15 Thread Boris Zbarsky

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

2010-09-15 Thread Julian Reschke

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

2010-09-15 Thread Arthur Barstow


 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

2010-09-15 Thread Arthur Barstow


 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

2010-09-15 Thread Jeremy Orlow
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]

2010-09-15 Thread Web Applications Working Group Issue Tracker

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]

2010-09-15 Thread Web Applications Working Group Issue Tracker

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]

2010-09-15 Thread Web Applications Working Group Issue Tracker

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]

2010-09-15 Thread Web Applications Working Group Issue Tracker

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]

2010-09-15 Thread Web Applications Working Group Issue Tracker

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]

2010-09-15 Thread Web Applications Working Group Issue Tracker

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]

2010-09-15 Thread Web Applications Working Group Issue Tracker

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]

2010-09-15 Thread Web Applications Working Group Issue Tracker

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]

2010-09-15 Thread Web Applications Working Group Issue Tracker

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]

2010-09-15 Thread Web Applications Working Group Issue Tracker

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

2010-09-15 Thread Doug Schepers

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]

2010-09-15 Thread Olli Pettay

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

2010-09-15 Thread Arun Ranganathan

 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