Two changes that recently landed in web-platform-tests make it easier to
write tests that require access to non-web-exposed features:
* testdriver APIs now work in many situations involving multiple
browsing contexts origins
* SpecialPowers is now available in gecko-only web-platform-tests
testdriver
==========
testdriver [1] is a cross-browser API provided by wpt for performing
privileged actions, notably those involving trusted user gestures.
Because it's cross-browser this is the preferred way to write tests
requiring such interactions, where possible.
The default implementation of testdriver uses WebDriver on the backend,
and where specs provide WebDriver APIs for automation (e.g. [2]) they
can be exposed to wpt via testdriver.
Previously testdriver APIs only worked in the browsing context
containing the test harness. Now it's possible to use them in any
browsing context that is reachable from the context containing the
harness (i.e. any context that can postMessage to the test window). Full
documentation is given in [1].
Unfortunately handling cases where the contexts can't communicate e.g.
rel=noopener remains challenging because of limitations in webdriver/the
way we communicate between the harness and the browser. It isn't
impossible to fix these cases, but will require additional work. Please
let me know when you're blocked writing cross-browser tests because of
such limitations since this will help prioritise the work.
SpecialPowers
=============
The SpecialPowers API that's commonly used in gecko-specific tests in
other harnesses is now available for use in gecko-specific
web-platform-tests i.e. those that live in
testing/web-platform/mozilla/tests These tests obviously can't be run
cross-browser and aren't upstreamed. Therefore it's preferable to write
a shareable test using testdriver or similar where possible. However
there are some cases where that simply doesn't provide the required
features and rather than forcing authors to write mochitest-plain tests
for those cases it's now (hopefully) possible to do everything required
for content tests in wpt.
Currently this is only enabled for js (i.e. testharness) tests. If there
are use cases that require SpecialPowers in other test types (e.g. wpt
reftests) please let me know.
To be really clear here, this isn't suitable for anything that would
have previously used e.g. a browser-chrome test. The intent is to make
it possible to test web apis in a way that requires occasional access to
internals, not to allow testing the internals themselves.
Future Work
===========
We want to keep making this kind of improvement to wpt, especially where
doing so allows us to drive compatibility improvements by writing
cross-browser tests where it was previously impossible.
We are proposing and making an initial implementation of the Browser
Testing API spec [3], which is designed to provide a place to specify
test-only features that don't make sense in WebDriver; the initial scope
is a function to invoke a garbage collection; this has been a
longstanding feature request. If there are additional APIs that people
think would make sense in such a spec, please let me know.
In general if there are places where wpt doesn't meet our requirements
for testing, or there are chances to improve the test writing ergonomics
please let me know and we can make sure that work gets appropriate
priority. Shared tests remains a key technique for ensuring
interoperability between different browser engines.
[1] http://web-platform-tests.org/writing-tests/testdriver.html
[2] https://w3c.github.io/permissions/#automation
[3] https://jgraham.github.io/browser-test/
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
