New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 793422 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Jan 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 1
Type: Bug



Sign in to add a comment

WebViewTests/WebViewTest.LoadWebviewInsideIframe/1 is flaky on MSAN

Project Member Reported by thomasanderson@chromium.org, Dec 8 2017

Issue description

Comment 1 by lfg@chromium.org, Dec 8 2017

Labels: -Pri-1 Pri-2
Owner: mcnee@chromium.org
Assigning to mcnee@, I think you were looking at weirdness embedding <webview> inside iframes.

Comment 2 by mcnee@chromium.org, Dec 8 2017

Components: Platform>Apps>BrowserTag
I suspect this is a separate issue from  crbug.com/788914  . Since in the test we have a DomAutomationController which would ensure we had a ScriptContext in the iframe.

Also, looking at the flakiness dashboard, we only appear to be having trouble with MSan; the rest look fine.
https://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=WebViewTests%2FWebViewTest.LoadWebviewInsideIframe%2F1

Comment 4 by mcnee@chromium.org, Dec 19 2017

So I've only been able to reproduce this locally once. It looks like the |webview.contentWindow.postMessage| is not getting through to the guest.

In the meantime, I can disable this test for MSAN.
Project Member

Comment 5 by bugdroid1@chromium.org, Dec 19 2017

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

commit f8f2534d9ec04929a85cf6e73f786ed83a6ac37c
Author: Kevin McNee <mcnee@chromium.org>
Date: Tue Dec 19 15:17:49 2017

Disable LoadWebviewInsideIframe under MSAN

WebViewTests/WebViewTest.LoadWebviewInsideIframe/1 is flaky under MSAN.

Bug:  793422 
Change-Id: I867113fc436c1574e79e4dc6b55666c42904f86c
Reviewed-on: https://chromium-review.googlesource.com/832678
Reviewed-by: James MacLean <wjmaclean@chromium.org>
Commit-Queue: Kevin McNee <mcnee@chromium.org>
Cr-Commit-Position: refs/heads/master@{#525038}
[modify] https://crrev.com/f8f2534d9ec04929a85cf6e73f786ed83a6ac37c/chrome/browser/apps/guest_view/web_view_browsertest.cc

Comment 6 by mcnee@chromium.org, Dec 19 2017

It's also worth noting that the old /0 version of the test (GuestViewCrossProcessFrames disabled) was not flaky on MSAN.
Project Member

Comment 7 by bugdroid1@chromium.org, Jan 17 2018

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

commit a18303412701d46a3dd35776012b9d3578521e89
Author: Kevin McNee <mcnee@chromium.org>
Date: Wed Jan 17 19:13:00 2018

OOPIF guest view: Don't ACK AttachToEmbedderFrame before the attachment.

In the OOPIF based guest version of |attachImpl$| we call
|AttachIframeGuest| and provide a callback to be run after the
attachment is done. However, the callback is run before the
frame is actually swapped for a remote frame, as evidenced by
the contentWindow still being local when the callback is run.

The relative order of |AttachToOuterWebContentsFrame| and
|GuestViewMsg_AttachToEmbedderFrame_ACK| appears to have been
accidentally changed in https://codereview.chromium.org/2472253002

We now send the ACK after the call to |AttachToOuterWebContentsFrame|
so that the callback is run after the attachment.

Similarly, we were dispatching queued events in GuestViewBase::DidAttach
before the attachment. We now dispatch after the attachment and ACK, so
that the correct contentWindow is available in JS when handling the
events.

Bug:  793422 
Change-Id: Ib83a985e24134dfcfd79cc474a6b30056ca66960
Reviewed-on: https://chromium-review.googlesource.com/868277
Reviewed-by: Lucas Gadani <lfg@chromium.org>
Commit-Queue: Kevin McNee <mcnee@chromium.org>
Cr-Commit-Position: refs/heads/master@{#529841}
[modify] https://crrev.com/a18303412701d46a3dd35776012b9d3578521e89/components/guest_view/browser/guest_view_base.cc
[modify] https://crrev.com/a18303412701d46a3dd35776012b9d3578521e89/components/guest_view/browser/guest_view_base.h
[modify] https://crrev.com/a18303412701d46a3dd35776012b9d3578521e89/components/guest_view/browser/guest_view_message_filter.cc

Project Member

Comment 8 by bugdroid1@chromium.org, Jan 19 2018

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

commit 1bf7fba85eb32436e2ec557a21f88e42fc3bfd86
Author: Kevin McNee <mcnee@chromium.org>
Date: Fri Jan 19 15:37:49 2018

Reenable WebViewTest.LoadWebviewInsideIframe under MSan.

I believe that
https://chromium-review.googlesource.com/c/chromium/src/+/868277
fixes the issue which was causing this test to flake.

Bug:  793422 
Change-Id: Ie74a8dc9e3b36f609210db89b453960e0d8b7286
Reviewed-on: https://chromium-review.googlesource.com/875111
Reviewed-by: James MacLean <wjmaclean@chromium.org>
Commit-Queue: Kevin McNee <mcnee@chromium.org>
Cr-Commit-Position: refs/heads/master@{#530514}
[modify] https://crrev.com/1bf7fba85eb32436e2ec557a21f88e42fc3bfd86/chrome/browser/apps/guest_view/web_view_browsertest.cc

Comment 9 by mcnee@chromium.org, Jan 22 2018

Status: Fixed (was: Assigned)

Sign in to add a comment