Add expectations for remaining layout tests with --site-per-process.

Add expectations for remaining layout tests with --site-per-process.

BUG=477150
NOTRY=true

Committed: https://crrev.com/19008fcc6611e8237d1ce992daf85a224c515ecb
Cr-Commit-Position: refs/heads/master@{#417320}

[alexmos, 2016-09-08 16:34:15]

alexmos@chromium.org changed reviewers:
+ lukasza@chromium.org

[alexmos, 2016-09-08 16:34:16]

Lukasz, can you please take a look?  I assembled this list from the first four
failing builds on Site Isolation Win after switching to the full set of layout
tests with --site-per-process, starting with
https://build.chromium.org/p/chromium.fyi/builders/Site%20Isolation%20Win/bui....

I haven't tried to triage them yet; this is just to get the bot green.  I'd
expect that all the imported/wpt/html/syntax/parsing tests fail for the same
reason, but that said, we don't fail the full set, but rather 47 of 60 tests, so
I didn't disable the whole directory.  I also think a couple of tests that time
out are just too slow for that bot (i.e., take longer than 30 seconds, so timing
out even with the SLOW expectation), such as jquery/manipulation.html and the
inspector test.  I don't know if we can do anything about that other than
requesting a faster machine, since it doesn't seem to be affecting the main
waterfall bots.

[Łukasz Anforowicz, 2016-09-08 16:57:30]

LGTM.  Interesting to know that --site-per-process can have an impact even
without http and/or extensions.  I am guessing that unique origins might be put
into separate processes?

[alexmos, 2016-09-08 17:00:37]

The CQ bit was checked by alexmos@chromium.org

[commit-bot: I haz the power, 2016-09-08 17:01:08]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-08 17:07:14]

Committed patchset #1 (id:1)

[alexmos, 2016-09-08 17:10:02]

On 2016/09/08 16:57:30, Łukasz Anforowicz wrote:
> LGTM.  Interesting to know that --site-per-process can have an impact even
> without http and/or extensions.  I am guessing that unique origins might be
put
> into separate processes?

I'm not sure; it'd be really interesting to dig into these.  I wouldn't expect
data: URLs to swap processes (they should stay in their creator's process), but
perhaps there's more process swap confusion with blob URLs (there are a couple
of blob tests), or strangeness involving creating/deleting lots of frames, even
if they're all same-origin (the fast/frames tests).

[commit-bot: I haz the power, 2016-09-08 17:10:56]

Description was changed from

==========
Add expectations for remaining layout tests with --site-per-process.

BUG=477150
NOTRY=true
==========

to

==========
Add expectations for remaining layout tests with --site-per-process.

BUG=477150
NOTRY=true

Committed: https://crrev.com/19008fcc6611e8237d1ce992daf85a224c515ecb
Cr-Commit-Position: refs/heads/master@{#417320}
==========

[commit-bot: I haz the power, 2016-09-08 17:10:57]

Patchset 1 (id:??) landed as
https://crrev.com/19008fcc6611e8237d1ce992daf85a224c515ecb
Cr-Commit-Position: refs/heads/master@{#417320}