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
We can actually let `processCue()` to handle rendering cues or cleaning displayed cues, no need to use another way to clear the cue.
The advantages is to make the code cleaner and easier to read, now we just need to know JS side would handle all rendering stuffs for us. We don't need to have different behavior when there is no showing cue.
The way we clear displayed cues are intuitive, we would remove all child nodes under the overlay, which are used to display cues.
Differential Revision: https://phabricator.services.mozilla.com/D31171
--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
We can actually let `processCue()` to handle rendering cues or cleaning displayed cues, no need to use another way to clear the cue.
The advantages is to make the code cleaner and easier to read, now we just need to know JS side would handle all rendering stuffs for us. We don't need to have different behavior when there is no showing cue.
The way we clear displayed cues are intuitive, we would remove all child nodes under the overlay, which are used to display cues.
Differential Revision: https://phabricator.services.mozilla.com/D31171
--HG--
extra : moz-landing-system : lando
We should add some debug logs, which should be easily enable and disable, in vtt.jsm in order to increase the efficiency of debugging.
Differential Revision: https://phabricator.services.mozilla.com/D30798
--HG--
extra : moz-landing-system : lando
When adjusting box's position, we would choose a axis first and move the box along this axis to see whether we can place this box without overlapping with other boxes and fully inside the rendering area.
If the box has been over the boundary along the moving direction, we should move box back to the original position and change the moving direction to see whether we can find another best place for the box.
Although the adjustment can run without timeout now, it still doesn't match the result of the reference, so change the state to `fail`.
Differential Revision: https://phabricator.services.mozilla.com/D29765
--HG--
extra : moz-landing-system : lando
According to the spec [1] 7.2.10.2, we should use the first line box's height or width as positioning unit to adjust box's position.
We will also use this value to adjust box when `snap-to-line` is false.
There, we implement a new chrome-only API to acquire this information, which would return the first line box's size in the `block` frame.
[1] https://www.w3.org/TR/webvtt1/#ref-for-webvtt-cue-snap-to-lines-flag-12
Differential Revision: https://phabricator.services.mozilla.com/D29745
--HG--
extra : moz-landing-system : lando
When adjusting cue's position, the goal is to place cue boxes fully inside the rendering area, and place in the right place.
In order to check whether the box is correctly inside the rendering area, we have to know the correct size of the cue box.
Therefore, we implement the new chrome-only APIs to acquire this information (box's height and width), and this returned value won't be affected by CSS transformation, which is good for positioning.
Differential Revision: https://phabricator.services.mozilla.com/D27178
--HG--
extra : moz-landing-system : lando
There is no need to have an anonymous function after we replace all `var` to `let`, now those variables won't pollute outer scopes.
Differential Revision: https://phabricator.services.mozilla.com/D20028
--HG--
extra : moz-landing-system : lando
In order to keep the local variable only visible inside the function scope, we should only use 'let' for those variables.
Differential Revision: https://phabricator.services.mozilla.com/D20027
--HG--
extra : moz-landing-system : lando
Remove those funcitons which are used to implement the previous way to move the cue box.
Differential Revision: https://phabricator.services.mozilla.com/D19610
--HG--
extra : moz-landing-system : lando
According to the spec 7.2.10, step1 to step10 (snap-to-line is true) and step1 to step2 (snap-to-line is flase) [1], we would adjust cue box's position depending on the algorithm.
The algorithm would calculate the cue box's top (or left) position depending on the writing direction, and move the box to the specific position.
However, if the cue box is overlapping with other cue boxes in the rendering area, we would still need to adjust its postion, which will be implemented in next patch.
[1]
https://w3c.github.io/webvtt/#ref-for-webvtt-cue-snap-to-lines-flag-12https://w3c.github.io/webvtt/#ref-for-webvtt-cue-snap-to-lines-flag-13
Differential Revision: https://phabricator.services.mozilla.com/D19609
--HG--
extra : moz-landing-system : lando
It's confused that we have both simpleBoxPosition object and BoxPosition object, we should only use one format to perform all box related operations.
Therefore, BoxPosition should be able to be initiaized by StyleBox, HTMLElement or BoxPosition.
In addition, as `right` and `bottom` can be calculated from other attributes, we remove these two attributes from BoxPosition, and use getter to get the correct value, which can reduce some unnessary modification when we changes the `height` or `width`. In order to implement a more readable getter, so we change `BoxPosition` to class-based.
Differential Revision: https://phabricator.services.mozilla.com/D22809
--HG--
extra : moz-landing-system : lando
When calculating font size, we should use the original bounding box as a reference, or it would cause incorrect font size scale.
Differential Revision: https://phabricator.services.mozilla.com/D20026
--HG--
extra : moz-landing-system : lando
There is no need to have an anonymous function after we replace all `var` to `let`, now those variables won't pollute outer scopes.
Differential Revision: https://phabricator.services.mozilla.com/D20028
--HG--
extra : moz-landing-system : lando
In order to keep the local variable only visible inside the function scope, we should only use 'let' for those variables.
Differential Revision: https://phabricator.services.mozilla.com/D20027
--HG--
extra : moz-landing-system : lando
Remove those funcitons which are used to implement the previous way to move the cue box.
Differential Revision: https://phabricator.services.mozilla.com/D19610
--HG--
extra : moz-landing-system : lando
According to the spec 7.2.10, step1 to step10 (snap-to-line is true) and step1 to step2 (snap-to-line is flase) [1], we would adjust cue box's position depending on the algorithm.
The algorithm would calculate the cue box's top (or left) position depending on the writing direction, and move the box to the specific position.
However, if the cue box is overlapping with other cue boxes in the rendering area, we would still need to adjust its postion, which will be implemented in next patch.
[1]
https://w3c.github.io/webvtt/#ref-for-webvtt-cue-snap-to-lines-flag-12https://w3c.github.io/webvtt/#ref-for-webvtt-cue-snap-to-lines-flag-13
Differential Revision: https://phabricator.services.mozilla.com/D19609
--HG--
extra : moz-landing-system : lando
It's confused that we have both simpleBoxPosition object and BoxPosition object, we should only use one format to perform all box related operations.
Therefore, BoxPosition should be able to be initiaized by StyleBox, HTMLElement or BoxPosition.
In addition, as `right` and `bottom` can be calculated from other attributes, we remove these two attributes from BoxPosition, and use getter to get the correct value, which can reduce some unnessary modification when we changes the `height` or `width`. In order to implement a more readable getter, so we change `BoxPosition` to class-based.
Differential Revision: https://phabricator.services.mozilla.com/D22809
--HG--
extra : moz-landing-system : lando
When calculating font size, we should use the original bounding box as a reference, or it would cause incorrect font size scale.
Differential Revision: https://phabricator.services.mozilla.com/D20026
--HG--
extra : moz-landing-system : lando
Alastor Wu
Narcis Beleuzu
Andreea Pavel
shindli
Kris Maglione