Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Make testharness tests run in a top-level browsing context #13966

Merged
merged 3 commits into from
Dec 11, 2018
Merged

Make testharness tests run in a top-level browsing context #13966

merged 3 commits into from
Dec 11, 2018

Commits on Nov 8, 2018

  1. Make testharness tests run in a top-level browsing context 

    Traditionally testharness tests ran in a auxillary browsing context
opened using window.open and with access to the opener. This works
well because the long-lived nature of the opener helps to avoid some
of the race conditions that would otherwise occur. But it doesn't work
*that* well; the recent refactor to stop continually focusing the
opener broke tests that alter document.domain or otherwise prevent the
opener being same-domain with the test window. And future platform
features may cause the opener to be nulled out entirely so even a
postMessage based fix wouldn't work.

To solve all of this, this patch refactors things so that the initial
window doesn't contain any logic at all and is just used to keep the
browser alive between tests. Most of the logic moves to
testharnessreport.js which is loaded once per test. In order to get
the right timeout when timeout_multiplier is set this requires an
addition to the product API in wptrunner to expose a function for
getting the timeout multiplier. This allows us to get the
timeout_multiplier for testharness tests upfront and avoids the need
to change the content of testharnessreport when we start running
testharness tests, or to restart the server for each test type.

The main issue with the single-window implementation is that we need
to start injecting script once the test page has loaded
testharnessreport.js. For most browsers we are able to use
pageLoadStrategy=eager to control this; in that case we can start
running tests once DOMContentLoaded is reached. Chrome doesn't support
this pageLoadStrategy, however, so we have to fake support with custom
script.
    @jgraham
    jgraham committed Nov 8, 2018
    Configuration menu
    Copy the full SHA
    ec633de View commit details
    Browse the repository at this point in the history

  2. Fix document.write tests to not assume globals exist after document.open

    @jgraham
    jgraham committed Nov 8, 2018
    Configuration menu
    Copy the full SHA
    196dd4c View commit details
    Browse the repository at this point in the history

  3. Remove reference to missing run() function in CSS tests

    @jgraham
    jgraham committed Nov 8, 2018
    Configuration menu
    Copy the full SHA
    2ed77c9 View commit details
    Browse the repository at this point in the history