To extract Huffman tables (see bug 1552435), we need the ability to walk through the grammar.
This patch starts implementing grammar walking, as macros - at this stage, sufficiently to walk
through interfaces and start dealing with their fields.
Depends on D32291
Differential Revision: https://phabricator.services.mozilla.com/D32295
--HG--
extra : moz-landing-system : lando
- Follow Gtk and get theme button text color directly from "button" CSS node instead of "button label"
- Provide new -moz-gtk-buttonactivetext color for active/pressed button text color
- Replace ButtonText color with -moz-gtk-buttonactivetext when it's appropriate
Differential Revision: https://phabricator.services.mozilla.com/D30566
--HG--
extra : moz-landing-system : lando
This patch adds telemetry instrumentation to count the number of times the RDM viewport properties are changed (dimensions and rotation). This count will be correlated with the panel open count and time spent open to refine the baseline for RDM usage and filter out accidental usage.
A new Redux middleware, `telemetryMiddleware`, is introduced to the RDM Redux store. This observes actions dispatched to the store. For `RESIZE_VIEWPORT` and `ROTATE_VIEWPORT` actions, it increases a numeric value for the new scalar telemetry probe, `"devtools.responsive.viewport_change_count"`.
Other actions may be observed in this middleware for future telemetry instrumentation of RDM.
The `RESIZE_VIEWPORT` action is a dispatched with a high frequency when dragging to resize. Therefore, we debounce logging for this action. To ensure the test can reliably test counting this action without adding needless complexity to account for the asynchronicity, the `debounce()` utility is extended with an `immediate` parameter to cause the very first call to be executed immediately before going into the debounce behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D31645
--HG--
extra : moz-landing-system : lando
test_CF_HTML_clipboard.html does nothing if platform isn't mac. But according
to intermittent failure log, this is often failure on Android.
I guess that this is infra issue, but we should use skip-if to avoid this
failure instead.
Differential Revision: https://phabricator.services.mozilla.com/D32413
--HG--
extra : moz-landing-system : lando
This is to allow us to detect the enabling and disabling of recording so that we can notify the embedding application of the change in status.
Differential Revision: https://phabricator.services.mozilla.com/D31072
--HG--
extra : moz-landing-system : lando
"Discard" instead of "Release" for consistency with ShouldDiscardBaselineCode.
Differential Revision: https://phabricator.services.mozilla.com/D32294
--HG--
extra : moz-landing-system : lando
The destroy() call in JSScript::finalize was moved into DestroyJitScripts for
consistency with BaselineScript and IonScript.
Differential Revision: https://phabricator.services.mozilla.com/D32290
--HG--
extra : moz-landing-system : lando
This replaces the in-tree u2fhid (which has been renamed to
authenticator) by the published crate.
Differential Revision: https://phabricator.services.mozilla.com/D32221
--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
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
