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

Issue 697938 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Mar 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

cross-origin-indexeddb-allowed.html layout test failing on Site Isolation Linux FYI bot

Project Member Reported by creis@chromium.org, Mar 2 2017

Issue description

After https://codereview.chromium.org/2723183002 landed, the following tests started failing with a text diff when run with --site-per-process on the Site Isolation Linux FYI bot:

http/tests/security/cross-origin-indexeddb-allowed.html
http/tests/security/cross-origin-worker-indexeddb-allowed.html

https://build.chromium.org/p/chromium.fyi/builders/Site%20Isolation%20Linux/builds/14339

To run locally:
DISPLAY=:20 third_party/WebKit/Tools/Scripts/run-webkit-tests -t Default -v --additional-drt-flag=--site-per-process --no-retry-failures --additional-drt-flag=--no-sandbox --iterations=1 http/tests/security/cross-origin-indexeddb-allowed.html http/tests/security/cross-origin-worker-indexeddb-allowed.html

jsbell@, can you take a look to help us get the bot green again?
 
The test appears to log a different number of warnings on those bots than elsewhere. Looking...
While I'm building - the tests use two iframes, one at http://localhost:8000/ and one at http://127.0.0.1:8000/ - do we have logic that prevents us from showing the same deprecation warning twice, but since each iframe gets a separate process it's not suppressing?

Comment 3 by creis@chromium.org, Mar 2 2017

Cc: dcheng@chromium.org lukasza@chromium.org
alexmos@: Do you know about what might be happening with the console warnings here?  (lukasza@ might, but he's OOO.)
Yeah, dropping this into Deprecation::countDeprecation():

DLOG(WARNING) << __FUNCTION__;

With --site-per-process I get:

[127233:127233:0302/103255.273935:8621976599421:WARNING:Deprecation.cpp(148)] countDeprecation
CONSOLE WARNING: line 9: indexedDB.webkitGetDatabaseNames() is deprecated and will be removed in M60, around August 2017. See https://www.chromestatus.com/features/5725741740195840 for more details.
[127249:127249:0302/103255.637004:8621976962468:WARNING:Deprecation.cpp(148)] countDeprecation
CONSOLE WARNING: line 9: indexedDB.webkitGetDatabaseNames() is deprecated and will be removed in M60, around August 2017. See https://www.chromestatus.com/features/5725741740195840 for more details.

Without I get:

[127303:127303:0302/103314.506086:8621995831536:WARNING:Deprecation.cpp(148)] countDeprecation
CONSOLE WARNING: line 9: indexedDB.webkitGetDatabaseNames() is deprecated and will be removed in M60, around August 2017. See https://www.chromestatus.com/features/5725741740195840 for more details.
[127303:127303:0302/103314.526844:8621995852205:WARNING:Deprecation.cpp(148)] countDeprecation

Note that both have two countDeprecation() calls, but in the --site-per-process case they're in different processes (first number in the []) so both actually result in a warning.
The theory from #2 seems very likely.  I don't know the deprecation code at all, but Deprecation::countDeprecation (https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/frame/Deprecation.cpp?l=140) seems to keep track of whether it's recorded the corresponding measurement and logged the message on Page.  The two frames here are in different renderers, with each renderer process having its own Page, and we definitely don't replicate the deprecation state/use counter, hence the two warnings.
I'm not sure what the best thing to do is. I assume this difference in logging is an acceptable behavior change for site-isolation. I don't think we want to change the test. I am unaware of a way to e.g. suppress the deprecation warning for the test. I don't think we have different expectation files (e.g. virtual/XYZ) for site isolation...

Thoughts?

One option would be to call testRunner.setDumpConsoleMessages(false) early in the layout test - this assumes that verifications that are important to the test are covered (or can be covered) in a different way (i.e. by dumping of frame contents / testRunner.dumpAsText).
Status: Started (was: Untriaged)
Ah, perfect - yeah, the tests are basically a try/catch that logs in both branches. Logging is not critical.

Status: Fixed (was: Started)
Thanks all!

Sign in to add a comment