Fix flaky ShellNativeAppWindowAuraTest.Bounds
This test creates its own TestBrowserContext, but it derives from ExtensionsTest, which also creates one. Making the test use the provided context instead of creating its own fixes the flake. The flake is fairly rare but becomes more frequent as we add new tests to app_shell_unittests. Read on for details on how this failure occurs, why it was flaky and why more tests make it fail more often. When run in combination with other tests, once in a while the new context happened to be created at the same address as a context used in a previous test, just by chance. The process-wide DependencyManager keeps track of the pointers to contexts that have already been shut down. ExtensionsTest is smart enough to register its own context as "live", so this flake doesn't normally happen, but this test didn't bother. A new context at an old address would be fine *if* the context was marked "live" again. When it isn't, accessing KeyedService with the new context will cause DependencyManager to identify it as a "dead" context (as seen in a previous test) and assert. If we really needed a separate TestBrowserContext, we could mark it live, but why bother? Bug: 750530 Change-Id: I094be7ea4c715a8316547fb2b9f06c081f963483 Reviewed-on: https://chromium-review.googlesource.com/592546 Commit-Queue: Michael Giuffrida <michaelpg@chromium.org> Reviewed-by:Elliot Glaysher <erg@chromium.org> Cr-Commit-Position: refs/heads/master@{#491178}
Showing
Please register or sign in to comment