Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
This required a change to vtt.jsm because it previously used clientHeight to determine whether the controls were showing.
Now that the controls are visually hidden but not display: none, that doesn't work because clientHeight can be > 0 even when the controls are visually hidden.
The hidden attribute is now used instead.
Differential Revision: https://phabricator.services.mozilla.com/D87403
Accessing `offsetXXX` attributes of element, it would trigger reflow, and sometime it would result in a re-entry of `processCue()` because we would call `processCue()` when `resizecaption` occurs.
One specifical case is that, assigning CSS properties `min-width` and `max-width` at the same video element, in thise case, when we re-enter the `processCues()` and access `offsetXXX`. It seems that the layout system would reprocess those properites again and again and dispatch `resizecaption` when we access `offsetXXX`, which causes an infinite loop, starting from receving `resizecaption`, then calling `processCue()`, accessing `offSetXXX`, triggering reflow, sending `resizecaption` event again.
Therefore, we should stop revisiting `processCues()` if we're already running a processing, we should run a processing once at a time.
Differential Revision: https://phabricator.services.mozilla.com/D45421
--HG--
extra : moz-landing-system : lando
We have already had a exactly same function, so can remove a redundant one.
Differential Revision: https://phabricator.services.mozilla.com/D41132
--HG--
extra : moz-landing-system : lando
When adjusting cues with `snapToLines=false`, first we would generate an array with all different axises which we would use to move cue on the specific direction.
However, for the different writing directions, we should have different priority for the moving directions.
For example, if the wriring direction is `horizontal`, which means cues will grow from the top to the bottom, then moving cues along the `y` axis should be more important than moving cues along the `x` axis, and vice versa for those cues growing from the left to right, or from the right to the left.
After decided the moving direction, then we have to decide the moving offset. Now we use line box's Bsize as a basic moving unit.
Moving cues, however, by such as large distance as a time would cause too many redudant space between cue boxes, which doesn't provide a good enough visual arrangement result. Therefore, we divide the Bsize by a factor, which can control the granularity of the moving unit and can still preverse a reasonable space between boxes. That can provide way better visual result than the one we had used before, and still has certain good performance comparing with moving 1px at a time.
Differential Revision: https://phabricator.services.mozilla.com/D41131
--HG--
extra : moz-landing-system : lando
When adjusting the position of the cue box, if we can't find a proper place to display the cue within the video rendering area, we should return `null` and not to show it on the screen.
Differential Revision: https://phabricator.services.mozilla.com/D40901
--HG--
extra : moz-landing-system : lando
When calculating position percentage, `top` should divide the height of the video rendering area, and `left` should divide the width of the video rendering area.
Differential Revision: https://phabricator.services.mozilla.com/D40900
--HG--
extra : moz-landing-system : lando
According to the spec [1], the background box should be `display:inline`.
Therefore, we should create a `<span>`, which already is an inline element, for the background box, not a `<div>`, which is a block element.
In addition, when the pseudo element is enabled, even though the element is currently a `div`, it doesn't match the div `{ display: block; }` rule from the UA style sheet because the pseudo element only matches `::cue` rules. It also has the initial value of display which is `inline`.
[1] https://www.w3.org/TR/webvtt1/#webvtt-cue-background-box
Differential Revision: https://phabricator.services.mozilla.com/D36849
--HG--
extra : moz-landing-system : lando
If the background node is not a pseudo element, these properties would actually be inherited, so we have no need to set them again.
Differential Revision: https://phabricator.services.mozilla.com/D36848
--HG--
extra : moz-landing-system : lando
In order to clearly see what properties are applied on the root node, create a function to list all of them together.
Differential Revision: https://phabricator.services.mozilla.com/D36847
--HG--
extra : moz-landing-system : lando
Setting cue's position would also affect cue box's size which would be determined by cue's position alignment as well. If the cue box's width or height is zero, it means that this box should not be display on the screen and we should clear cue's display state as well.
Differential Revision: https://phabricator.services.mozilla.com/D35693
--HG--
extra : moz-landing-system : lando
When we start a new load, all previous data fetching from the previous listener and all state changing applied to track element should be ignored.
Therefore, we add a new method `Cancel()` which owner of the listener should call when we would like to discard current listener.
Differential Revision: https://phabricator.services.mozilla.com/D36407
--HG--
extra : moz-landing-system : lando
According to the spec 7.2.10.17 [1], if we have tried both direction and there is no place to put the cue inside the rendering area without overlapping with other cues or the boundary of rendering area, then we have to discard all CSS boxes, which means that we should not display this cue.
[1] https://www.w3.org/TR/webvtt1/#processing-cue-settings
Differential Revision: https://phabricator.services.mozilla.com/D33729
--HG--
extra : moz-landing-system : lando
When the check whether boxes are overlapping or box is placing out side the container boundary, we should use fuzzy for this checking if the difference is small enough to be ignored.
When two boxes just overlapped a little bit (like < 0.01 px), which user can't be aware of it and looks like just placing side by side, we acutally don't need to adjust box position again.
Otherwise, it would result in an obvious space between two boxes which makes it look more weird because the basic moving unit for adjusting boxes is the Bsize of the first line box.
In addition, adding fuzzy can also ensure rendering testing can be more robust, because on some platform the cues would overlap a really tiny amount of pixels and causes box moving up more than our expectation, which result in incorrect rendering comparasion.
Differential Revision: https://phabricator.services.mozilla.com/D34577
--HG--
extra : moz-landing-system : lando
According to the spec 7.2.10.17 [1], if we have tried both direction and there is no place to put the cue inside the rendering area without overlapping with other cues or the boundary of rendering area, then we have to discard all CSS boxes, which means that we should not display this cue.
[1] https://www.w3.org/TR/webvtt1/#processing-cue-settings
Differential Revision: https://phabricator.services.mozilla.com/D33729
--HG--
extra : moz-landing-system : lando
Because of bug1558431, now the text alignment for `bidi` won't take effect on the initial reflow of the document, so we have to delay setting 'unicode-bidi' in order to trigger reflow again as a workaround.
It would make the `bidi` text showing correctly after reflow.
Differential Revision: https://phabricator.services.mozilla.com/D34640
--HG--
extra : moz-landing-system : lando
It would be more convenient to use the pref to dynamically switch vtt debug log on/off without changing any code.
Differential Revision: https://phabricator.services.mozilla.com/D33220
--HG--
extra : moz-landing-system : lando
According to the spec [1] step 13, if we won't reset cues' display state, we should reuse them.
If the amount of displaying cues changes, which means some cues should disappear from the screen and some of them should still be showed, we have to clear the screen and resume displaying cues' display state.
As the amount of displaying cues might affect the computed result of cues' display state, if we recompute cues' display state in this situaion, the result would be different from the one we had last time.
For example, there are two cues, Cue0 [0:2], Cue1 [1:5]. When Cue0 disappears, Cue1 should stay in the same position.
```
[playing at 1s]
*-------------------*
| Cue1 |
| Cue0 |
*-------------------*
[playing at 3s] (correct)
*-------------------*
| Cue1 |
| |
*-------------------*
[playing at 3s] (incorrect)
*-------------------*
| |
| Cue1 |
*-------------------*
```
[1] https://w3c.github.io/webvtt/#rules-for-updating-the-display-of-webvtt-text-tracks
Differential Revision: https://phabricator.services.mozilla.com/D32935
--HG--
extra : moz-landing-system : lando
Cue's display state is a DIV element with corresponding CSS style to display cue on the screen. When the cue is being displayed first time, we will compute its display state.
After that, we could reuse its state until following conditions happen.
(1) control changes : it means the rendering area changes so we should recompute cues' position.
(2) cue's `hasBeenReset` flag is true : it means cues' line or position property has been modified, we also need to recompute cues' position.
(3) the amount of showing cues changes : it means some cue would disappear but other cues should stay at the same place without recomputing, so we can resume their display state.
The new state includes `REUSE`, `REUSE AND CLEAR` and `COMPUTE AND CLEAR`, our current behavior doesn't handle `REUSE AND CLEAR, which would be implemented in next patch.
Differential Revision: https://phabricator.services.mozilla.com/D32934
--HG--
extra : moz-landing-system : lando
According to the spec [1], text node has a value to represent its text, even when its text is an empty string.
Therefore, we should append a text node with a value for empty text string on the DocumentFragment we return, when input sting is an empty string.
[1] https://w3c.github.io/webvtt/#webvtt-text-object
Differential Revision: https://phabricator.services.mozilla.com/D33215
--HG--
extra : moz-landing-system : lando
If the amount of cues which are going to be displayed is different from the one we displayed last time, we have to compute cues' display state again because cue's position might be affected by other cues.
Differential Revision: https://phabricator.services.mozilla.com/D31170
--HG--
extra : moz-landing-system : lando
Kartik Gautam
Cosmin Sabou
Simon Giesecke
alwu
Ricky Stewart
Bogdan Tara
Dorel Luca
James Teh
Kris Maglione
Mark Banner
Mihai Alexandru Michis
Narcis Beleuzu