Changes:
- demote all existing `android-em-4.*` tests to tier 2
- ensure the above tests only run on `try` and `mozilla-central` but with exceptions
Differential Revision: https://phabricator.services.mozilla.com/D32086
--HG--
extra : moz-landing-system : lando
Adding tests to ensure that when cues with overlapping times, the one with earlier end timestamp should disappear when the media time reaches its end time. In this test, we have two cues with overlapping time, when the video starts, both cues should be displayed. When the time passes 1 seconds, the first cue should disappear and the second cues should be still displayed.
Differential Revision: https://phabricator.services.mozilla.com/D31172
--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
Changes:
- demote all existing `android-em-4.*` tests to tier 2
- ensure the above tests only run on `try` and `mozilla-central` but with exceptions
Differential Revision: https://phabricator.services.mozilla.com/D32086
--HG--
extra : moz-landing-system : lando
We previously (in bug 1491235) adjusted some utility code to make
layout-contained frames behave as if they have no baseline.
But that's not sufficient. To make frames fully report lack-of-a-baseline,
we now do the following for layout-contained frames, as of this patch:
(a) We now leave the ReflowOutput outparam's BlockStartAscent member at its
default value (which is what we do for frames without a baseline like
e.g. nsCheckboxRadioFrame and nsHTMLCanvasFrame). And if the parent cares
about the baseline, it'll then ask directly, using a baseline getter.
(b) We now return 'false' in more implementations of bool-returning
baseline-getter-methods (where 'false' indicates 'no baseline').
(c) We now return the margin-box-bottom edge, in the nscoord-returning
'GetLogicalBaseline()' getter method. (We typically do this by deferring
to the inherited method, which ultimately comes from nsFrame's
implementation). It's appropriate to use the margin-box-bottom edge when
there's no baseline, per the definition of 'vertical-align: baseline',
here: https://drafts.csswg.org/css2/visudet.html#propdef-vertical-align
Depends on D32182
Differential Revision: https://phabricator.services.mozilla.com/D32183
--HG--
extra : moz-landing-system : lando
In particular:
- In contain-layout-suppress-baseline-002.html, the test currently indirectly
relies on the 50px-tall-canvas being the tallest thing in each flex
container. This isn't robustly true (and in fact on windows, the textarea is
taller at 50.8px tall). So I'm adjusting this test so that it no longer has a
hardcoded flex container size and no longer depends on this.
- In contain-layout-baseline-005.html and its reference case, we need to
explicitly specify 'vertical-align:baseline' to test baseline-alignment,
because some of its tested form controls have other UA-stylesheet-provided
default values of 'vertical-align'.
(e.g. <select multiple> defaults to 'vertical-align:text-bottom")
- Also: in that same test, we need to reduce the width of the an <input>
textfield -- otherwise, it and the other elements on its line may not fit and
may linewrap, which prevents us from effectively testing baseline-alignment
on the linewrapped element.
- In contain-layout-button-001.html, the expectation was not correct. Before
this patch, the test expects that a layout-contained button will have the
same baseline as an empty button, and that's an invalid expectation. An empty
button uses a point inside of its content-box as its baseline, whereas a
layout-contained element *has no baseline*, which means that it does
'vertical-align:baseline' alignment by aligning its own margin-bottom edge
with the parent's baseline, per
https://drafts.csswg.org/css2/visudet.html#propdef-vertical-align
So, I'm amending the test to have this expectation and updating its meta tags
to reference the updated expectation and with a reference to that spec text.
Firefox fails the amended contain-layout-button-001.html test, so this patch
adds a .ini file to reflect that failure. The next patch in this series will
fix our implementation to make us pass the test, and will remove the .ini file.
Chrome also fails the amended contain-layout-button-001.html tests, and I filed
https://bugs.chromium.org/p/chromium/issues/detail?id=965740 on them with an
explanation.
Differential Revision: https://phabricator.services.mozilla.com/D32182
--HG--
extra : moz-landing-system : lando
This includes style system and layout update. I add 3 extra reftests
because the original tests use ray() function as the offset-path, but we
don't support it. It'd be better to add tests using a different type of
offset-path.
The spec issue about the serialization:
https://github.com/w3c/fxtf-drafts/issues/340
Differential Revision: https://phabricator.services.mozilla.com/D32212
--HG--
extra : moz-landing-system : lando
Actually, all JNI Exceptions with `java.lang.OutOfMemoryError` call
`NS_ABORT_OOM(0)`. But `JNIEnv::NewString` in `StringParam::GetString` can know
OOM size when returning `nullptr`. So call `NS_ABORT_OOM` directly when
`NewString` is failure.
Differential Revision: https://phabricator.services.mozilla.com/D31026
--HG--
extra : moz-landing-system : lando
During the visibility pass, the main clip chain instance for each
primitive is created. In the prim prepare pass, a clip chain instance
is generated for each segment (of primitives that are segmented).
This previously required maintaining the active clip chain stack
during both passes. However, this is not ideal for a number of
reasons: the code is somewhat complicated / error prone and the
segment clip chain building step does more work than required.
This patch changes the segment clip chain building code to set up
the active clip nodes based on the result of the initial clip
chain built for the overall primitive during the visibility pass.
This means that it's no longer necessary to maintain the active
clip chain stack during the prepare pass. This simplifies some
upcoming picture caching changes related to avoiding redundant
cache invalidations, which is the main motivation for the change.
Differential Revision: https://phabricator.services.mozilla.com/D32250
--HG--
extra : moz-landing-system : lando
This is a follow-up to https://phabricator.services.mozilla.com/D30600
Previously, I changed changed the space mapper logic to use the world transformations.
This was seemingly needed because we requrested the relation between primitives and
their clip nodes, which could be in unrelated spatial sub-trees.
However, I believe the change was a mistake, since for clips we should not even try
to get the relative mapping, and clipping is done in world space for these cases.
This change reverts that logic back. ~~Fingers crossed for the try to not show any
asserts firing up inside get_relative_transform.~~ Try is green 🎉
Differential Revision: https://phabricator.services.mozilla.com/D32382
--HG--
extra : moz-landing-system : lando
This makes our video controls bindings check on loadedmetadata events whether or not to display
the toggle.
Differential Revision: https://phabricator.services.mozilla.com/D32365
--HG--
extra : moz-landing-system : lando
e10s profiling or IR-based PGO instrumentation will both produce
multiple `.profraw` files that need to be handled in some way. Since
clang's `-fprofile-generate` option takes a directory, it seems fitting
to make `--with-pgo-profile-path` mirror that by taking a directory, and
letting `merge_profdata.py` deal with whatever files it might find in
said directory.
Differential Revision: https://phabricator.services.mozilla.com/D32389
--HG--
extra : moz-landing-system : lando
This change is necessary to make either e10s profiling or LLVM IR-based
PGO instrumentation work properly, as both will generate multiple
`.profraw` files.
Differential Revision: https://phabricator.services.mozilla.com/D32390
--HG--
extra : moz-landing-system : lando
Always generating the slot assignment combinator means that we check the current
host correctly.
Differential Revision: https://phabricator.services.mozilla.com/D32405
--HG--
extra : moz-landing-system : lando
This format includes an "actionName" for each experiment which
identifies the source of the experiment. This makes it possible for
each experiment type to identify which experiments it should clean up
vs. which it should leave alone because they don't belong to it.
Differential Revision: https://phabricator.services.mozilla.com/D32338
--HG--
extra : moz-landing-system : lando
D29542 fixed the bogus checks that was making nested pseudo-elements match
author rules. This adds tests and ends up being just a cleanup, though as it
turns out we it also fixes an issue with ::slotted() matched from
Element.matches.
Differential Revision: https://phabricator.services.mozilla.com/D27529
--HG--
extra : moz-landing-system : lando
when update-verify migrated from using build-tools to in-tree, the path
to `diff-summary.log` was not updated.
Differential Revision: https://phabricator.services.mozilla.com/D32403
--HG--
extra : moz-landing-system : lando
The initial implementation made some incorrect assumptions about the data that
was in our data set and used the wrong field to identify the certificates to
delete when they are removed from our preload list. Now that the data set has
the expected field (the hash of the whole certificate), we can use it instead.
Differential Revision: https://phabricator.services.mozilla.com/D32380
--HG--
extra : moz-landing-system : lando
As a side effect of this patch, the format of the "state" value of
"async shutdown timeout" crash reports will change, as follows:
"Run manifest: " has been replaced with "Run manifest, ":
```
- Startup: Run manifest: asyncEmitManifestEntry("background")
+ Startup: Run manifest, asyncEmitManifestEntry("background")
```
Multiple states are now separated by ", " instead of ",":
```
- Startup: Run manifest: manifest_name,manifest_version
+ Startup: Run manifest, manifest_name, manifest_version
```
"Run manifest" will always have a "Startup: " in front of it:
```
- Startup: Emit Startup,Run manifest
+ Startup: Emit Startup, Startup: Run manifest
```
And removed the `manifest_*` event dispatch since it has no listeners.
Differential Revision: https://phabricator.services.mozilla.com/D26986
--HG--
extra : moz-landing-system : lando
We previously (in bug 1491235) adjusted some utility code to make
layout-contained frames behave as if they have no baseline.
But that's not sufficient. To make frames fully report lack-of-a-baseline,
we now do the following for layout-contained frames, as of this patch:
(a) We now leave the ReflowOutput outparam's BlockStartAscent member at its
default value (which is what we do for frames without a baseline like
e.g. nsCheckboxRadioFrame and nsHTMLCanvasFrame). And if the parent cares
about the baseline, it'll then ask directly, using a baseline getter.
(b) We now return 'false' in more implementations of bool-returning
baseline-getter-methods (where 'false' indicates 'no baseline').
(c) We now return the margin-box-bottom edge, in the nscoord-returning
'GetLogicalBaseline()' getter method. (We typically do this by deferring
to the inherited method, which ultimately comes from nsFrame's
implementation). It's appropriate to use the margin-box-bottom edge when
there's no baseline, per the definition of 'vertical-align: baseline',
here: https://drafts.csswg.org/css2/visudet.html#propdef-vertical-align
Depends on D32182
Differential Revision: https://phabricator.services.mozilla.com/D32183
--HG--
extra : moz-landing-system : lando
In particular:
- In contain-layout-baseline-005.html and its reference case, we need to
explicitly specify 'vertical-align:baseline' to test baseline-alignment,
because some of its tested form controls have other UA-stylesheet-provided
default values of 'vertical-align'.
(e.g. <select multiple> defaults to 'vertical-align:text-bottom")
- Also: in that same test, we need to reduce the width of the an <input>
textfield -- otherwise, it and the other elements on its line may not fit and
may linewrap, which prevents us from effectively testing baseline-alignment
on the linewrapped element.
- In contain-layout-button-001.html, the expectation was not correct. Before
this patch, the test expects that a layout-contained button will have the
same baseline as an empty button, and that's an invalid expectation. An empty
button uses a point inside of its content-box as its baseline, whereas a
layout-contained element *has no baseline*, which means that it does
'vertical-align:baseline' alignment by aligning its own margin-bottom edge
with the parent's baseline, per
https://drafts.csswg.org/css2/visudet.html#propdef-vertical-align
So, I'm amending the test to have this expectation and updating its meta tags
to reference the updated expectation and with a reference to that spec text.
Firefox fails the amended contain-layout-button-001.html test, so this patch
adds a .ini file to reflect that failure. The next patch in this series will
fix our implementation to make us pass the test, and will remove the .ini file.
Chrome also fails the amended contain-layout-button-001.html tests, and I filed
https://bugs.chromium.org/p/chromium/issues/detail?id=965740 on them with an
explanation.
Differential Revision: https://phabricator.services.mozilla.com/D32182
--HG--
extra : moz-landing-system : lando
