Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move event-firing into Storage interface instead of action at a distance #3210

Closed
domenic opened this issue Nov 7, 2017 · 0 comments · Fixed by #5560
Closed

Move event-firing into Storage interface instead of action at a distance #3210

domenic opened this issue Nov 7, 2017 · 0 comments · Fixed by #5560
Labels
clarification Standard could be clearer topic: storage

Comments

@domenic
Copy link
Member

domenic commented Nov 7, 2017

Currently the firing of storage events is done at a distance, via these paragraphs:

When the setItem(), removeItem(), and clear() methods are called on a Storage object x that is associated with a session storage area, if the methods did not throw an exception or "do nothing" as defined above, then for every Document object whose Window object's sessionStorage attribute's Storage object is associated with the same storage area, other than x, send a storage notification.

When the setItem(), removeItem(), and clear() methods are called on a Storage object x that is associated with a local storage area, if the methods did not throw an exception or "do nothing" as defined above, then for every Document object whose Window object's localStorage attribute's Storage object is associated with the same storage area, other than x, send a storage notification.

These should move into the algorithms for setItem/removeItem/clear, and use actual if statements, and so on.

Formalizing this probably requires some kind of mapping back from storage areas to Storage instances.

@domenic domenic added the clarification Standard could be clearer label Nov 7, 2017
annevk added a commit that referenced this issue May 18, 2020
This makes use of the new primitives in the Storage Standard.

Closes #3210, closes #3283, closes #4650, and closes #5463.
@annevk annevk mentioned this issue May 18, 2020
3 tasks
annevk added a commit that referenced this issue May 18, 2020
This makes use of the new primitives in the Storage Standard.

Closes #3210, closes #3283, closes #4650, and closes #5463.
annevk added a commit that referenced this issue Jun 5, 2020
This makes use of the new primitives in the Storage Standard.

Closes #3210, closes #3283, closes #4650, and closes #5463.
annevk added a commit that referenced this issue Jul 8, 2020
Use the new primitives in the Storage Standard.

Closes #3209, closes #3210, closes #3283, closes #4650, closes #5463, and closes #5498.
annevk added a commit that referenced this issue Jul 10, 2020
Use the new primitives in the Storage Standard.

Closes #3209, closes #3210, closes #3283, closes #4650, closes #5463, and closes #5498.
mfreed7 pushed a commit to mfreed7/html that referenced this issue Sep 11, 2020
Use the new primitives in the Storage Standard.

Closes whatwg#3209, closes whatwg#3210, closes whatwg#3283, closes whatwg#4650, closes whatwg#5463, and closes whatwg#5498.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification Standard could be clearer topic: storage
Development

Successfully merging a pull request may close this issue.

2 participants