2

I have the following html on a local file at ~/test.html:

<html>
  <head>
    <title>Test Event</title>
  </head>
  <body>
    Test Event
  </body>
</html>

I open it in two different windows in Chrome (Version 62.0.3202.75). In the console of the first window I enter the following JS:

window.addEventListener('storage', function(e) {  
    console.log('criou sdasd');
    console.log(e.key);
    console.log(e.oldValue);
    console.log(e.newValue);
    console.log(e.url);
    console.log(e.storageArea);
});

In the console of the second window I enter the following JS:

localStorage.setItem('Chronometer.time', '00:00');

And nothing happens in the first window.

Interesting facts:

  • If I run localStorage.getItem('Chronometer.time') on the console of the first window I get "00:00".
  • If I just open two new empty Chrome tabs and do the same steps above, I do get an event triggered in the first window.

Do storage events work on local html files?

Herohtar
  • 5,347
  • 4
  • 31
  • 41
  • it is EASILY reproducible in **chrome** ... if the file is opened using `file:///` protocol scheme - because Chrome isolates `file:///` tabs from "talking" to each other - `on a local file` suggests `file:///` to me – Jaromanda X Nov 01 '17 at 02:38
  • @JaromandaX then how would the first page be able to access the value set by the second page? That sounds like a chrome bug. I can repro in chrome 52, not in FF57. – Kaiido Nov 01 '17 at 02:39
  • I don't follow @Kaiido - what I'm saying is ... if the page is `http://` or `https://` then changing local storage in one tab will fire the event in another tab (on the same domain) in both Firefox and Chrome .... Firefox also works like this if both pages are loaded `file:///` - Chrome does not ... – Jaromanda X Nov 01 '17 at 02:41
  • @JaromandaX no, in FF the event fires even on `file://` protocol, if both documents points to the same .html file. Here in chrome, the storageArea is shared in this case (you access the new value set by the second tab in the first tab), **but** the storage event doesn't fire. This is a bug since when your storageArea is modified by an other document, it should fire. – Kaiido Nov 01 '17 at 02:43
  • it's not a chrome **bug** - it's how chrome treats `file:///` uri's – Jaromanda X Nov 01 '17 at 02:43
  • 1
    @JaromandaX OP needs to launch chrome with `--allow-file-access-from-files` flag set – guest271314 Nov 01 '17 at 02:43
  • `in FF the event fires even on file:// protocol` - yes, exactly what I said ... Firefox doesn't treat `file:///` as "cross domain" – Jaromanda X Nov 01 '17 at 02:44
  • @Kaiido - it is **not** a bug, it's how Chrome works and has done for dozens of versions – Jaromanda X Nov 01 '17 at 02:45
  • @RicksonGuidolini See [Read local XML with JS](https://stackoverflow.com/questions/41279589/read-local-xml-with-js/) – guest271314 Nov 01 '17 at 02:46
  • @guest271314 - yes, that's the option (I was stalling for time while I tried to find it :p ) - true developers never need that, because true developers understand that developing should be done using `http[s]://` – Jaromanda X Nov 01 '17 at 02:46
  • @JaromandaX You don't get the point... They do **share** the storageArea. So when it is modified the event should fire, otherwise it's a bug. It wouldn't be one if they didn't shared this storageArea, but they do! – Kaiido Nov 01 '17 at 02:46
  • @Kaiido See link at previous comment. With the appropriate launch flag set there should be no issue with code at Question dispatching `storage` event between different browsing contexts which have the same origin. Without the flag set the `storage` event is not dispatched at chromium. – guest271314 Nov 01 '17 at 02:47
  • I know what you are saying @Kaiido - but in the context of how Chrome treats `file:///` url's, it's no surprise that this also doesn't work – Jaromanda X Nov 01 '17 at 02:47
  • @JaromandaX not a surprise, we may agree, but it is a bug. Either they do security seriously and do not share this storageArea, either they implement the API correctly. – Kaiido Nov 01 '17 at 02:50
  • actually, `--allow-file-access-from-files` does sweet fanny albert, must be some other switch, or @Kaiido is right, it's a bug :p – Jaromanda X Nov 01 '17 at 02:51
  • @JaromandaX Will check which flags have set. When initially tried the chromium instance was launched with `--allow-file-access-from-files` flag set at plnkr at two different windows. Tried again without flag set using a different `--user-data-dir` and the `storage` event was not dispatched – guest271314 Nov 01 '17 at 02:53
  • @JaromandaX Unfortunately disk is full at the machine trying at, getting error at `terminal` at chromium instance when call `.setItem()` `History sqlite error 13, errno 0: database or disk is full, sql: INSERT OR REPLACE INTO meta (key,value) VALUES (?,?)`, will free space and or try at a different machine when get a chance to confirm – guest271314 Nov 01 '17 at 02:57
  • `disk is full` remove some por.... I mean, temp data :p – Jaromanda X Nov 01 '17 at 02:59
  • Filed a bug report: https://bugs.chromium.org/p/chromium/issues/detail?id=780360 – Kaiido Nov 01 '17 at 03:05
  • no, chrome doesn't consider files to be a common domain, so the two tabs are on different domains. afaik, only localStorage considers them the same, and that's probably because it would be hard define a local domain otherwise. everything else behaves as SOP (messages, opener, iframes dom, etc) – dandavis Nov 01 '17 at 03:08
  • @JaromandaX Was at an os at an sd with minimal total space. Cleared space and launched with `--unlimited-storage` flag and get same result, `storage` event is not dispatched – guest271314 Nov 01 '17 at 03:14
  • @dandavis It that true for only `storage` event at `file:` prototcol? Just tried the same procedure using `resquestFileSystem` at two HTML documents reading and writing to same `LocalFileSystem` using code at [How to use webkitRequestFileSystem at file: protocol](https://stackoverflow.com/questions/37502091/how-to-use-webkitrequestfilesystem-at-file-protocol) and the `File` object is available at both documents. – guest271314 Nov 01 '17 at 03:19
  • @Kaiido Interestingly, was able to use `webkitRequestFileSystem` to retrieve `File` object set at same document at different `window`. Will try the code at Question again at two different HTML documents not having the same name, to determine if that makes a difference. – guest271314 Nov 01 '17 at 03:26
  • afaik, that's only for localStorage events. maybe SharedWebWorkers and RTCDataChannels too? – dandavis Nov 01 '17 at 03:28
  • @dandavis What would be the security risk? How is *oogle related to the issue? Chrome is based on Chromium code, which is open source; the decision would be that of the Chromium authors, not *oogle, e.g., see [Base64 PDF in new tab shows Blank Page before Refresh](https://stackoverflow.com/q/45558645/) – guest271314 Nov 01 '17 at 03:30
  • @dandavis The restriction appears to be applicable to `storage` event. Was able to communicate between browsing contexts at `file:` protocol using other methods of `window`. – guest271314 Nov 01 '17 at 03:39
  • @Kaiido The `storage` event is dispatched when the initial value that is set is changed and `--allow-file-access-from-files` flag is set – guest271314 Nov 01 '17 at 03:41
  • @JaromandaX The issue appeared to have been low disk space, `storage` event is now being dispatched at `file:` protocol using code at Question, where appropriate flag is set – guest271314 Nov 01 '17 at 03:50
  • the spec doesn't actually insist on a domain, so I think this is a bug: "_When the setItem(), removeItem(), and clear() methods are invoked, events are fired on the Window objects of other Documents that can access the newly stored or removed data, as defined in the sections on the sessionStorage and localStorage attributes._" clearly, other files in chrome can see the new data. i would love this fixed. – dandavis Nov 01 '17 at 03:51
  • really, with just the `--allow-file-access-from-files` flag? Must be broken in Chrome 62 then – Jaromanda X Nov 01 '17 at 03:51
  • @JaromandaX Yes, trying at Chromium 61 after clearing disk space. There could be a change at Chromium 62, have not read the release notes or browsed all of the recent issues – guest271314 Nov 01 '17 at 03:51
  • `doesn't actually insist on a domain` - except the part that says `other Documents that can access the newly stored or removed data, as defined...` – Jaromanda X Nov 01 '17 at 03:52
  • @guest271314 - yet another Chrome 62 bug (this is one of the most buggy *releases* I've seen since 2012 where every second release broke something or other) – Jaromanda X Nov 01 '17 at 03:53
  • the litmus test is "can access the newly stored data", the other parts are vauge about "domains" – dandavis Nov 01 '17 at 03:53
  • @JaromandaX Will try to update to version 62 to try. There might be a corresponding undocumented flag which could be used to provide expected result. We also do not know if OP's disk space is low, which evidently was the issue at version 61, here, where no notifications as to the low disk space were logged at `console`, though the errors are logged at commandline – guest271314 Nov 01 '17 at 03:57
  • @Kaiido _"I was able to repro on 61 too"_ Did you launch with `--allow-file-access-from-files` flag set? – guest271314 Nov 01 '17 at 13:16
  • @guest271314 yes I also did set this flag and still faced the bug, but even if it had worked with the flag set it wouldn't have changed anything in it being a bug. And it has been confirmed in the bug report that it's not a regression, M50 already had this buggy behavior. – Kaiido Nov 01 '17 at 14:10
  • @Kaiido At Chromium 61 here the `storage` event is dispatched when the flag is set – guest271314 Nov 01 '17 at 22:03
  • Possible duplicate of [localStorage event listener cannot fire in chrome](https://stackoverflow.com/questions/19150638/localstorage-event-listener-cannot-fire-in-chrome) – Herohtar Jan 22 '18 at 19:48

1 Answers1

0

Chrome prevents local files (file:///*) from "talking" to each other by default as a security measure. You can disable this restriction by launching Chrome with the --allow-file-access-from-files flag:

chrome.exe --allow-file-access-from-files

Now the storage event should work as expected with local files.

Herohtar
  • 5,347
  • 4
  • 31
  • 41