I can't reproduce the failure in my local machine.

I will disable them: https://chromium-review.googlesource.com/c/599249

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

commit e10c7679c674fe65772a36342e03235d88c2d765
Author: Tsuyoshi Horo <horo@chromium.org>
Date: Thu Aug 03 08:24:14 2017

Disable flaky WebUIWebViewBrowserTests on ChromeOS

TBR: hanxi
Bug: 751907
Change-Id: I231934d8e83384687d837e140f25e9d553c774ab
Reviewed-on: https://chromium-review.googlesource.com/599249
Reviewed-by: Tsuyoshi Horo <horo@chromium.org>
Commit-Queue: Tsuyoshi Horo <horo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#491677}
[modify] https://crrev.com/e10c7679c674fe65772a36342e03235d88c2d765/chrome/browser/ui/webui/webui_webview_browsertest.cc

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

commit 44a32024fe82e16db9bc0ccdbdd6195ed023e2fd
Author: Luna Lu <loonybear@chromium.org>
Date: Thu Aug 03 19:47:22 2017

Disable tests consistently failing on Linux ChromiumOS MSan Tests:
WebUIWebViewBrowserTest.AddContentScriptIncognito
WebUIWebViewBrowserTest.AddMultiContentScripts
WebUIWebViewBrowserTest.AddContentScript

https://uberchromegw.corp.google.com/i/chromium.memory/builders/Linux%20ChromiumOS%20MSan%20Tests
Change-Id: I6913b1bfcc5f666826ace9538142e5ef29bc6301

Bug: 751907
TBR: hanxi
Change-Id: I6913b1bfcc5f666826ace9538142e5ef29bc6301
Reviewed-on: https://chromium-review.googlesource.com/600633
Commit-Queue: Luna Lu <loonybear@chromium.org>
Reviewed-by: Luna Lu <loonybear@chromium.org>
Cr-Commit-Position: refs/heads/master@{#491820}
[modify] https://crrev.com/44a32024fe82e16db9bc0ccdbdd6195ed023e2fd/chrome/browser/ui/webui/webui_webview_browsertest.cc

Can't just disable tests without bringing attention to them...

Regression range: https://chromium.googlesource.com/chromium/src/+log/cea99f6eb3b6e67579771bee0c9b5a231007dd22..c647a330c868a8dec8914914c98cdd75dbd2a69a?pretty=fuller&n=10000

the two CLs that touched webui in it are: erikchen's and stevenjb's

erikchen@ could you PTAL and pass to stevenjb@ if required?

Failures are ChromeOS, and stevenjb's CL heavily touches chromeOS webUI files.

From Aug 10? *ugh*. Regression range is not going to be super helpful at this point. I will try to take a look. I've been re-factoring these anyway.

 Issue 662673  has been merged into this issue.

I've been runing these tests locally with and without msan, and have not seen them fail. *however*, on Chrome OS they are *SLOW*, especially the msan tests, so I strongly suspect that the flakiness is due to the tests timing out occasionally.

The reason they are slow is that they are loading chrome://oobe/login for testing. This is... not ideal, as it makes the tests highly vulnerable to unrelated changes (e.g. converting login to views...).

I would really prefer not to own this, but I'm not sure why the best owner is.

rkc@, is this something your team could pick up? If not, I can keep it on my plate, but I won't get to it right away.

FWIW, I tested this using GURL(chrome::kChromeUIMobileSetupURL) instead of GURL(chrome::kChromeUIOobeURL).Resolve("/login") and it runs *MUCH* faster, so this would temporarily serve as a workaround... until we re-factor chrome://mobilesetup/. We really need to have the test set up a page/host for testing this.

These tests test content scripts, so maybe Devlin's team should own this?

That seems reasonable to me. The non cros implementation isn't a whole lot better, just less slow:

  GURL GetWebViewEnabledWebUIURL() const {
#if defined(OS_CHROMEOS)
    return GURL(chrome::kChromeUIMobileSetupURL);
#else
    return GURL(signin::GetPromoURLForTab(
        signin_metrics::AccessPoint::ACCESS_POINT_START_PAGE,
        signin_metrics::Reason::REASON_SIGNIN_PRIMARY_ACCOUNT, false));
#endif
  }

So on desktop chrome the dependency is on signin::GetPromoURLForTab, which also seems potentially fragile. The correct fix (imho) would be to remove both dependencies and use a test only page that enables webview.

Assigning Devlin to prioritize and further assign.

These tests are primarily testing webui.  I don't think this is something the extensions team should own.  If there is a problem with the content script extensions API, we can take a look, but this sounds like it's a problem of flaky/slow/complicated tests, rather than a functional issue in content scripts.

back to rkc@.

Since the component is set correctly, marking untriaged so it can be picked up WebUI owners.

FWIW, we have chosen to not run JS WebUI tests on various *SAN bots, see https://cs.chromium.org/chromium/src/chrome/test/BUILD.gn?l=33.

Perhaps there are more test that should adhere to this flag.

dpapad@ - Take a look at comment #13, would you agree that even on non cros using arbitrary WebUI to test embedded <webview> (especially one that is not available on CrOS) is not ideal?

The fundamental problem here is that instead of creating a test-only page, we picked something not available on CrOS, and for CrOS we picked something that is *VERY* slow to load and which is being replaced with non WebUI.

We also don't have anyone on CrOS focused on WebUI :(

I can "fix" this using a different URL for CrOS as mentioned in comment #11, but it will just be another ticking time bomb.

I agree that we should also disable these on *SAN bots, but these have been occasionally flakey on other bots as well, and eventually oobe/login will stop working on CrOS.