Cool. Marking this as available.

Just as a note, out-of-process iframes have been shipping since M56 and we are increasing their usage. It will be great to at least assess whether/what is broken at the current state, so it can be prioritized accordingly.
We are aiming at starting to experiment with generic OOPIFs on the open web towards the end of the year, but will ship two more milestones before that.

FWIW I'm not sure why the current design has those as static methods on StorageArea actually, and not just instead register the correct Storage* instances with their StorageArea. That way StorageArea could just directly inform the appropriate Storage* instances (and their window), rather than having to iterate over all the pages/frames to see if any of them happen to match our storage namespace/origin...
(there already has to be a Storage/StorageArea instance for each window that cares about storage events, because that is how a window registers for receiving those events: by creating those instances)

What's the status of this? Did we fix and just lost track of the bug, or is site isolation going to be breaking lots of stuff?

Site Isolation has been on for lots of users for a while now, so it isn't breaking lots of stuff. I would not be surprised if it is breaking some stuff though, so it will be useful to get someone that knows this area to help investigate.

Thanks for the ping.  mek@, can you take a look to see if there's anything broken there that we need to address in the short term?  You can test using --site-per-process and a page with cross-site iframes, like http://csreis.github.io/tests/cross-site-iframe.html.

Friendly ping.  mek@, are there functionality problems expected from this bug?  What would the repro steps be?  For reference, Site Isolation is targeting M67 on desktop, so if fixes are needed we should probably get them into at least 68 if possible. 
 Thanks!

It's find for the iteration over frames to skip remote frames, since those would always be on a different origin than the main document anyway, afaik? So as long as the frame->Tree().TraverseNext() iteration at least touches all same origin frames in the same process anywhere in the frame tree there shouldn't be a problem.

And even if some same-origin frames are for whatever reason in a different process, than that process itself would have registered interest in storage events if the frame is interested in them. So even in that case I don't expect any problems. So I don't expect any problems, but unfortunately I haven't actually gotten around to testing that. Testing would probably involve listening for storage events in one iframe while changing local and/or session storage from a different same-origin iframe, for various combinations of top-level/nested frames. But it should all just work, since each process that is interested in events would register for them anyway.

That makes sense to me.  Agreed that frame->Tree().TraverseNext() should hit all LocalFrames in the tree, even in a case like A(B(A)).  Also agreed that any same-origin frames in the same page would be in the same process.  (Same-origin frames in a different tab would often be in a different process, but as you mention, those will register interest in their own process.)

Maybe we should just land a CL changing:
      // FIXME: We do not yet have a way to dispatch events to out-of-process
      // frames.
to:
      // Remote frames are cross-origin and do not need to be notified of events.
?

Thanks for checking!

Yep, that sounds good to me.

Also, I believe that sessionstorage should never have to move events between processes or frames, as all changes apply to a namespace + origin pair, and the namespace is per-tab. I recently re-implemented this in mojo where all changes are just handled / dispatched in the renderer itself.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/667ff1eb06bd7b97f79a078537ef7902bc73b584

commit 667ff1eb06bd7b97f79a078537ef7902bc73b584
Author: Nasko Oskov <nasko@chromium.org>
Date: Thu May 31 23:54:40 2018

Replace FIXMEs with correct comments.

As discussed in  https://crbug.com/753130 , there is no additional work
needed for OOPIFs to be notified of localStorage/sessionStorage updates.
This CL removes the FIXMEs and replaces them with a more accurate comment.

Bug:  753130 
Change-Id: I7b9a0c3869168c716281837dae2572adb01a09c5
Reviewed-on: https://chromium-review.googlesource.com/1080286
Reviewed-by: Marijn Kruisselbrink <mek@chromium.org>
Reviewed-by: Victor Costan <pwnall@chromium.org>
Commit-Queue: Victor Costan <pwnall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#563441}
[modify] https://crrev.com/667ff1eb06bd7b97f79a078537ef7902bc73b584/third_party/blink/renderer/modules/storage/storage_area.cc