[Webkit-unassigned] [Bug 211503] New: DOM storage event is raised on the same window that called localStorage.setItem or localStorage.removeItem. By HTML live spec, it should only be raised on the other windows that share the same localStorage instance.
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Wed May 6 03:47:43 PDT 2020
https://bugs.webkit.org/show_bug.cgi?id=211503
Bug ID: 211503
Summary: DOM storage event is raised on the same window that
called localStorage.setItem or
localStorage.removeItem. By HTML live spec, it should
only be raised on the other windows that share the
same localStorage instance.
Product: WebKit
Version: Safari 13
Hardware: All
OS: All
Status: NEW
Severity: Normal
Priority: P2
Component: WebKit Misc.
Assignee: webkit-unassigned at lists.webkit.org
Reporter: pirimoglu at hotmail.com
With Safari 13.1 update, DOM storage event is being raised at the same window that has caused the storage event to happen. This is a behavior difference from earlier versions of Safari, and is not complaint with the HTML Living Standard specification on this. The standard spec at https://html.spec.whatwg.org/multipage/webstorage.html#localStorageEvent says this for localStorage events:
"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 relevant global object's localStorage attribute's Storage object is associated with the same storage area, other than x, send a storage notification."
And says this for sessionStorage events:
"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 relevant global object's sessionStorage attribute's Storage object is associated with the same storage area, other than x, send a storage notification."
For both localStorage and sessionStorage, the a "storage notification" should be sent for every document whose corresponding storage object is the same one as the current document, which they call "x", but not on "x". So the document who made the setItem(), removeItem() or clear() methods, should not receive the storage notification (event). Only others that are in the same session who share the same storage object should receive the notification.
Before Safari 13.1 it was behaving this way. With Safari 13.1 it is not behaving this way, the document that called the methods that causes the notification (event) is also receiving the event.
To give example in js code:
Assume document A has this code:
window.addEventListener("storage", storageEventHandler);
function storageEventHandler(e) {
console.log("A received " + e.key);
}
function AddToLocalStorage(key, value)
{
localStorage.setItem(key, value);
}
And document B has this code, which is loaded from same origin/site as document A, so they share session and so localStorage:
window.addEventListener("storage", storageEventHandler);
function storageEventHandler(e) {
console.log("B received " + e.key);
}
Assume both document A and document B are loaded and the event listeners are set.
Assume on document A, AddToLocalStorage("new key" , "value1") is called, by a button click or some other way.
In this case, because document A is calling setItem(), document A's storegaEventHandler() should not be invoked. But document B's storageEventHandler() should be invoked.
With Safari 13.1 document A's storageEventHandler is being invoked too.
This is against the specification, and breaks existing functionality that relies on this. Only IE 10 behaves this way, but it is known to not be complaint with specifications.
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200506/64aa01e1/attachment.htm>
More information about the webkit-unassigned
mailing list