Thanks for the report!  Does either clearing your cookies or updating to 63.0.3239.132 resolve the issue?

We've seen one other report of this, but Gmail seems to work with --site-per-process for most users.  It would be great to narrow down what the cause is.

DOH!! Clearing browsing history including cookies seems to do the trick.

Unable to reproduce this issue on reported version 63.0.3239.108 using Ubuntu 14.04 and ubuntu 17.10 with steps mentioned below.

1. Launched chrome with --site-per-process
2. Navigated to Gmail, Able to login and access Gmail successfully. Attaching video for reference.

Issue is not reproducible from TE end. Could someone from Internals>Sandbox>SiteIsolation team please have a look at this issue.

Thanks!

Deleted: Issue 799312.ogv 3.1 MB

	Issue 799312.ogv 3.1 MB View Download

Clearing cookies resolves the issue...

... however, it recurs after a restart of Chrome OS, until I clear cookies again. This is going to get very annoying very quickly.

Is there any useful debug information I can submit?

I see many errors of the form:

Uncaught DOMException: Blocked a frame with origin "https://mail.google.com" from accessing a cross-origin frame.
    at https://mail.google.com/_/scs/mail-static/_/js/k=gmail.main.en.fuzzfuzzfuzz/m=pds,pdl,pdit,m_i,pdt,t,it/am=fuzzfuzzfuzz/rt=h/d=1/rs=fuzzfuzzfuzz:6:44

followed by:

Uncaught TypeError: Cannot read property '0' of undefined
    at rs=fuzzfuzzfuzz:14
and
Uncaught TypeError: Cannot read property 'join' of undefined
    at _B_err (rs=fuzzfuzzfuzz:16)
    at rs=fuzzfuzzfuzz:107

(fuzzfuzzfuzz inserted to obfuscate; not sure if those URLs are sensitive.)

Let me know if I can safely submit the JS console log (or ping me on internal chat).

I can further confirm that clearing cookies and re-signing in to gmail is enough to fix the issue until next reboot.

Comments 6-7: Thanks!  That's a useful lead.  That makes it sounds like a same-origin Gmail frame is ending up in the wrong process, which is pretty unexpected for something in a single tab.

lukasza@: Would you be able to help look into this, possibly working with colm@?

I think I misread the JS error from comment 6.  It's not saying that mail.google.com is accessing mail.google.com.  We don't know which frame it's trying to access, but it's a good bet the frame is in a different process.

Thanks for the report colm@!  

1) Does the problem still happen after disabling all Chrome extensions at chrome://extensions (by unchecking the checkbox saying "Enable(d)") and *then* rebooting?

2) Would you be able provide a Chrome trace of the problematic behavior?
   - Go to chrome://tracing
   - Click "Record"
   - Select "Manually select settings"
   - Expand the "Edit categories" list and include "content", "navigation", "net"
   - Click the other "Record"
   - Switch to another tab and repro the problem where GMail doesn't load
   - Switch back to the chrome://tracing tab and click "Stop"
   - Click "Save" to save the trace
   - Share the trace offline (it might include PII data so it is probably best to avoid attaching it to this public bug)

From the first error reported in #c6, it seems that 2 frames from https://mail.google.com are incorrectly put into *separate* renderer processes and are therefore unable to find and synchronously script each other.

Hmmm... I wonder if this issue might be somehow related to  issue 796912  that would repro if A) Chrome version is 63.0.3239.126 or earlier and B) google.com and/or accounts.google.com is isolated (the first via enterprise policy, the latter via sign-in-process-isolation feature).  I bet that colm@ runs Chrome earlier than 63.0.3239.126 (because AFAIK CrOS has not yet been updated to 63.0.3239.126 unlike Windows/MacOS/Linux).

RE: #c9

Ooops.  I made the same mistake in my last comment in #c10.

A new piece of information; the standard way to launch GMail on CrOS is using the GMail "app" which visits https://mail.google.com/mail/ca/ - this does *not* work.

However, navigating direction to https://mail.google.com/mail/ *does* work.

Yes, I am on CrOS version 63.0.3239.116 (Official Build) (64-bit)

And I can reproduce exactly the same problem under MacOS 63.0.3239.132.

+1 to #14: I've just reproed it by clicking on Gmail from chrome://apps, on 63.0.3239.132 with --site-per-process turned on.  So the fix for 796912 won't help here.

The hypothesis right now is that isolation of google.com is incompatible with the gmail hosted app (credit for this goes to alexmos@).  Unfortunately I am not able to verify this hypothesis, because:

- I could repro the problem on Mac, but I don't know how to turn off or temporarily edit the enterprise policy that is forcing isolation of google.com on this machine

- I was not able to repro the problem on Linux and/or Windows


gkihumba@, if we can confirm that this problem is indeed restricted to users who isolate google.com, then 1) I don't think this bug is necessarily a ReleaseBlock-Stable (because it won't affect the majority of users) and 2) tweaking Finch config of sign-in-process-isolation won't help.

