webexposed tests should disable testing-specific APIs |
||||||||||
Issue descriptionBlink's "webexposed" LayoutTests are designed to track the API surface area exposed by the browser (especially when run in the virtual/stable configuration which disables all experimental APIs). But like other LayoutTests, they run inside of a special mode of content_shell which has a few APIs exposed for testing purposes (eg. window.internals, window.chrome). This can cause confusion about what's really "web exposed" and creates a (small) blind spot that could in theory contribute to accidentally exposing such an internal API unintentionally. Perhaps we could run all the webwexposed tests in a (different) virtual test suite that explicitly avoided adding test-specific APIs? Not sure what to do about testRunner though - some minimal APIs are currently needed (like dumpAsText) to make the test behave as desired, but perhaps that could be eliminated (eg. by changing modes based on the command line flag).
,
Jun 9 2016
It's tempting to think the webexposed scripts should just explicitly exclude known testing-specific APIs (would be trivial to do), but that kind of just masks the problem (doesn't change the fact that that we'd be blind to accidentally exposing one of those APIs).
,
Jun 9 2016
,
Jun 23 2016
,
Jun 23 2016
,
Jan 3 2017
,
Jan 3 2017
,
Jun 26 2017
,
Sep 8 2017
,
Sep 11 2017
Perhaps we should attempt to fix this next quarter?
To summarize this bug, we need to do two things:
1. hide window.{internals,testRunner) in --stable-release-mode, and
2. fix the webexposed/ tests not to use these APIs.
Step 2 would be lengthy but mechanical: we seem to have ~13 tests relying on testRunner, where we can to switch to in-html asserts (using testharness.js).
,
Sep 11 2017
,
Jun 21 2018
Added to Feature Control code health hotlist. |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by rbyers@chromium.org
, Jun 9 2016