CLOSED TREE
Backed out changeset 5c65378feacd (bug 1298818)
Backed out changeset 72f66ce70dd8 (bug 1298818)
Backed out changeset eb17677e8167 (bug 1299838)
This allows other UAs to use it, removes duplicated checks, and
increases the chance of us noticing if the spec changes. Some of the
expected values in our mochitest were contrary to the spec.
I checked the new expected failures against the spec and the other UAs.
I filed a spec bug for one group because it was contrary to all UAs
(although IMO the spec makes more sense and the UAs are buggy), and the
others are fixed in the next patch.
MozReview-Commit-ID: 1j11XgfuErB
The VideoPuppeteer now uses played ranges where possible to calculate the
remaining time. It will also use the played ranges to determine the expected
duration where possible. This is more accurate than using the time when the
tests first poll the video. The first poll time was previously self._start_time,
but I've renamed this to self._first_seen_time, to reduce ambiguity -- the video
may have started playing before this time.
The playback_done function has had it's remaining time check relaxed. Previously
it was possible to skip over the window where a video would be considered
complete, that window is now expanded so that if the start threshold is passed
the video is considered played.
A concrete example: the tests could play a 90 second video, but the duration of
the test is set to 60 so only part of the video need be played back before the
test completes. If a 1 second interval was used in the tests there would be a
window between 59 to 61 seconds during which if the video were polled it would
be considered complete. However, due to latency polling may not take place in
this window, leading to racy fails. Now the tests will consider any point beyond
59 seconds to be complete.
MozReview-Commit-ID: J6DpqCbZxUg
--HG--
extra : rebase_source : 7990e4eee0bce30718b875f652c7148110cd4c3f
This is a quality of life change. Since VideoPuppeteer uses, and since I plan on
using the played ranges of a video element more, it is useful to output them as
part of the str representation.
MozReview-Commit-ID: LwVPfVtFF1v
--HG--
extra : rebase_source : 1ebe4b7a7176a15f7e9300dee84103a8f6b86708
This patch prevents the Windows widget code from dispatching the contextmenu
event if APZ is handling touch input. Instead, the APZ code processes the
raw touch input, and will fire a contextmenu event when the user lifts their
finger after a long-press action, in keeping with the Windows platform
convention. Doing it this way also allows us to respect web conventions where
the web content can prevent the contextmenu event from firing by calling
preventDefault on the touchstart event; this was not possible when dispatching
the contextmenu event directly from the widget code.
This also makes long-pressing on browser chrome components work properly, as
it just shifts the point in time that the contextmenu event is fired without
changing any of the code that triggers the XUL popup. However, some changes
were needed to have the widget code ignore the synthetic mouse events that
the Windows platform sends us, because those would otherwise immediately
dismiss the contextmenu popup after it appeared.
MozReview-Commit-ID: 9HFZLC6xUAi
--HG--
extra : rebase_source : aea932d9f95454c585bcdf962d151c946b5c6ec2
hasFeature() always returning true matches the current DOM spec. SVG 2
has removed requiredFeatures. Chrome has had both of these always
return true since 2014, and they seem to have had no problems.
Even requiredFeatures="" (empty string) now returns true, matching
Chrome.
MozReview-Commit-ID: 1LEu3iK4R94
Wes Kocher
Olli Pettay
Kyle Machulis
Cameron McCormack
Andrea Marchesini
Sebastian Hengst
Tom Schuster
Ryan VanderMeulen
Ethan Lin
Edgar Chen
Stone Shih
Jimmy Wang
Daosheng Mu
Phil Ringnalda
Aryeh Gregor
Bryce Van Dyk
Kartikaya Gupta
Andi-Bogdan Postelnicu
Michael Layzell
Nicolas Silva
Sotaro Ikeda
Jean-Yves Avenard