StorageMap.StorageEntryIterator#remove() - Issues with order?

[Andreas Kohn]

Hi,

while reading through the GWT StorageMap class to learn more about using HTML 5 local storage I noticed that the StorageEntryIterator#remove() method seems to assume a stable order of the keys in the local storage, i.e. that removing a key via the iterator does not change the order of the iteration, and the next unvisited key has simply the same index as the now-removed key.

According to http://dev.w3.org/html5/webstorage/#dom-storage-key this doesn't seem to be a good assumption: the order is explicitly allowed to change when the number of keys change,
> The key(n) method must return the name of the nth key in the list. The order of keys is user-agent defined, but must be consistent within an object so long as the number of keys doesn't change. (Thus, adding or removing a key may change the order of the keys, but merely changing the value of an existing key must not.) If n is greater than or equal to the number of key/value pairs in the object, then this method must return null.

Has this behavior ever been observed in the wild, or am I missing something here?

--
Andreas

[Jens]

Looks like you are right and the iterator does not account for such a behavior in case of remove(). If remove() can really result in a different key ordering then iteration can fail to work properly. Adding an element to the underlying collection while iterating is not an issue as the Iterator JavaDoc/Contract already defines that iteration behavior is undefined if the underlying collection is modified by other means than Iterator.remove().

I think GWT has been lucky here so far and browsers do not re-order existing storage entries if you remove a key/value pair. Also the key(n) doc says:

The supported property names on a Storage object are the keys of each key/value pair currently present in the list associated with the object, in the order that the keys were last added to the storage area.

I am wondering if this can be useful for an alternative iterator implementation as this sentence defines an ordering which should not change when removing items.

-- J.

[Andreas Kohn]

Should I open an issue for this?

On the question of using the other order guarantee, I guess this depends on how reliably that is actually implemented in the browsers :)

--

Andreas

--
You received this message because you are subscribed to a topic in the Google Groups "Google Web Toolkit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/b6SLntTyTsU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

[Jens]

Should I open an issue for this?

Sure. I don't think the current implementation will change in the near future (as it seems to work in all browsers nowadays) but at least that problem will be tracked, can be found by others if it becomes relevant and can be used to discuss alternative implementations.

-- J.

[Andreas Kohn]

Hi,

there we go:
https://code.google.com/p/google-web-toolkit/issues/detail?id=8544

--

Andreas

--