From what I can see in source history, pal8v4.bmp started out with a fuzzy of (3, 6376) on all platforms. Then one day aarch64-windows started producing a result of (1, 899) and so that platform's expectations were adjusted.
In the upcoming clang 12, the behavior of this test gets "fixed" in that we go back to those 6376 differing pixels like on other platforms. The max difference rises to 4 though. In light of the fact that aarch64-windows is seeing less priority these days, I can't justify digging into the exact code reason for the change, so this patch just updates the fuzzy setting to allow these values.
Differential Revision: https://phabricator.services.mozilla.com/D100823
Windows start blocking media by default (see the
media.block-autoplay-until-in-foreground pref).
If the document becomes visible from GetScriptHandlingObject(), we
hand-rolled our own UpdateVisibilityState and didn't call
MaybeActiveMediaComponents (which unblocks media playback).
It couldn't call it there before since given content docshells used
start as active, but now that they don't we can do that and fix the bug.
Differential Revision: https://phabricator.services.mozilla.com/D41438
I removed this assertion temporarily to unblock fuzzing over the holidays. Now that we've fixed the bugs, we can put it back.
Depends on D100751
Differential Revision: https://phabricator.services.mozilla.com/D100752
There were two bugs here:
1. We weren't checking hadEagerTruncationBailout before eagerly truncating phis.
2. MDiv::operandTruncateKind and MMod::operandTruncateKind can return TruncateAfterBailouts even if ComputeTruncateKind returns a less restrictive kind. We therefore have to check the operands too.
Depends on D100750
Differential Revision: https://phabricator.services.mozilla.com/D100751
The next patch will add a method to `RangeAnalysis` with a TruncateKind argument. Nested enums can't be forward-declared, so instead of undoing anba's work in bug 1669181 (part 35), I'm un-nesting the enum.
Differential Revision: https://phabricator.services.mozilla.com/D100750
There is no autorelease pool in place at the time that C++ globals are initialized, so this array
causes warnings when running with `OBJC_DEBUG_MISSING_POOLS=YES LIBDISPATCH_DEBUG_MISSING_POOLS=NO`.
And avoiding static initializers is a good practice anyway.
Differential Revision: https://phabricator.services.mozilla.com/D100736
There is no autorelease pool in place at the time that C++ globals are initialized, so this array
causes warnings when running with `OBJC_DEBUG_MISSING_POOLS=YES LIBDISPATCH_DEBUG_MISSING_POOLS=NO`.
And avoiding static initializers is a good practice anyway.
Differential Revision: https://phabricator.services.mozilla.com/D100734
The only remaining issues we've been able to find with the skeleton UI are that it's missing RTL support (which is coming - bug 1671603), there's a flash of the skeleton UI when maximizing the window (bug 1665451), and that we don't yet clean up the registry values from the uninstaller (bug 1675081). These do need to be addressed, but I don't think they're severe enough to block landing this to start getting feedback from our Nightly audience.
Again, I'm flagging all of you for review per Jim Mathies's request. There's not really one reviewer most familiar with this and the condition it's in, unfortunately.
Differential Revision: https://phabricator.services.mozilla.com/D98480
This scope will support later functional changes that are conditionally
compiled. This part is standalone to help with blame-tracking.
Differential Revision: https://phabricator.services.mozilla.com/D100805
Add ACCESS_WIFI_STATE to the gve manifest, same as androidTest.
Remove ACCESS_WIFI_STATE from the list of pm grants, since it is not of
type dangerous.
Differential Revision: https://phabricator.services.mozilla.com/D100727
Otherwise the adjustments that the media controls do in response to size
changes affect the size itself, which can cause cyclic layout.
Differential Revision: https://phabricator.services.mozilla.com/D100722
Introducing this as a separate patch to simplify this changeset and first introduce a straightforward-ish implementation.
Differential Revision: https://phabricator.services.mozilla.com/D100731
Applying a bulk filter on accessibles in content process allows us to avoid a potentially large (and variable) number of IPC sync calls to retrieve the accessible names. I chose to implement this as a "post filter" and not to actually do the entire search in content because it would cause a lot of duplication of code for non-IPC searching, and we wouldn't have the flexibility to combine a text search with any arbitrary search key as the API requires.
I also generalized the RangeTypes.h header to PlatformExtTypes so it can be used to define filter types as well.
Differential Revision: https://phabricator.services.mozilla.com/D100730
`rust` and `rust-analyzer` are incompatible together so we should remove the first
one since `rust-analyzer` is the better choice.
Differential Revision: https://phabricator.services.mozilla.com/D100759
When mach errors out, an error report is sent to Sentry. This error
report contains information about the state of the interpreter during
the failure, details about the environment, installed packages and more.
Having this information available immediately when attempting to resolve
a bug report is generally desirable, instead of going through a back-and-forth
needinfo tag on Bugzilla or spending time asking the reporter questions on
Matrix.
This commit captures the Sentry ID returned from `sentry_sdk.capture_exception`
and prints it to the screen. If a user adds this line to their bug report (as
the error messages suggest) a build team member can enter this number into
Sentry to identify the exact report and debug the error. At minimum this will
reduce the amount of back-and-forth between the reporter and the assignee
required to resolve a bug. Optimally it should make bugs easier to spot and
reduce the time spent on end user support requests.
To use the Sentry ID to identify information about a specific bug report, the
bug assignee should open the Mozilla Sentry page for the `mach` project and
paste the ID into the search box, which will produce the full stack trace with
all submitted information.
Differential Revision: https://phabricator.services.mozilla.com/D100247
