document.activeElement will return null if there is no document
element. This may happen if, for example, in an HTML document the
<body> element is removed.
The WPT test test_sucess_without_body in get_active_element.py
is wrong. It expects Get Active Element to return null if there
is no document element, but following a recent specification change
we want it to return a no such element error.
Specification change: https://github.com/w3c/webdriver/pull/1157
MozReview-Commit-ID: LQJ3slV9aty
--HG--
extra : rebase_source : cc349bb642f57bb2203d126ecd86d8d988d90301
Instead of having to assign resp.body.value explicitly when dealing
with WebElements, this makes it possible to return WebElement
references directly from GeckoDriver command handlers. This was
not possible in the past because web element representations were
just plain object literals.
MozReview-Commit-ID: EPqXJ2gpNen
--HG--
extra : rebase_source : 334a5f4f597259c28b3c00c93f3ad24912d5dd87
Run those fragment URL tests in test_transitions_per_property.html for
clip-path only because shape-outside will resolve URL fragments (i.e. #a),
so the computed value of URL fragment will have document URL as a prefix,
which won't match. Also, added absolute URL tests for both clip-path and
shape-outside.
MozReview-Commit-ID: 8SUpfTaV9cz
--HG--
extra : rebase_source : e5c180a2ef293d70fa33133012023e9360eef98e
If the DOM click event does not fire, which currently happens in
this edge case where Firefox does not bubble the click event up
to <body>, interaction.flushEventLoop will hang forever.
This is believed to be a bug in Gecko, but it is probably safer to
use a TimedPromise here in case anything else bad were to happen.
Thanks-to: Alexei Barantsev <barancev@gmail.com>
MozReview-Commit-ID: KZBdR8zcfJb
--HG--
extra : rebase_source : aba0c4c810a703877d858fa6f4398ad960ece0d1
The WebDriverException.http_status can be None if it falls back to
the WebDriverException abstract class.
MozReview-Commit-ID: mgWKfDtTYO
--HG--
extra : rebase_source : fc0f42e1e26e7da9a834384d78345365a1a8ccfc
This is a manual test, and the timeout often prevents it from being run to
completion manually.
MozReview-Commit-ID: DXnqycq5hix
--HG--
extra : rebase_source : d058a76b173a951e112d1eef72aacf6d264ea60d
Hopefully most of these changes are self-explanatory however a few notes follow.
* In timing-model/animations/play-states.html, as well as making the tests match
the updated spec, one or two tests have also been moved to better reflect the
order in the spec (to make it obvious which branch of the algorithm is being
tested).
* In timing-model/animations/set-the-timeline-of-an-animation.html we previously
had two tests that check:
a) That the playState was 'pending' before and after setting the timeline.
b) That the playState was 'pending' before setting the timeline and then,
after setting the timeline and waiting on the ready promise, would become
'running'.
Likewise we had the same test for pausing.
Since these are basically the same test--(b) just adds the wait on the ready
promise--we combine them here into one test that covers both (a) and (b).
MozReview-Commit-ID: CLoDJvsdwmF
--HG--
extra : rebase_source : c2f34fa6614795f2d3ba9ca3e572f11306f96463
Currently we have a test in interfaces/Animation/playState.html that somewhat
randomly tests the result of the `playState` member.
However, there's no complex logic associated with the `playState` member in the
IDL. It simply returns "The play state of this animation". The logic we need to
test is in the definition of 'play state' which is in the timing model.
As a result we move this test to timing-model/animations/play-states.html
However, this test as it stands does not test the calculation of the play state
in a particularly thorough manner. For example, it does not contain a single
test for the 'finished' state.
Given that this patch series will change the definition of the 'play state' we
first fix this test to cover each of the different cases in the definition of
the 'play state' prior to these changes. That is, we update the tests based on
the definition of 'play state' here:
https://www.w3.org/TR/2016/WD-web-animations-1-20160913/#play-states
(Note that at this point in the patch series the pref to turn on the changed
definition behavior has not been enabled even for tests so this patch is
actually testing the behavior when that pref is false. We'll replace much of
this test in the next patch but by updating the test first, we should be able to
more clearly see the changes in the next patch.)
MozReview-Commit-ID: 1xkOmuY1SxD
--HG--
rename : testing/web-platform/tests/web-animations/interfaces/Animation/playState.html => testing/web-platform/tests/web-animations/timing-model/animations/play-states.html
extra : rebase_source : 1890e1b4db007452df393e8a9e4b3ccf42bca237
This fixes the problem that wdspec tests fail silently when there
is a problem with collecting the file in pytest. For example,
if the Python test file contains a SyntaxError we currently fail
to record this as ERROR, and instead report it as OK.
MozReview-Commit-ID: 5W46gaLQa0c
--HG--
extra : rebase_source : de7be091949f792be9d72cacac5c630e53cf2c3a
Calling shutdown() causes two things to happen:
1) A 'logger_shutdown' action is implicitly logged so handlers/formatters
can do things on log shutdown.
2) Further attempts to use the logger raise a LoggerShutdownError.
The shutdown() method is also implicitly called when the StructuredLogger's
destructor is run, or when exiting a context manager.
MozReview-Commit-ID: LLNojVoCBZY
--HG--
extra : rebase_source : 373b7e70f6a2121d29d7deccfe9bf4cc0f402e3b
