[Bug 10321] New: [IndexedDB] Description attribute of IDBDatabase doesn't play nicely with run to completion
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10321 Summary: [IndexedDB] Description attribute of IDBDatabase doesn't play nicely with run to completion Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: andr...@google.com ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org When opening a database, one of the parameters is description. If you specify it, that description is set on the database, no matter what the previous description was. There's also a description attribute on IDBDatabase(+ Sync). Since IndexedDB is usable by workers (and other pages' event loops, in some implementations) this presents a problem with run to completion. The easiest solution is to spec IDBDatabase(Sync).description to be the description you passed in to .open (and not a live value). I believe this is the only synchronous attribute with such a problem. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10322] New: open() should not throw for non same-origin URL
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10322 Summary: open() should not throw for non same-origin URL Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: XHR 1.0 AssignedTo: ann...@opera.com ReportedBy: ann...@opera.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org At the moment XMLHttpRequest Level 1 prescribes that open() invoked with a non same-origin URL should throw. This is incompatible with XMLHttpRequest Level 2. Instead we should align with XMLHttpRequest Level 2 (and some implementations) and treat non same-origin URLs as a network error during the request phase (i.e. after send() is invoked). This gives a better migration path towards CORS and allows us to test this requirement in browsers that implement (parts of) XMLHttpRequest Level 2. Along with this we should then also start throwing when the user/password arguments of open() are non-null for a non same-origin URL as XMLHttpRequest Level 2 does that as well. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10323] New: responseXML for HTML documents
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10323 Summary: responseXML for HTML documents Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: XHR 1.0 AssignedTo: ann...@opera.com ReportedBy: ann...@opera.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Since we have a dependency on HTML already for responseText (and elsewhere) we should just bite the bullet and add the dependency on responseXML as well and align here with XMLHttpRequest Level 2 so responseXML can remain unchanged. I.e. responseXML for a text/html resource would give a Document representing that resource. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10324] New: send() should set Content-Type to text/html for HTML documents
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10324 Summary: send() should set Content-Type to text/html for HTML documents Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: XHR 1.0 AssignedTo: ann...@opera.com ReportedBy: ann...@opera.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org When the Document object passed to send is created by createHTMLDocument() or an HTML parser the media type should not be application/xml. The Document object will be serialized according to HTML rules already, but the Content-Type set for it is currently incorrect. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10325] New: single conformance class
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10325 Summary: single conformance class Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: XHR 1.0 AssignedTo: ann...@opera.com ReportedBy: ann...@opera.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org We should drop the XML conformance class in favor of requiring XML support from everyone. XMLHttpRequest Level 2 already does this and there is no implementation that does not support XML. This only complicates keeping the two drafts in sync for no benefit. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10326] New: make user:password in URLs a SYNTAX_ERR
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10326 Summary: make user:password in URLs a SYNTAX_ERR Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: XHR 1.0 AssignedTo: ann...@opera.com ReportedBy: ann...@opera.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Currently user:password is an optional feature and I would rather kill support for it entirely than leave it as such. Now it cannot be tested basically. Can we do this? -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10327] New: supported URL schemes in open()
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10327 Summary: supported URL schemes in open() Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: XHR 1.0 AssignedTo: ann...@opera.com ReportedBy: ann...@opera.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org I would like to have clearer language for URLs regarding their supported scheme component. I.e. I would like it to be clear from the draft what happens if you use any of the following: mailto:f...@example.org; about:blank tag:example.org tel:+316... data:text/html,... My preferred solution would be to throw unless the URL scheme is one of a whitelist which contains: http https ftp file (implementation specific, must throw a SYNTAX_ERR if the current scheme is not file) We can add to this whitelist in the future, such as the blob URL scheme. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10328] New: change Accept-Charset to should not
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10328 Summary: change Accept-Charset to should not Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: XHR 1.0 AssignedTo: ann...@opera.com ReportedBy: ann...@opera.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Currently the specification states that Accept-Charset should be set as appropriate by the user agent. However, Accept-Charset is a useless header that is on its way out. Opera already dropped it from requests and Mozilla is planning to. Alternatively maybe the specification should not say anything about Accept-Charset and Accept-Encoding except that authors do not have control over them and that content-encodings used in transmission are automatically decoded by the user agent. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[XHR] Status Update
The WG has published a Candidate Recommendation draft of XMLHttpRequest recently: http://www.w3.org/TR/2010/CR-XMLHttpRequest-20100803/ My apologies for not announcing this here when it happened. As a result I worked most of last week and a bit during the weekend on a new test suite for XMLHttpRequest. The old one had become quite obsolete. I hope to put the results of that work online soon so people can take a look and maybe contribute the missing pieces. I will email about that separately once it is done. As a result of working on the test suite I found a few minor issues that would be nice to resolve (I'm not particularly interested in the solution to each of these problems, but I thought I would propose one in order to move things forward). I filed these bugs on them: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10322 http://www.w3.org/Bugs/Public/show_bug.cgi?id=10323 http://www.w3.org/Bugs/Public/show_bug.cgi?id=10324 http://www.w3.org/Bugs/Public/show_bug.cgi?id=10325 http://www.w3.org/Bugs/Public/show_bug.cgi?id=10326 http://www.w3.org/Bugs/Public/show_bug.cgi?id=10327 http://www.w3.org/Bugs/Public/show_bug.cgi?id=10328 I discussed with Art that I would not make changes to the editor's draft for non-editorial changes until the WG agrees to a change. As such I propose we have a Call for Consensus for each of the bugs above a couple of days from now when people have had a change to take initial look. Bugs with comments indicating that my solution may not be correct should be excluded from the Call for Consensus until the concerns are addressed in some way. The tentative plan is to stay in Candidate Recommendation and update the Editor's Draft with changes as the WG agrees to them. As well as maintaining a test suite and tracking implementation conformance to that test suite. Then once we have two implementations that are conforming we can have another Last Call and hopefully move straight to Proposed Recommendation as we have proven that it can be implemented in interoperable fashion. (The security considerations document will have to be done as well by then, of course.) -- Anne van Kesteren http://annevankesteren.nl/
RE: [IndexedDB] Need a method to remove a database
From: jor...@google.com [mailto:jor...@google.com] On Behalf Of Jeremy Orlow
Sent: Friday, August 06, 2010 2:34 AM
On Fri, Aug 6, 2010 at 12:37 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Aug 5, 2010 at 4:02 PM, Pablo Castro pablo.cas...@microsoft.com
wrote:
-Original Message-
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org]
On Behalf Of Jonas Sicking
Sent: Thursday, August 05, 2010 2:12 PM
I suggest we make removeDatabase (or whatever we call it) schedule a
database to be deleted, but doesn't actually delete it until all
existing connections to it are closed (though either explicit calls to
IDBDatabase.close(), or through the tab being closed).
Any calls to IDBFactory.open with the same name will hold the callback
until the removeDatabase() operation is finished. I.e. after all
existing connections are closed and the database is removed.
This is similar to how setVersion works.
If we're not going to keep it simple, then we should match the
setVersion
semantics as much as is possible. I.e. add the blocked event and
stuff like
that.
The blocked event fires on the IDBDatabase object. Do we want to
require that the database is opened before it can be removed? I don't
really feel strongly either way.
The other question is if we should fire a versionchange event on
other open IDBDatabases, like setVersion does. Or should we fire a
holy hell, your database is about to get nuked! event? The former
would keep things simpler since there is just one event to listen to.
The latter might be more correct.
/ Jonas
I like the idea of just scheduling the database to be deleted once the
last connection to it closes, and also preventing any new connection from
being established once the database has been scheduled for deletion.
This adds as little surface area as possible to the API.
If we find that that's not a good idea for some reason, I wonder if we
should unify the versionchange event and this into a single stuff
seriously changed event where subscribers need to close their handles and
let go of any assumptions they had about the database. Once they can
re-open, they need to re-establish all their context (this is already true
for a version change, we may as well extend it to database deletes and any
other future big changes to the database schema, options, etc.)
Here's my proposal, please poke holes in it:
interface IDBFactory {
...
IDBRequest deleteDatabase(in DOMString name);
...
};
When deleteDatabase is called, the given database is scheduled for
deletion. If any IDBDatabase objects are opened to the database fire a
versionchange event on those IDBDatabase objects, with a .version
set to null. If any calls to IDBFactory.open occur, stall those until
after this algorithm is finished. Note that this generally won't mean
that those open calls will fail. They'll generally will receive a
newly created database instead.
Once all existing IDBDatabase are closed (implicitly or explicitly),
the database is removed. At this point any IDBFactory.open calls are
fulfilled and a success event is fired on the returned IDBRequest.
So no blocked event is fired as I'm not sure where to fire it. I'm
also not sure that this is a big problem. I'm not even sure that
returning a IDBRequest is worth it. The only value I can see is
wanting to display to a user when a database is for sure deleted as to
allow the user to for example safely shut down the computer without
worrying that sensitive data is still in the database.
All of this sounds good to me. I'd probably still return an IDBRequest
for consistency and so that the app can get a conformation when it's really
gone. On success would fire with a null result field, I'd think.
This looks good to me too. I agree with still having deleteDatabase return an
IDBRequest so the caller can tell when the operation is done.
-pablo
Re: [XHR] Status Update
On Mon, Aug 9, 2010 at 6:05 AM, Anne van Kesteren ann...@opera.com wrote: The WG has published a Candidate Recommendation draft of XMLHttpRequest recently: http://www.w3.org/TR/2010/CR-XMLHttpRequest-20100803/ My apologies for not announcing this here when it happened. As a result I worked most of last week and a bit during the weekend on a new test suite for XMLHttpRequest. The old one had become quite obsolete. I hope to put the results of that work online soon so people can take a look and maybe contribute the missing pieces. I will email about that separately once it is done. As a result of working on the test suite I found a few minor issues that would be nice to resolve (I'm not particularly interested in the solution to each of these problems, but I thought I would propose one in order to move things forward). I filed these bugs on them: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10322 http://www.w3.org/Bugs/Public/show_bug.cgi?id=10323 http://www.w3.org/Bugs/Public/show_bug.cgi?id=10324 http://www.w3.org/Bugs/Public/show_bug.cgi?id=10325 http://www.w3.org/Bugs/Public/show_bug.cgi?id=10326 http://www.w3.org/Bugs/Public/show_bug.cgi?id=10327 http://www.w3.org/Bugs/Public/show_bug.cgi?id=10328 I discussed with Art that I would not make changes to the editor's draft for non-editorial changes until the WG agrees to a change. As such I propose we have a Call for Consensus for each of the bugs above a couple of days from now when people have had a change to take initial look. Bugs with comments indicating that my solution may not be correct should be excluded from the Call for Consensus until the concerns are addressed in some way. Some of these bugs are feature enhancements. Such as adding support for sending and receiving text/html documents. In the interest of getting us to rec as quickly as possible I suggest that these features are added to XHR L2 instead. / Jonas
[IndexedDB] question about description argument of IDBFactory::open()
Hi, While implementing IDBFactory::open(), we thought that the description argument is optional but we were surprised to find out it's actually mandatory. Is there any reason not to make this argument optional? And, assuming it is optional, should the default value be the empty string? Also, how should the null and undefined values be treated? My suggestion would be to treat them as if the argument wasn't specified, so the description of the database would not change. Thanks, Andrei
Re: [XHR] Status Update
On Mon, 09 Aug 2010 20:54:48 +0200, Jonas Sicking jo...@sicking.cc wrote: Some of these bugs are feature enhancements. Such as adding support for sending and receiving text/html documents. In the interest of getting us to rec as quickly as possible I suggest that these features are added to XHR L2 instead. Actually, by virtue of following the Document.innerHTML algorithm from HTML5 sending HTML documents is already covered for in XMLHttpRequest. It is just that the media type (as the bug indicates) is always set to application/xml rather than text/html for HTML documents. Receiving HTML documents would indeed be a newish feature, except that you already need to follow HTML5 rules to discover the character encoding for responseText, etc. so adding this did not seem like a big burden on implementations on top of which it makes sense that if you can send them (which was already possible) you can also receive them. You say such as but I believe these are the only two bugs that can be classified as such and the former is really a bug and not a new feature. -- Anne van Kesteren http://annevankesteren.nl/
RE: ACTION-568: Create an alternative mechanism for openURL and send it to the mail list (Web Applications Working Group)
Marcos, That method works for well-know URI schemes except for http:// and https://. The openURL() method would have launched the browser for those schemes, and we still need a method to do that. I was not able to attend the last week's call and was not aware there was a plan to remove the openURL() method. This leaves a major hole in the functionality we need from the Widgets specs (ability to launch the browser when necessary/desirable, which is something only known by the widget - e.g. it needs to invoke a resource that it knows needs to be handled through the browser or other registered URI scheme handler). Thanks, Bryan Sullivan | ATT -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Marcos Caceres Sent: Friday, August 06, 2010 8:56 AM To: Web Applications Working Group WG Subject: Re: ACTION-568: Create an alternative mechanism for openURL and send it to the mail list (Web Applications Working Group) On 8/5/10 3:30 PM, Web Applications Working Group Issue Tracker wrote: ACTION-568: Create an alternative mechanism for openURL and send it to the mail list (Web Applications Working Group) http://www.w3.org/2008/webapps/track/actions/568 On: Marcos Caceres Due: 2010-08-12 If you do not want to be notified on new action items for this group, please update your settings at: http://www.w3.org/2008/webapps/track/users/39125#settings The proposal is simply to use HTML a element. So, instead of: widget.openURL(sms:+123456789101112); It would just be: a href=sms:+123456789101112Send and SMS/a Then you can use the .click() element to open links programmatically (on trusted URI types) or only respond to explicit user interaction (the user clicks on the link to do something). Kind regards, Marcos -- Marcos Caceres Opera Software
Re: [IndexedDB] question about description argument of IDBFactory::open()
On Mon, Aug 9, 2010 at 1:13 PM, Andrei Popescu andr...@google.com wrote: Hi, While implementing IDBFactory::open(), we thought that the description argument is optional but we were surprised to find out it's actually mandatory. Is there any reason not to make this argument optional? And, assuming it is optional, should the default value be the empty string? Also, how should the null and undefined values be treated? My suggestion would be to treat them as if the argument wasn't specified, so the description of the database would not change. I agree optional makes sense, defaulting to empty string. null and undefined should IMHO be defined by webidl. I forget what the syntax is, but I believe it's possible to enforce that the passed in value is converted to a real string before passed to the actual function. / Jonas
Re: [IndexedDB] question about description argument of IDBFactory::open()
On 8/9/2010 1:13 PM, Andrei Popescu wrote: While implementing IDBFactory::open(), we thought that the description argument is optional but we were surprised to find out it's actually mandatory. Is there any reason not to make this argument optional? And, assuming it is optional, should the default value be the empty string? Also, how should the null and undefined values be treated? My suggestion would be to treat them as if the argument wasn't specified, so the description of the database would not change. I think we want something there, because that is likely what the user agent is going to tell the user when it has to ask for space (if the user agent limits) or display if the user wants to see what a site is storing locally. I think we should probably enforce a non-null string too because of this, although a null string for future connections meaning do not change seem fine to me. I started a bug [1] a while back about what to do if it changes, but it went nowhere. Cheers, Shawn [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9562 smime.p7s Description: S/MIME Cryptographic Signature
Re: [IndexedDB] question about description argument of IDBFactory::open()
I'm pretty sure opening a database with a different description is actually already specified: the new one takes precedent. Take a look at the algorithm for database opening; I'm pretty sure it's there. When talking to Andrei earlier tonight I thought we'd probably want to make it optional, but now I'm thinking maybe we shouldn't. You're right, Shawn, that the description can be useful for many reasons. And although it seems redundant for a developer to pass in the description every time, I actually can't think of any reason why a developer wouldn't want to. So, just to make sure we always have a description handy, it seems like maybe we should keep it non-optional. As for Jonas' comment about IDL: I believe the default is for null to turn into null and undefined to turn into undefined, but IDL has ways of overriding the behavior. To me, null and undefined as database descriptions are pretty useless, but I don't see how we can spec that descriptions must be useful. Off the top of my head, it seems as though we could get away with making all strings in the IndexedDB treat null/undefined as an empty string, but would this be consistent with other specs in a predictable way? I'm not sure. But I think consistency/predictability for the user is the most important consideration. J On Mon, Aug 9, 2010 at 9:42 PM, Shawn Wilsher sdwi...@mozilla.com wrote: On 8/9/2010 1:13 PM, Andrei Popescu wrote: While implementing IDBFactory::open(), we thought that the description argument is optional but we were surprised to find out it's actually mandatory. Is there any reason not to make this argument optional? And, assuming it is optional, should the default value be the empty string? Also, how should the null and undefined values be treated? My suggestion would be to treat them as if the argument wasn't specified, so the description of the database would not change. I think we want something there, because that is likely what the user agent is going to tell the user when it has to ask for space (if the user agent limits) or display if the user wants to see what a site is storing locally. I think we should probably enforce a non-null string too because of this, although a null string for future connections meaning do not change seem fine to me. I started a bug [1] a while back about what to do if it changes, but it went nowhere. Cheers, Shawn [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9562
RE: [XHR] Status Update
Anne, Are you saying that it should not be possible now (with XHR L1) to receive HTML files via XHR (Receiving HTML documents would indeed be a newish feature ) ? This does actually work for me in XHR L1, so I'm unclear about what you mean below. Thanks, Bryan Sullivan | ATT -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Anne van Kesteren Sent: Monday, August 09, 2010 1:25 PM To: Jonas Sicking Cc: WebApps WG Subject: Re: [XHR] Status Update On Mon, 09 Aug 2010 20:54:48 +0200, Jonas Sicking jo...@sicking.cc wrote: Some of these bugs are feature enhancements. Such as adding support for sending and receiving text/html documents. In the interest of getting us to rec as quickly as possible I suggest that these features are added to XHR L2 instead. Actually, by virtue of following the Document.innerHTML algorithm from HTML5 sending HTML documents is already covered for in XMLHttpRequest. It is just that the media type (as the bug indicates) is always set to application/xml rather than text/html for HTML documents. Receiving HTML documents would indeed be a newish feature, except that you already need to follow HTML5 rules to discover the character encoding for responseText, etc. so adding this did not seem like a big burden on implementations on top of which it makes sense that if you can send them (which was already possible) you can also receive them. You say such as but I believe these are the only two bugs that can be classified as such and the former is really a bug and not a new feature. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] Status Update
On Mon, 09 Aug 2010 23:37:25 +0200, SULLIVAN, BRYAN L (ATTCINW) bs3...@att.com wrote: Are you saying that it should not be possible now (with XHR L1) to receive HTML files via XHR (Receiving HTML documents would indeed be a newish feature ) ? This does actually work for me in XHR L1, so I'm unclear about what you mean below. It is not supported by the specification as it stands today, no, and never was, and is not supported by all implementations. However, I think we should add it, as I explained in my previous email. -- Anne van Kesteren http://annevankesteren.nl/
RE: ACTION-568: Create an alternative mechanism for openURL and send it to the mail list (Web Applications Working Group)
Quoting SULLIVAN, BRYAN L (ATTCINW) bs3...@att.com: Marcos, That method works for well-know URI schemes except for http:// and https://. The openURL() method would have launched the browser for those schemes, and we still need a method to do that. No. We dont. Please see my proposal. I was not able to attend the last week's call and was not aware there was a plan to remove the openURL() method. This leaves a major hole in the functionality we need from Major hole? No one has yet presented a single use case that could not be done with an a element. the Widgets specs (ability to launch the browser when necessary/desirable, which is something only known by the widget - e.g. it needs to invoke a resource that it knows needs to be handled through the browser or other registered URI scheme handler). See my proposal. Its not needed. Thanks, Bryan Sullivan | ATT -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Marcos Caceres Sent: Friday, August 06, 2010 8:56 AM To: Web Applications Working Group WG Subject: Re: ACTION-568: Create an alternative mechanism for openURL and send it to the mail list (Web Applications Working Group) On 8/5/10 3:30 PM, Web Applications Working Group Issue Tracker wrote: ACTION-568: Create an alternative mechanism for openURL and send it to the mail list (Web Applications Working Group) http://www.w3.org/2008/webapps/track/actions/568 On: Marcos Caceres Due: 2010-08-12 If you do not want to be notified on new action items for this group, please update your settings at: http://www.w3.org/2008/webapps/track/users/39125#settings The proposal is simply to use HTML a element. So, instead of: widget.openURL(sms:+123456789101112); It would just be: a href=sms:+123456789101112Send and SMS/a Then you can use the .click() element to open links programmatically (on trusted URI types) or only respond to explicit user interaction (the user clicks on the link to do something). Kind regards, Marcos -- Marcos Caceres Opera Software
Re: [IndexedDB] question about description argument of IDBFactory::open()
On Mon, Aug 9, 2010 at 9:57 PM, Jeremy Orlow jor...@chromium.org wrote: I'm pretty sure opening a database with a different description is actually already specified: the new one takes precedent. Take a look at the algorithm for database opening; I'm pretty sure it's there. When talking to Andrei earlier tonight I thought we'd probably want to make it optional, but now I'm thinking maybe we shouldn't. You're right, Shawn, that the description can be useful for many reasons. And although it seems redundant for a developer to pass in the description every time, I actually can't think of any reason why a developer wouldn't want to. Actually, I think it's pretty inconvenient to have to specify a description every time, especially since I am not sure developers would want to change the description very often. I think we should allow a null string for future connections as Shawn suggested. Thanks, Andrei
[Bug 10052] Specify setVersion details
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10052 Andrei Popescu andr...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Andrei Popescu andr...@google.com 2010-08-09 22:25:09 --- Fixed in http://dvcs.w3.org/hg/IndexedDB/rev/e03a6bfd0c2e -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10337] New: add [Supplemental] support
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10337 Summary: add [Supplemental] support Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: WebIDL AssignedTo: c...@mcc.id.au ReportedBy: i...@hixie.ch QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org For specification process reasons, some interface definitions don't get organised the same way as we want from implementations. I've assumed that [Supplemental] will exist, and used it as follows: - Setting [Supplemental, NoInterfaceObject] on an interface X with no ancestor and then saying: Y implements X; ...implies that the members in X are imported into Y as if the definition of Y always had X in it. - Setting [Supplemental, NoInterfaceObject] on an interface X that inherits from Y implies that there are objects called Y that have all the members of X and Y with X not appearing on the prototype chain. - Setting [Supplemental] on an interface that has the same name as an interface definition without [Supplemental]. The distinction between these cases is that I have three different cases where I need to do this. One is where I have some objects, e.g. Window, that are made up of APIs defined in other specs, and those APIs are also used by other interfaces. So I define Window, and then other specs slide stuff into Window, and slide stuff into other interfaces (like Worker- related ones). Another is WorkerGlobalScope, which I want to be the name of the interface implementing the global scope for workers, but there are two types of workers, and they have slightly different interfaces. And the third is the deprecated interfaces, where one interface, e.g. HTMLAnchorElement, is defined in two places. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
RE: ACTION-568: Create an alternative mechanism for openURL andsend it to the mail list (Web Applications Working Group)
Marcos, You're saying if I understand you, that if I create an anchor: a href=http://mywidget.com;Click to load the online version/a That when the user clicks this link it will launch the browser, instead of retrieving the online version of my widget (or at least of this page of it)? This would in essence prevent the use of anchors anywhere in widgets, where the developer's intent was to have the web runtime retrieve and present the content directly, within the widget's context. For example, if I want to use an iframe to pull in some external content and then allow the user to navigate the content within the iframe - in your proposal the first link they hit in the iframe would take them out of the widget and into the browser. Not the desired experience IMO. Or do I misunderstand your proposal? Thanks, Bryan Sullivan | ATT -Original Message- From: marc...@opera.com [mailto:marc...@opera.com] Sent: Monday, August 09, 2010 2:51 PM To: SULLIVAN, BRYAN L (ATTCINW) Cc: Web Applications Working Group WG Subject: RE: ACTION-568: Create an alternative mechanism for openURL andsend it to the mail list (Web Applications Working Group) Quoting SULLIVAN, BRYAN L (ATTCINW) bs3...@att.com: Marcos, That method works for well-know URI schemes except for http:// and https://. The openURL() method would have launched the browser for those schemes, and we still need a method to do that. No. We dont. Please see my proposal. I was not able to attend the last week's call and was not aware there was a plan to remove the openURL() method. This leaves a major hole in the functionality we need from Major hole? No one has yet presented a single use case that could not be done with an a element. the Widgets specs (ability to launch the browser when necessary/desirable, which is something only known by the widget - e.g. it needs to invoke a resource that it knows needs to be handled through the browser or other registered URI scheme handler). See my proposal. Its not needed. Thanks, Bryan Sullivan | ATT -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Marcos Caceres Sent: Friday, August 06, 2010 8:56 AM To: Web Applications Working Group WG Subject: Re: ACTION-568: Create an alternative mechanism for openURL and send it to the mail list (Web Applications Working Group) On 8/5/10 3:30 PM, Web Applications Working Group Issue Tracker wrote: ACTION-568: Create an alternative mechanism for openURL and send it to the mail list (Web Applications Working Group) http://www.w3.org/2008/webapps/track/actions/568 On: Marcos Caceres Due: 2010-08-12 If you do not want to be notified on new action items for this group, please update your settings at: http://www.w3.org/2008/webapps/track/users/39125#settings The proposal is simply to use HTML a element. So, instead of: widget.openURL(sms:+123456789101112); It would just be: a href=sms:+123456789101112Send and SMS/a Then you can use the .click() element to open links programmatically (on trusted URI types) or only respond to explicit user interaction (the user clicks on the link to do something). Kind regards, Marcos -- Marcos Caceres Opera Software
RE: [XHR] Status Update
Well at least it works in Firefox, Safari, Opera, and Chrome. With that broad support, I imagine that removing this defacto feature in XHR L2 would cause a lot of heartburn for developers who probably rely upon it today. Thanks, Bryan Sullivan | ATT -Original Message- From: Anne van Kesteren [mailto:ann...@opera.com] Sent: Monday, August 09, 2010 2:49 PM To: Jonas Sicking; SULLIVAN, BRYAN L (ATTCINW) Cc: WebApps WG Subject: Re: [XHR] Status Update On Mon, 09 Aug 2010 23:37:25 +0200, SULLIVAN, BRYAN L (ATTCINW) bs3...@att.com wrote: Are you saying that it should not be possible now (with XHR L1) to receive HTML files via XHR (Receiving HTML documents would indeed be a newish feature ) ? This does actually work for me in XHR L1, so I'm unclear about what you mean below. It is not supported by the specification as it stands today, no, and never was, and is not supported by all implementations. However, I think we should add it, as I explained in my previous email. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] Status Update
On Mon, Aug 9, 2010 at 5:13 PM, SULLIVAN, BRYAN L (ATTCINW) bs3...@att.com wrote: Well at least it works in Firefox, Safari, Opera, and Chrome. With that broad support, I imagine that removing this defacto feature in XHR L2 would cause a lot of heartburn for developers who probably rely upon it today. This is not correct. I can't speak for the other browsers, but Firefox does not support loading HTML documents using XMLHttpRequest. We never hook up any other type of parser than an XML parser. And if the Content-Type of the response is text/html we don't hook up any parser at all. / Jonas
RE: [XHR] Status Update
Jonas,
With the code below, I have no problem doing this in Firefox. Notes:
- asyncXHR is a typical XHR wrapper function, not included here for
brevity.
- The key statement below is:
document.getElementById(text).innerHTML = Headers:br +
hdrs + br/ + xhr.responseText;
With this, Firefox correctly renders the retrieved HTML content
into the element text.
function gotResponse(xhr) {
var extref = document.getElementById(extref);
extref.innerHTML = ;
extref.setAttribute('src', );
var hdrs = xhr.getAllResponseHeaders();
var type = xhr.getResponseHeader(Content-Type);
if (type === text/plain) {
document.getElementById(text).innerHTML =
Headers:br + hdrs + br/pre + xhr.responseText + /pre;
}
else {
document.getElementById(text).innerHTML =
Headers:br + hdrs + br/ + xhr.responseText;
}
}
function loadFile(url,inline) {
var encurl = encodeURI(url);
if (inline) {
document.getElementById(text).innerHTML = loadFile:
+ url;
asyncXHR('GET',encurl,,'*/*',,gotResponse);
}
else {
var extref = document.getElementById(extref);
document.getElementById(text).innerHTML = loadFile:
+ url + brFile should appear below;
extref.setAttribute('src', encurl);
}
}
Thanks,
Bryan Sullivan | ATT
-Original Message-
From: Jonas Sicking [mailto:jo...@sicking.cc]
Sent: Monday, August 09, 2010 5:23 PM
To: SULLIVAN, BRYAN L (ATTCINW)
Cc: Anne van Kesteren; WebApps WG
Subject: Re: [XHR] Status Update
On Mon, Aug 9, 2010 at 5:13 PM, SULLIVAN, BRYAN L (ATTCINW)
bs3...@att.com wrote:
Well at least it works in Firefox, Safari, Opera, and Chrome.
With that broad support, I imagine that removing this defacto feature
in
XHR L2 would cause a lot of heartburn for developers who probably rely
upon it today.
This is not correct. I can't speak for the other browsers, but Firefox
does not support loading HTML documents using XMLHttpRequest. We never
hook up any other type of parser than an XML parser. And if the
Content-Type of the response is text/html we don't hook up any
parser at all.
/ Jonas
Re: [XHR] Status Update
On Tue, 10 Aug 2010 05:19:10 +0200, SULLIVAN, BRYAN L (ATTCINW) bs3...@att.com wrote: With the code below, I have no problem doing this in Firefox. That code is not using responseXML... -- Anne van Kesteren http://annevankesteren.nl/
RE: [XHR] Status Update
Sorry, the statement Receiving HTML documents would indeed be a newish feature implied that it was not possible at all - if it is possible at least using responseText (which it clearly is), and just dumping the text into an element allows it to be accessed via the DOM, then for my purposes it is supported. Thanks for the clarification. Thanks, Bryan Sullivan | ATT -Original Message- From: Anne van Kesteren [mailto:ann...@opera.com] Sent: Monday, August 09, 2010 9:51 PM To: Jonas Sicking; SULLIVAN, BRYAN L (ATTCINW) Cc: WebApps WG Subject: Re: [XHR] Status Update On Tue, 10 Aug 2010 05:19:10 +0200, SULLIVAN, BRYAN L (ATTCINW) bs3...@att.com wrote: With the code below, I have no problem doing this in Firefox. That code is not using responseXML... -- Anne van Kesteren http://annevankesteren.nl/
