This isn't necessary, since it has only 2 static children (the selected tab's content
and the customizable UI), and their visibility is toggled in a single place. We already
toggle .hidden for both - there's no need for a separate deck.
Differential Revision: https://phabricator.services.mozilla.com/D34792
--HG--
extra : moz-landing-system : lando
Improve support for Python 3 by running modernize over adb.py and a few other related changes.
Differential Revision: https://phabricator.services.mozilla.com/D19306
--HG--
extra : moz-landing-system : lando
In `2_cues_overlapping_partially_move_up.vtt`, the second cue was put on the 99% place where the second cue is `1%` higher than the first cue, and then we would move the second cue up by a line box height in order to prevent those two cues overlapping.
Therefore, in the reference files, the second cue should be 1%(of 180px) higher than its original place.
Differential Revision: https://phabricator.services.mozilla.com/D34609
--HG--
extra : moz-landing-system : lando
In order to simulate the line break correctly and robustly, we use <div> to trigger the line break, instead of using `martin-top` to adjust the box position, which have to specify the actual line box's size. Notice that the line box size is not actullay equal to the font size, it would make the offset really tricky (like moving aroung 9.33px if font is 9px) and not robust.
In addtion, as the main purpose of these tests are to check whether the second cue would be moved upward and not overlapped with the first box, we change the line position to `100%`, which can eliminate unnecessary moving. If we set `position:50%` for first box, the first box's top would be aligned to the 50% place height of video rendering area, and the second cue would be put above the first cue, which makes that the reference files have to use more complicated CSS style in order to get the same rendering. But if we put the first cue on the bottom, it's way more easier to write the style for the make-up cue line in the reference files.
Differential Revision: https://phabricator.services.mozilla.com/D23272
--HG--
extra : moz-landing-system : lando
If cue's `position` is smaller than `50`, the cue box would stay left and reduce its box size. If cue's `position` is larger than `50` the cue box would stay right and also reduce its box size [1].
Therefore, for `align_center_position_lt_50-ref` and `align_center_position_lt_50_size_gt_maximum_size-ref`, we should set `left:0` because the box is in the left side.
For `align_center_position_gt_50-ref`, we have to set `right:0`.
[1] https://searchfox.org/mozilla-central/source/dom/media/webvtt/vtt.jsm#641-685
Differential Revision: https://phabricator.services.mozilla.com/D33383
--HG--
extra : moz-landing-system : lando
In reference files `align_center_position_*.html`, the text `Awesome!!!` doesn't exceed the line box's boundary, so it won't wrap to multiple lines.
In other files, we don't have to set the break explicitly, texts would automatically wrap to multiple lines when it exceeds the line box's boundary.
Differential Revision: https://phabricator.services.mozilla.com/D33381
--HG--
extra : moz-landing-system : lando
These wpt are actually able to pass without having any modification, we should enable them.
Differential Revision: https://phabricator.services.mozilla.com/D34103
--HG--
extra : moz-landing-system : lando
Using `nsContentUtils::IsInSameAnonymousTree(this, aElement)` to check will ignore all mutation notification for anonymous <use> which will happen when <use> is nested. This is the cause that second-level <use> isn't properly synced with element mutation.
We should use the referenced element instead of `this` in the check condition.
Differential Revision: https://phabricator.services.mozilla.com/D34284
--HG--
extra : moz-landing-system : lando
Add a new wpt 'start_alignment.html' to ensure that two cues would have different text alignment.
In addition, add `line:0` in vtt file to put cue on the top in order to reduce the complexity of using CSS to markup the test, because if we don't specifiy the postion for cue, those two cues won't be put the bottom of the video, instead they would be move upward one line above the bottom according to the spec.
The reason is that the base moving unit for adjusting cue box's position is the Bsize of the first line box, it would require extra moving if one cue contains two different cues which line boxes are not the same height.
Differential Revision: https://phabricator.services.mozilla.com/D34641
--HG--
extra : moz-landing-system : lando
Disable on Windows is because sometime iframe can't load successfully, which makes our test file showing wrong image.
Differential Revision: https://phabricator.services.mozilla.com/D34778
--HG--
extra : moz-landing-system : lando
It's no need to add 'controls' attribute in this test because it's totally unrelated with navigation and we even have to add extra offset for the cue text in the reference file.
Differential Revision: https://phabricator.services.mozilla.com/D34777
--HG--
extra : moz-landing-system : lando
With this patch Marionette registers globally for the dialog notifications
and events while a session is active. Also it provides an interface for
custom dialog handlers to hook in.
Instead of the callbacks custom events could have been fired, but that would
be some more work, and should preferable be done in a follow-up bug.
Differential Revision: https://phabricator.services.mozilla.com/D34139
--HG--
extra : moz-landing-system : lando
This allows me to run 'mach gtest "APZ*"' and other short runs of gtest
that were previously failing.
Differential Revision: https://phabricator.services.mozilla.com/D34764
--HG--
extra : moz-landing-system : lando
Since the media element is playing directly after play(), not waiting for the
readyState to advance before play()ing could leave the play promise from play()
unhandled until cleanup, when it would be rejected by the load algorithm.
This would happen if a timeupdate event is raised before the first frame comes
in to update the readyState, which resolves the play promise.
Waiting for the readyState to advance before play()ing seems like the cleanest
fix wrt testing currentTime after the first timeupdate event.
Depends on D33655
Differential Revision: https://phabricator.services.mozilla.com/D34686
--HG--
extra : moz-landing-system : lando
This does several things:
- Split the test up, so one assert doesn't fail the entire test suite
- Check preload, playbackRate and defaultPlaybackRate attributes after unsetting srcObject
- Check setting currentTime before loading (default playback start position),
and after loading (official playback position) separately
- Check that duration is changed to a real number on ending
- Check that HAVE_ENOUGH_DATA is reached by only assigning srcObject
- And other minor things and formatting
Differential Revision: https://phabricator.services.mozilla.com/D33647
--HG--
extra : moz-landing-system : lando
This is not used yet but will be eventually so I'm just going to
add it now.
Depends on D34623
Differential Revision: https://phabricator.services.mozilla.com/D34624
--HG--
extra : moz-landing-system : lando
Ensure we force-disable webrender unless it is explicitly enabled
via the --enable-webrender flag. Also add missing env variables for
the telemetry_client.py case which appears to be a copy/paste error
that was not caught because we never run that test with WR enabled.
Depends on D34622
Differential Revision: https://phabricator.services.mozilla.com/D34623
--HG--
extra : moz-landing-system : lando
This drops the --disable-webrender option (which force-disables WR)
and treats the lack of an --enable-webrender as if --disable-webrender
was provided.
Differential Revision: https://phabricator.services.mozilla.com/D34622
--HG--
extra : moz-landing-system : lando
Due to bug 1557457 it can happen that loading a web page with eg.
a HTTP auth prompt, no modal dialog will be shown by Firefox. As
such disable this preference for now globally, until all the issues
with privileged content processes have been solved.
Differential Revision: https://phabricator.services.mozilla.com/D34710
--HG--
extra : moz-landing-system : lando
This has been broken since bug 1545629 landed, when we started using
git to (quickly) get hashes of unchanged files. Unfortunately, the
logic for finding changed files only worked when the test root was the
root of the git repository.
Differential Revision: https://phabricator.services.mozilla.com/D34702
--HG--
extra : moz-landing-system : lando
It's not complete I think, but it covers the constructor and some bits of
behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D32175
--HG--
extra : moz-landing-system : lando
Enable the web platform tests for clearkey scheme checking. Since these tests
simply check if the functionality is implemented, and do not check if the
browsers actually support different encryption schemes, it's okay to do this
even though we don't have cbcs support in clearkey yet. I.e. it's enough that a
page can ask "do you support cbcs in clearkey?" to Firefox to pass the test, the
answer from Firefox doesn't have to be "yes."
Add the pref setting to the DRM scheme checking test, though leave the
expectations as they are on this test, as in automation the test will still not
pass due to Widevine downloads being blocked. My hope is that we can find a
solution to this Widevine download issue in automation, at which point we'd
expect that tests to start passing due to the pref added in this patch -- at
which point we could toggle the expectations.
Differential Revision: https://phabricator.services.mozilla.com/D34303
--HG--
extra : moz-landing-system : lando
Byron Campen [:bwc]
Brian Grinstead
Valentin Gosu
Marian Raiciof
Arnold Iakab
Charlie Marlow
Alastor Wu
violet
Emilio Cobos Álvarez
shindli
Brindusan Cristian
Thomas Nguyen
Narcis Beleuzu
Cosmin Sabou
Maja Frydrychowicz
Ehsan Akhgari
Henrik Skupin
Geoff Brown
Boris Zbarsky
Andreas Pehrson
Dorel Luca
Kartikaya Gupta
Sam Sneddon
Oana Pop Rus
Paul Adenot
Bryce Van Dyk