New issue
Advanced search Search tips

Issue 700510 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 700077
Owner:
Closed: Mar 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Regression



Sign in to add a comment

[OOPIFs] Domain that loading into OOPIF fail to load into none-OOPIF top document

Reported by cool...@gmail.com, Mar 10 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0

Steps to reproduce the problem:
1. install the unpacked extension from the attached twitch5.zip
2. navigate to chrome-extension://TWITCH5-EXTENSION-ID/player.html?channel=coolcmd
3. hit INSERT key on the keyboard to open the chat (if it does not open already)
    https://www.twitch.tv/coolcmd/chat will be loading into <iframe>
4. while chat content is still loading, click the link 'Broadcast ended' at the top left corner
    https://www.twitch.tv/coolcmd will be loading into the tab (as top document)

What is the expected behavior?
https://www.twitch.tv/coolcmd must be loaded with minimal error messages in the console (press Ctrl+Shift+J).
see attached testcase.mp4, attempts 1, 2, 3, 4, 5, 7

you should allways see expected behavior if run the command
    chrome --force-fieldtrials=SiteIsolationExtensions/Control
which disables OOPIFs (in my version of Chrome)

What went wrong?
sometimes https://www.twitch.tv/coolcmd fail to load: black background with Twitch logo at center will be shown. console is flooded with uncaught exceptions (TypeError: no access).
see attached testcase.mp4, attempts 6 and 8.

Did this work before? Yes 55

Does this work in other browsers? Yes

Chrome version: 57.0.2987.98 (Official Build) (64-bit)  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 24.0 r0
 

Comment 1 by woxxom@gmail.com, Mar 10 2017

The attachment is absent, please reupload.

Comment 2 by cool...@gmail.com, Mar 10 2017

bugs.chromium.org refuse to receive attachments. i will try tomorrow.
Cc: creis@chromium.org
Components: Internals>Sandbox>SiteIsolation
Labels: M-57
Status: Available (was: Unconfirmed)
Able to reproduce but that is not consistent.

Comment 4 by creis@chromium.org, Mar 11 2017

Cc: yukishiino@chromium.org
Components: UI>Browser>Navigation
Owner: dcheng@chromium.org
I'm assuming this is referring to the same twitch5.zip extension attached to  issue 700346 ?

I do see some problems when clicking the "Broadcast Ended" link, though it's hard to say exactly which part is failing yet.  (We appear to be navigating a page on A with a B subframe to B at the top level.)

In a debug build, I'm failing this DCHECK in v8::Local<v8::Object> WindowProxy::globalIfNotDetached():
  DCHECK(m_globalProxy == m_scriptState->context()->Global());

Daniel, are you familiar with this from your bindings work?

I also see this DCHECK failing in LocalWindowProxy::disposeContext if I go back after the first DCHECK failure:

      // TODO(yukishiino): This DCHECK failed on Canary (M57) and Dev (M56).
      // We need to figure out why m_globalProxy != context->Global().
      DCHECK(m_globalProxy == context->Global());

These probably help explain the "TypeError: no access" messages?

Comment 5 by creis@chromium.org, Mar 11 2017

Looks like this problem might be related to  issue 700077 .  It seems to be a V8 bindings problem, which would explain why the page is failing to load with TypeErrors.

Comment 6 by dcheng@chromium.org, Mar 11 2017

Status: Assigned (was: Available)
I think this might be fixed. creis@, do you happen to know what revision you were testing against?

Comment 7 by creis@chromium.org, Mar 11 2017

I was testing in a trunk build: 59.0.3037.0, built from r455838.  Haven't had a chance to try on Canary yet.

Comment 8 by dcheng@chromium.org, Mar 12 2017

Ah, OK. The immediate problem was fixed in r455951, and I've added CHECKs since then that haven't tripped on crash, so I believe this should work now.

Comment 9 by creis@chromium.org, Mar 16 2017

Status: Fixed (was: Assigned)
Comment 8: Agreed.  This does not repro in the 59.0.3043.0 Canary.

It does repro in 57.0.2987.88.  Is there a need to merge that and/or other fixes to M58 and M57?

Comment 10 by creis@chromium.org, Mar 16 2017

(Also repros on 58.0.3029.19.)
Mergedinto: 700077
Status: Duplicate (was: Fixed)
(Marking this as a duplicate, so it's clearer that this was merged to M58)

Sign in to add a comment