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
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
- Fixes expandFrames() to ensure the thread property is set
- Refactors getSourceLocationFromMouseEvent to use fromEditorLine
- Replaces dwarf_to_json (for proper DWARF conversion)
Differential Revision: https://phabricator.services.mozilla.com/D33092
--HG--
extra : moz-landing-system : lando
Remove the mozpersist attribute and XULDocument requirement to use XUL
persistence and allow any system privilege document to use it by default.
Differential Revision: https://phabricator.services.mozilla.com/D34602
--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
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
The `WebProgress#sendLoadCallResult` method only existed to send a empty async
message and was only called from the `WebNavigationChild`. Since
`WebNavigationChild` is in the process of being removed, it makes sense to
inline the replaced method into its call site.
Differential Revision: https://phabricator.services.mozilla.com/D34566
--HG--
extra : moz-landing-system : lando
When `TabParent::ReconstructWebProgressRequest` was introduced in
31b206e2046f63af31424489e3d61d7761805878, it mistakenly was unconditionally
constructing an `nsIRequest` from the received `RequestData`, even when the URI
was null.
Additionally `ReconstructWebProgressRequest` has been updated to use the Gecko
style for out parameters (accepting an `nsIFoo**` and passing
`getter_AddRefs(...)` instead of `nsCOMPtr<nsIFoo>&`).
Differential Revision: https://phabricator.services.mozilla.com/D34445
--HG--
extra : moz-landing-system : lando
This fixes Bug 1558506 by making it so that the parent process ignores the context menu event
when right-clicking on the remote <browser> hosting the Add-on Options page. Before, we were
handling the event, stopping it from propagating and preventDefault'ing it, and then sending
a message to the parent that ultimately did nothing (since we knew that we didn't want to
display the context menu). Stopping propagation and preventDefault'ing meant that the event
was never fired in the Extension process for the options page.
With the parent process now returning early in the event that it knows that it doesn't want
to be the one to open the context menu, the underlying ContextMenuSpecialProcessChild can
handle the contextmenu event in the extension process, and do the right thing.
Differential Revision: https://phabricator.services.mozilla.com/D34901
--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
Waiting for docshells and frameloaders to destroy will leave attached
browsing contexts attached too long. In case the children of a
browsing contexts cannot be cached we want to detach all of them as
soon as possible.
Also normalizes the use of BrowsingContext::mGroup.
Differential Revision: https://phabricator.services.mozilla.com/D33602
--HG--
extra : moz-landing-system : lando
For `track-webvtt-two-cue-layout-after-first-end.html`
(1) modify cue1's start time
According to the text track cue order [1], "cues must be sorted by their start time, earliest first; then, any cues with the same start time must be sorted by their end time, latest first".
This order also decides which cue we would display first. As this test would like show `cue1` at top and show another cue at bottom, we should modify cue1's `startTime` in order to put it before cue [0:3] in the cue list.
[1] https://html.spec.whatwg.org/multipage/media.html#text-track-cue-order
(2) listen for cue1's `exit`
As this cue would like to stop when the first cue ends, it should listen `exit` event.
---
For `track-webvtt-two-cue-layout-after-first-end-ref.html`, we should call `video.play()` in order to clear `show-poster` flag [2] and run `TimeMarchesOn` to show the cue.
If we didn't call it to reset the flag, we won't display any cue.
[2] https://html.spec.whatwg.org/multipage/media.html#playing-the-media-resource:show-poster-flag
Differential Revision: https://phabricator.services.mozilla.com/D32937
--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
Temporary workaround to use the document element as the root content node
in XHTML pages that have a XUL root element.
Differential Revision: https://phabricator.services.mozilla.com/D34657
--HG--
extra : moz-landing-system : lando