Issue 799638 has been merged into this issue.

Re: #19 - I can reproduce on a personal Mac with no enterprise policies applied (except mandatory install of password alert extension).

Can you confirm the name of the policy which isolates google.com so I can confirm? The account I am using (apart from google.com) is a GSuite account, but I have very few mandatory policies applied.

IsolateOrigins is definitely not set on the Mac in question (although it is set on my Chromebook, being a google.com-enrolled device.

RE: #21,23,24

You can probably double check if site-per-process (aka Strict site isolation) flag is enabled via chrome://flags

We've determined this does not repro when using solely --isolate-origins or no Site Isolation, and that this repros on any platform when opening Gmail via chrome://apps when running with --site-per-process.

Updating summary accordingly.

#enable-site-per-process is enabled on the Mac, and on the Chromebook.

Comment 26 (i.e., that it's --site-per-process specific) means that this is limited to users who turn on Site Isolation manually.  The workaround is to visit https://mail.google.com without using the shortcut in chrome://apps.

I'm inclined to think this is not a stable blocker as a result, since it will not affect Chrome users by default, or apparently even enterprise users of --isolate-origins.

gkihumba@, let me know if you disagree.

Ok with removing RBS label. Update from other pings: this issue doesn't repro for me and a few other people. Seems to be inconsistent.

We think using both --site-per-process and --isolate-origins=https://google.com may make the bug not repro in general.  That's the case for many of us (myself, gkihumba@, pbommana@), but alexmos@ is seeing the bug repro in that case in comment 15 and currently.  There may be something else at work there, though this seems like a secondary issue.

 Issue 799525  has been merged into this issue.

I also have my yahoo.ca account connected to my gmail account so I can
receive them in gmail. I wonder if that has anything to do with it

Comment 32: It should be unrelated to that.  We think it's more related to the Gmail app icon (which gets special process treatment in Chrome) versus --site-per-process.

Note that I am not seeing the bug on M64 and M65 when using --site-per-process (and not --isolate-origins) on Mac.  This suggests that it may already be fixed on those branches, and it only affects M63.  (My current theory is that r521188 for issue 718516 might have fixed it.)

I'll mark it as Started, but it's possible this is Fixed and just a matter of using the workaround until M64 is stable.

Cool. Basic html is fair enough for now, there's no real hit in
functionality. Just have to figure out my way round it and wait.

I've just checked out and built the M63 branch, and confirmed that merging in my r521188 indeed fixes this issue on M63.

My best explanation of the problem: 

1. Launching from chrome://apps launches the GMail App's web_url, which is https://mail.google.com/mail/ca.

2. Looking in the GMail app's manifest, it covers "*://mail.google.com/mail/ca", so without --isolate-origins for google.com, this goes into an App process.

3. Some gmail subframes are same-site, but not in the app's extent, so without 
the IsCurrentlySameSite() modifications in r521188, they get kicked out of the App process and into a regular "google.com" subframe process.  Indeed, in my repro, there's one iframe with the URL "https://mail.google.com/_/scs/mail-static/_/js/..."

So in other words, this confirms #33.  The full r521188 was too risky to merge to M63 (we did discuss this back in December), so I think Charlie's right that we'll need to stick with the workaround until M64 stable, where this should already be fixed.  

To reconcile #15 and #30: my profile/Chrome instance where I have the repro apparently has the IsolateOrigins enterprise policy deployed, but it hasn't been restarted with it yet.  I can tell because chrome://version doesn't show the --isolate-origins flag like my other profile where I can't repro, and because loading https://mail.google.com/mail/ca shows up as an "App" process in task manager, whereas it shows up as a regular google.com process in the other profile with no repro.  So I think all of this confirm that:
- this is specific to --site-per-process *without* --isolate-origins for google.com
- --isolate-origins for google.com works around this issue.

So, #34: Another workaround for you might be to run with both --site-per-process *and* --isolate-origins=https://google.com.  Unfortunately, --isolate-origins isn't exposed via chrome://flags right now, so you'd need to specify the command-line flag manually.

 Issue 799506  has been merged into this issue.

Thanks for the great analysis in comment 35, alexmos@!  Marking fixed accordingly.  I've listed the workaround in https://www.chromium.org/Home/chromium-security/site-isolation#TOC-Known-Issues while we wait for Chrome 64.

You don't need to drop back to Basic HTML mode - just bookmark or navigate
to mail.google.com (instead of clicking the Gmail app) and it should work.

I'd forgotten I was using the app instead of a link

This seems to be fixed in 63.0.3239.140 (Chromebook samus at least). Did something change?

#40: Most likely you've gotten an enterprise policy that includes google.com in the list of isolated origins.  That happens to fix this bug, when it's used together with --site-per-process.  On M63, an isolated origin takes precedence over any matching hosted apps and would prevent /ca URLs from even starting to load in an app process.

 Issue 800106  has been merged into this issue.

 Issue 804119  has been merged into this issue.

 Issue 804376  has been merged into this issue.