Re: [Bug 12111] New: spec for Storage object getItem(key) method does not match implementation behavior
All - given that addressing 12111 is a low priority for Ian, one way forward is for someone else to create a concrete proposal. BTW, I don't think anyone from Opera or Safari has commented on bug 12111 and if that is the case, it would be good to get their comments. -AB On Jun/14/2011 12:21 AM, ext Jeremy Orlow wrote: On Sun, Jun 12, 2011 at 2:58 PM, Aryeh Gregor simetrical+...@gmail.com mailto:simetrical%2b...@gmail.com wrote: On Sat, Jun 11, 2011 at 3:10 PM, Ian Hickson i...@hixie.ch mailto:i...@hixie.ch wrote: The particular issue in question isn't a particularly important one. The spec describes a superset of implementations, and is a logical direction for the spec to go. (Even within the process, there's no reason we couldn't go to LC with it as is.) Implementations are the ultimate guide here, when this issue bubbles up to the top of the priority list then it'll get resolved one way or the other based on what they do and want. The spec does not describe a superset of implementations. It describes behavior that contradicts what implementations actually do. For instance, if you set localStorage.foo = false, the spec requires localStorage.foo to return boolean false. In implementations, it will return the string false, which evaluates to boolean true. It is not realistically going to be possible for implementations to change to what the spec currently says. Furthermore, we have some implementers from each of IE, Firefox, and Chrome saying that they don't intend to change to match the spec, and no implementers saying they intend to change to match the spec. That should serve to indicate that the spec is broken and needs to change, process issues aside. I don't see what would take a few hours to change here. Change all the relevant types from any to DOMString, remove all the stuff about structured clones, and let WebIDL do the work. That's immediately much closer to browser behavior than the current spec. I was about to write an email that said about the exact same thing. Then I saw Aryeh beat me to it. J
Re: [Bug 12111] New: spec for Storage object getItem(key) method does not match implementation behavior
On Jun/11/2011 3:57 PM, ext James Robinson wrote: In my opinion, the only thing left to be done with localStorage is to write it off as an unfortunate failure, learn our lesson, and move on. This may not be relevant to the processes you are trying to follow. Stopping work on Web Storage is indeed another option for this spec. I don't know the level of support for that option, especially since the Storage spec is a normative dependency for at least one other spec. -AB
Re: [webstorage] origin security check
On 14 Jun 2011, at 06:28, Marcos Caceres wrote: On Monday, June 13, 2011, Ian Hickson i...@hixie.ch wrote: On Mon, 13 Jun 2011, Marcos Caceres wrote: I thought maybe I could get away with: When getting or setting the preferences attribute, if the origin of a widget instance is mutable (e.g., if the user agent allows document.domain to be dynamically changed), then the user agent must perform the object initialization steps of [Web Storage] substituting the preferences attribute for the localStorage attribute where appropriate. But maybe I'll just do a copy and paste and just replace the appropriate bits of text. I guess that could work. By the way, how are you resolving the multiple-thread problem here? (Since you're introducing a new API, it presumably doesn't have to have the same bug as the localStorage API, where we're stuck for legacy reasons and are basically forced to either have a cross-thread blocking API or a racy API, depending on how it's implemented, both of which suck.) We are not solving it:( As widgets run as a single process, each instance in a unique origin, don't share data/cache with browser tabs/windows or other widgets, this issue does not come up much... At least no one has complained to me about it. We've seen clients setting the same preference in different threads resulting in a consistency problem, however we basically go with the view that its something we just deal with - i.e. its not guaranteed to be consistent but we make best effort. In general use in a widget context its not going to be frequent or critical - we only come across it in a testing context by creating duplicate views of a widget instance, showing them alongside each other, which is a pretty pointless thing for a user to do. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- Marcos Caceres http://datadriven.com.au
Re: [FileAPI] Updates to FileAPI Editor's Draft
Sorry if these have all been discussed before. I just read the File API for the first time and 2 random questions popped in my head. 1) If I'm using readAsText with a particular encoding and the data in the file is not actually in that encoding such that code points in the file can not be mapped to valid code points what happens? Is that implementation specific or is it specified? I can imagine at least 3 different behaviors. 2) If I'm reading using readAsText a multibyte encoding (utf-8, shift-jis, etc..) is it implementation dependent whether or not it can return partial characters when returning partial results during reading? In other words, Let's say the next character in a file is a 3 byte code point but the reader has only read 2 of those 3 bytes so far. Is implementation dependent whether result includes those 2 bytes before reading the 3rd byte or not?
[indexeddb] IDBIndex.getKey incorrect description.
The description for the IDBIndex.getKey tells us to use the steps for retrieving a value from an index as the operation. These steps seem to deal with how to retrieve values and not keys. It seems, we need a new section similar to this one that explains how to retrieve a primary key from an index. The main issue we are having is knowing what to return when there are no records that match the key parameter. For example, imagine that we create an index on an empty object store and immediately call getKey. We believe that this should call the onsuccess handler with a result set to undefined. This seems to match the spirit of the note under IDBIndex.getKey. I believe this will also affect the IDBIndexSync.getKey. Do you agree? Israel
RE: publish Last Call Working Draft of Web Workers; deadline March 7
On Wed, 9 Mar 2011, Adrian Bateman wrote:
Based on our understanding of the web worker lifetime model (Section
4.4), dedicated workers are allowed to enter into an orphaned state
where they have a message port that is keeping them alive (see example
at the end of this feedback).
I do not believe this is entirely accurate. It's the combination of having
a document owner and having something that protects it (like a port) that
keeps a worker alive.
We can imagine scenarios where the
orphaned workers are still able to provide results to a document
(e.g., via connecting to a shared worker), however these use cases 1)
seem largely irrelevant, 2) can be handled by shared workers if needed
and 3) overly complicate the implementation (in our analysis) of
dedicated workers.
I strongly disagree with point (1). The great thing about the
MessageChannel / Web Worker model is that you can create a worker, have it
vend a port, and then forget about the worker but still have everything
work. It is an absolutely key feature of the API. I don't see how shared
workers would do this better.
Could you elaborate on why it complicates the implementation?
We note that no browser appears to implement the lifetime model as
specified in the latest editor's draft (that we can test).
Do you have a test I could examine to test this?
1 - Lifetime based on a dedicated worker's document reachability: This
alternate lifetime model keeps a dedicated worker alive until it can no
longer communicate with the document(s) to which it is associated
(through its implicit port or any other port). This proposed lifetime
model is based on graph reachability, where the nodes in the graph are
web workers and the arcs in the graph are implicit and explicit message
ports owned by a worker (i.e., the worker's ports). A dedicated
worker's lifetime is managed by whether the dedicated worker can reach
the document(s) in its list of the worker's documents. See the example
at the end for how the currently speced lifetime model changes with this
approach.
It has to be more than just reachability of the original document, because
otherwise if an iframe vends a port from a worker to its parent, and then
drops all references, this would expose specifics about GC behaviour.
2 - Lifetime that prevents orphaning dedicated workers: In this
alternate lifetime model, orphaned dedicated workers are never allowed,
and the lifetime of the worker is strictly controlled by its implicit
port. Therefore, whenever a worker creates another worker, if the
parent worker is terminated or closed, then the child worker will be
terminated or closed as well (preventing the child from becoming an
orphan). This model is enforced regardless of other message ports that
the child may have.
This doesn't seem significantly simpler than what we have now, for
implementations (it's just keeping track of one port instead of a list),
while being significantly less useful for authors (no fire-and-forget
model is possible). Since fire-and-forget is an important use case, I do
not believe we should do this.
Example that creates an orphaned dedicated workers:
Steps:
1. Document 'D' creates dedicated worker 'W1'
2. Dedicated worker W1 creates a dedicated worker 'W2'
3. Document 'D' creates dedicated worker 'W3'
4. Dedicated worker W3 creates a dedicated worker 'W4'
(At this point W1 and W3 are parent workers and W2 and W4 are child
workers.)
5. W1 creates a message channel and passes the channel's ports to document
'D' and 'W2'
6. W3 creates a message channel and passes the channel's ports to document
'D' and 'W4'
('D' now has an independent message port for W2 and W4.)
7. Document 'D' creates a message channel and passes the channel's ports to
'W2' and 'W4'
(W2 and W4 now have a direct communication channel between themselves.)
8. Document 'D' terminates worker 'W1'
(Terminating W1 causes all W1's ports to be disentangled [step 15 of
section 4.5
processing model] which effects W2's implicit port; however, W2 is not
terminated
because it is still considered a protected worker, since its list of
the worker's
ports is not empty.)
9. Document 'D' terminates worker 'W3'
('D' still has communication ports with W2 and W4 and can test that they
are still
alive. W2 and W4 are now orphaned from their original creator, but
still have a
connection to the document 'D'.)
10. Document 'D' closes the port connected to 'W2'
(W2 is now only connected via a message port to W4, and can send
information to
'D' via W4.)
11. Document 'D' closes the port connected to 'W4'
(Document 'D' now has *no* connections to W2 or W4-those workers are
completely
orphaned from it. However, W2 and W4 are still alive because they are
protected
since they have a message port connection to each
FW: publish Last Call Working Draft of Web Workers; deadline March 7
From: Ian Hickson [mailto:i...@hixie.ch]
Sent: Tuesday, June 14, 2011 12:19 PM
On Wed, 9 Mar 2011, Adrian Bateman wrote:
Based on our understanding of the web worker lifetime model (Section
4.4), dedicated workers are allowed to enter into an orphaned state
where they have a message port that is keeping them alive (see example
at the end of this feedback).
I do not believe this is entirely accurate. It's the combination of having
a document owner and having something that protects it (like a port) that
keeps a worker alive.
I was just simplifying, but you are correct. It's guaranteed to be alive while
it is protected.
We can imagine scenarios where the
orphaned workers are still able to provide results to a document
(e.g., via connecting to a shared worker), however these use cases 1)
seem largely irrelevant, 2) can be handled by shared workers if needed
and 3) overly complicate the implementation (in our analysis) of
dedicated workers.
I strongly disagree with point (1). The great thing about the
MessageChannel / Web Worker model is that you can create a worker, have it
vend a port, and then forget about the worker but still have everything
work. It is an absolutely key feature of the API. I don't see how shared
workers would do this better.
Could you elaborate on why it complicates the implementation?
We imagine that being able to cascade-delete workers when an owning
worker/document is closed is easier than explicitly managing each worker's
lifetime separately. However, an actual implementation would be required to
know for sure. I deduce this based on Opera's choice of implementation.
We note that no browser appears to implement the lifetime model as
specified in the latest editor's draft (that we can test).
Do you have a test I could examine to test this?
We tried a scenario similar to the one described below:
1. D creates W1
2. W1 creates W2
3. Message channel M1 established between D and W2
4. W1 is closed (via close() or by terminate())
5. D uses M1 to try and get a response from W2
If so, test passes
If not, test fails (when W1 closed, it took W2 with it)
1 - Lifetime based on a dedicated worker's document reachability:
This alternate lifetime model keeps a dedicated worker alive until it
can no longer communicate with the document(s) to which it is
associated (through its implicit port or any other port). This
proposed lifetime model is based on graph reachability, where the
nodes in the graph are web workers and the arcs in the graph are
implicit and explicit message ports owned by a worker (i.e., the
worker's ports). A dedicated worker's lifetime is managed by whether the
dedicated worker can reach
the document(s) in its list of the worker's documents. See the
example at the end for how the currently speced lifetime model changes
with this approach.
It has to be more than just reachability of the original document, because
otherwise if an iframe vends a port from a worker to its parent, and then
drops all references, this would expose specifics about GC behaviour.
2 - Lifetime that prevents orphaning dedicated workers: In this
alternate lifetime model, orphaned dedicated workers are never
allowed, and the lifetime of the worker is strictly controlled by its
implicit port. Therefore, whenever a worker creates another worker, if
the parent worker is terminated or closed, then the child worker
will be terminated or closed as well (preventing the child from
becoming an orphan). This model is enforced regardless of other
message ports that the child may have.
This doesn't seem significantly simpler than what we have now, for
implementations (it's just keeping track of one port instead of a list),
while being significantly less useful for authors (no fire-and-forget
model is possible). Since fire-and-forget is an important use case, I do
not believe we should do this.
Indeed the fire-and-forget model was raised as a valid scenario in a different
thread.
Example that creates an orphaned dedicated workers:
Steps:
1. Document 'D' creates dedicated worker 'W1'
2. Dedicated worker W1 creates a dedicated worker 'W2'
3. Document 'D' creates dedicated worker 'W3'
4. Dedicated worker W3 creates a dedicated worker 'W4'
(At this point W1 and W3 are parent workers and W2 and W4 are
child workers.)
5. W1 creates a message channel and passes the channel's ports to
document 'D' and 'W2'
6. W3 creates a message channel and passes the channel's ports to
document 'D' and 'W4'
('D' now has an independent message port for W2 and W4.)
7. Document 'D' creates a message channel and passes the channel's
ports to 'W2' and 'W4'
(W2 and W4 now have a direct communication channel between
themselves.)
8. Document 'D' terminates worker 'W1'
(Terminating W1 causes all W1's ports to be disentangled [step 15 of
section 4.5
processing model] which effects W2's implicit port; however, W2 is
not terminated
