The two spaces indicate that the setTimeout() fired before the possibly-crashing condition was triggered, so the iframe is still there, affecting the dumped text.

(I should have searched harder for a non-timeout test. I should also have put some text in the iframe)

Disable for now, I'll improve the test.

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

commit f6d2b1ae742e83a914efbffb16c87004e2947279
Author: alexmos <alexmos@chromium.org>
Date: Thu Sep 29 18:26:13 2016

Disable flaky storage/websql/transaction-removed-context-crash.html test

This test is consistently failing on Site Isolation Win bot and flaky
on several other Windows bots.

BUG=651502
NOTRY=true

Review-Url: https://codereview.chromium.org/2377283004
Cr-Commit-Position: refs/heads/master@{#421874}

[modify] https://crrev.com/f6d2b1ae742e83a914efbffb16c87004e2947279/third_party/WebKit/LayoutTests/TestExpectations

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

commit b9bd580e1f1c84ed970446ba780f96c48adcf788
Author: jsbell <jsbell@chromium.org>
Date: Thu Sep 29 23:11:15 2016

Deflake storage/websql/transaction-removed-context-crash.html

Test relied on an arbitrary timeout to determine if the conditions
leading to a (now fixed) crash had passed. That introduced flakiness
where the timeout could fire before the test logic was complete on
slower machines.

Replace the arbitrary timeout with a poll that waits for a certain
condition instead, and re-enable the test.

BUG=651502
R=alexmos@chromium.org

Review-Url: https://codereview.chromium.org/2384563002
Cr-Commit-Position: refs/heads/master@{#421973}

[modify] https://crrev.com/b9bd580e1f1c84ed970446ba780f96c48adcf788/third_party/WebKit/LayoutTests/TestExpectations
[modify] https://crrev.com/b9bd580e1f1c84ed970446ba780f96c48adcf788/third_party/WebKit/LayoutTests/storage/websql/transaction-removed-context-crash.html

The test is still timing out on recent FYI bot runs - for example here: https://build.chromium.org/p/chromium.fyi/builders/Site%20Isolation%20Win/builds/16402

Looks like it's only timing out on site isolation now? I don't see flakes on other platforms.

Note that the test *does* do interesting things with iframes. The iframe is given a Blob's URL as the src, and the iframe then attempts to remove itself from the parent document. Maybe it's a real site isolation bug? 

I'm landing a change (https://codereview.chromium.org/2398313002/ - in the CQ) that simplifies the test further - replaces blob URL with just using srcdoc. If it is an issue w/ Blob URLs vs. site isolation that might fix it?

+nick@ because of the blob comment in #c8

Dashboard looks happy following my change:

https://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=storage%2Fwebsql%2Ftransaction-removed-context-crash.html

So "fixed" but per #8 this seems like the original version of the test could be tripping an actual Site Isolation bug w/r/t blobs.

passing off to nick@ - unless this is a known issue I'd suggest trying to repro with site isolation, filing a new bug, and closing this one. Let me know if I can help.

Thanks for looping me in. The original failure is definitely worth debugging.

If I understand correctly, switching from blob to srcdoc seems to have fixed the problem, which only had manifested under --site-per-process. That's surprising indeed, since this blob iframe ought to be same-origin with window.top, so not an oopif.

However, if it were an oopif (e.g. due to a bogus process transfer?), this test ought to fail, since window.frameElement would be null in a cross-origin/cross-process iframe.

Blobs loads always go through the browser process, whereas srcdoc is all handled locally. So that could be a timing difference overall.

Also worth noting is that this isn't an http test, which (I believe) means it runs in the file:// origin. blob URLs and file:// origins have some weird interactions.

Oh, but: by default today, SiteIsolationPolicy::AreCrossProcessFramesPossible() will return false in a layout test unless you have the --site-per-process flag set. Whereas in a chrome build, SiteIsolationPolicy::AreCrossProcessFramesPossible() always returns true. That makes a behavior difference with the flag possibly less surprising for a same-origin iframe.

> switching from blob to srcdoc seems to have fixed the problem, which only had manifested under --site-per-process.

Yes.

> Also worth noting is that this isn't an http test, which (I believe) means it runs in the file:// origin. blob URLs and file:// origins have some weird interactions.

Yes, and yes. :) 

Ah, https://codereview.chromium.org/2376083002 is my attempt to add a browsertest that exercises blob URLs from file:// origins, and it actually hasn't landed yet because of a failure specific to --site-per-process.

I believe I understand what's going on now. Under --site-per-process, if you navigate a frame currently at a file:// URL to a blob:null URL (which is what blob URLs created from file:// origins look like), we do a process swap because IsCurrentlySameSite returns false.

There are a few ways to fix this ranging from specific to general. The main worry is that for blob:null, data: URLs, about:blank URLs, and other similarly ambiguous cases where the origin can't be inferred from URL, whether changing the process transfer logic opens up any attack surface for executing attacker-controlled code in a privileged process -- e.g., via history navs. Given all the recent chaos around blob:/filesystem:, I think it's time to take a hard look at this.

Status of this one?

Maybe fixed by https://chromium-review.googlesource.com/c/chromium/src/+/953129 ?

This issue has been marked as started, but has no owner. Making available.