Add browser tests for multi-process Webview. |
||
Issue descriptionThis is a follow up on issue 880617. Turning on OOPR completely broke multi-process Webview in some configs where the renderer and browser process can be of different bitness and the cc/paint and skia serialization was not bitness agnostic. The best way to avoid future regressions would be to have some tests on the waterfall that catch this early. Is it possible to add a content browsertest or a gpu pixel test for it?
,
Sep 13
Multiprocess was not the problem here. All of webview instrumentation tests run in both single process and multiprocess mode, and uses hardware rendering. The problem is when the browser is 64bit and renderer is 32bit. The O CTS bot does run in this configuration, and it did catch this: crbug.com/879123. But it's not on the cq, and we ignored the failure for more than a week. I don't think there is anything immediate to do here. WebView team has wanted CTS tests on the cq for years, but that requires a whole different fleet of devices that's provisioned differently, so that's a lot of work for the persistently understaffed infra team. And I don't think we should invent any weird build target to specifically exercise this, especially since not all devices on cq are 64bit yet.
,
Sep 13
The CTS test which caught this are not targeted rendering tests (WebSettingsTest, WebViewSslTest) and happened to break because of a debug assert in skia's deserialization code. This is not a consistent pattern, for cc/paint serialization we just fail safely on bad input instead of adding DCHECKs. I think its still important to have a targeted rendering smoke test for this config, which could be through CTS.
,
Sep 13
CTS is not the right place for this. I suppose this doesn't necessarily have to run on android, but I'm not sure if any other platform still supports 32bit. I think anything done on android is going to be fairly difficult and one-off.
,
Sep 13
Yes, it doesn't need to be on Android. Any platform/test suite which allows testing the renderer and GPU process running with different bitness would work. I'm not aware of what other options are there. Though why do you say it would be difficult for Android. Isn't there an API on Webview that allows taking a snapshot of the page that we could use for an end to end pixel test? Could such a test be added to CTS?
,
Sep 13
CTS is part of Android and is nontrivial to update/modify - we would not want to have image comparison tests in CTS due to the likely need to rebaseline them. If we do want to have WebView-specific tests here, they'd need to be CHromium side tests for it to be maintainable. |
||
►
Sign in to add a comment |
||
Comment 1 by khushals...@chromium.org
, Sep 13