In the regressing bug 1849793 I removed a hunk like this because we
don't use any of the parent state on the parent properly:
```
if (aAppearance == StyleAppearance::MozMenulistArrowButton) {
// HTML select and XUL menulist dropdown buttons get state from the
// parent.
nsIFrame* parentFrame = aFrame->GetParent();
aFrame = parentFrame;
elementState = GetContentState(parentFrame, aAppearance);
}
```
However that aFrame = parentFrame also changed the frame we read the
color for the fill. This is not an issue for menus because those don't
override the colors, but for the select menulist button we need to
explicitly inherit.
Differential Revision: https://phabricator.services.mozilla.com/D192002
We were catching Proxy object in the ObjectActor before
we're calling the custom formatter machinery, so we weren't
calling the custom formatter hooks with Proxy objects.
A test is added to ensure these are handled now.
I had to switch the test to use findMessageVirtualizedByType
as the new logged message might be outside of the viewport.
Differential Revision: https://phabricator.services.mozilla.com/D191936
There are a number of occasions where changes to rust code doesn't
trigger cargo to run on an incremental build. In most cases, these
changes are accompanied with a change in Cargo.lock, so let's make cargo
run every time Cargo.lock changes.
Differential Revision: https://phabricator.services.mozilla.com/D192018
$? will only pass the dependencies that have triggered the command to be
called, which will save some work in rebuild_check. However, since
rebuild_check does the difference between removed and modified files,
it still needs to keep checking files.
But, the real reason we need this check is that gkrust.d can have
dependencies with spaces in them, and Make special variables like $^ or
$? don't handle those nicely, and while those files with spaces in
them are most likely unchanged (in most cases, they are going to be
files from the Windows SDK), they end up always reported as the cause
for rebuilds when setting REBUILD_CHECK. $? is more likely not to
contain files with spaces.
Differential Revision: https://phabricator.services.mozilla.com/D191381
Because the force-cargo-* rules don't have actual dependencies, the
REPORT_BUILD call can't usefully report why cargo is invoked when
setting REBUILD_CHECK.
This also has the side effect of making the non-verbose output nicer
(containing the actual built file rather than force-cargo-*)
Differential Revision: https://phabricator.services.mozilla.com/D191380
There are subtle differences in the two implementations that actually
make the variant for RUST_PROGRAMS not work currently:
- there is a %.h leftover from bug 1855623
- there is a missing $(basename) when trying to find the .d file,
preventing it from being found.
With a common rule, we avoid such subtle differences, and that also
allows to further implement fixes without missing one of the cases.
This will also allow to add the same trick to other rules, which should
already have it.
Differential Revision: https://phabricator.services.mozilla.com/D191378
Back when this was added, there was an incentive to try to build
gkrust-gtest before gkrust so that libxul-gtest could have a chance
to link and be dumpsymbol'ed while gkrust compiles.
While we may still want that to happen to some degree, the way it's done
right now, with how things evolved over the years, ends up being
counterproductive and ends up delaying all the rust compiles entirely.
We'll deal with improving the overall ordering of builds in bug 1651293.
(This only affects CI)
Differential Revision: https://phabricator.services.mozilla.com/D192015
This change introduces the possibility for more interdependencies being
recorded automatically, but making this work reliably more generally
we'll probably need more work, so at the moment, just make it work for
wasm2c.
Differential Revision: https://phabricator.services.mozilla.com/D191925
There are unfortunate cases where all the rust targets don't end up on
the same line, and that's kind of confusing.
This keeps the rust targets using "Rust" (in config/makefiles/rust.mk)
and switching individual crates to "RustCrate". They will still appear
close to each other in the profiles, but targets will now have their
dedicated line.
Differential Revision: https://phabricator.services.mozilla.com/D192013
At the top-level, what we currently have is something akin to:
export: some deps
echo BUILDSTATUS TIER_START export
make recurse_export
...
In practice, what this means is that `some` and `deps` are built outside
the export tier/phase.
Since recurse_export is itself a recipe with dependencies, we can "just"
move `some` and `deps` to become dependencies of recurse_export instead.
But since in non top-level directories, recurse_export is not a thing,
we still need to keep the dependencies on export there.
Unfortunately, we have one instance of something built during
recurse_export that relied on its undeclared/undeclarable dependencies
being built before recurse_export, so we need to accomodate for that.
Also, for some reason, recurse_pre-export was a two-colons recipe, while
the other recurse_* recipes were single-colon, so fix that.
Come to think of it, the same probably applies to misc and libs, which
this would mechanically fix alongside.
Incidentally, this also makes those things that ran before recurse_* run
in parallel of the other things that run during recurse_*.
Differential Revision: https://phabricator.services.mozilla.com/D191913
$? will only pass the dependencies that have triggered the command to be
called, which will save some work in rebuild_check. However, since
rebuild_check does the difference between removed and modified files,
it still needs to keep checking files.
But, the real reason we need this check is that gkrust.d can have
dependencies with spaces in them, and Make special variables like $^ or
$? don't handle those nicely, and while those files with spaces in
them are most likely unchanged (in most cases, they are going to be
files from the Windows SDK), they end up always reported as the cause
for rebuilds when setting REBUILD_CHECK. $? is more likely not to
contain files with spaces.
Differential Revision: https://phabricator.services.mozilla.com/D191381
Because the force-cargo-* rules don't have actual dependencies, the
REPORT_BUILD call can't usefully report why cargo is invoked when
setting REBUILD_CHECK.
This also has the side effect of making the non-verbose output nicer
(containing the actual built file rather than force-cargo-*)
Differential Revision: https://phabricator.services.mozilla.com/D191380
There are subtle differences in the two implementations that actually
make the variant for RUST_PROGRAMS not work currently:
- there is a %.h leftover from bug 1855623
- there is a missing $(basename) when trying to find the .d file,
preventing it from being found.
With a common rule, we avoid such subtle differences, and that also
allows to further implement fixes without missing one of the cases.
This will also allow to add the same trick to other rules, which should
already have it.
Differential Revision: https://phabricator.services.mozilla.com/D191378
