When Mach captures an exception, it checks if any Python files were
modified, then sends the error to Sentry if not. This filters out local
development errors from our Sentry dashboard.
However, asking VCS if "any Python files are changed" can be a long
operation (in the magnitude of ~1s-10s).
This patch moves that processing to a separate thread that starts during
Mach initialization, so that the answer will be ready by the time an
exception is raised.
I would've preferred if there was a better abstraction for handling this,
but:
* A ThreadExecutor seemed like overkill (until it becomes Mach-wide)
* I don't know of any standard library tools that provide a
"single-thread-future-with-result" sort of mechanism.
Differential Revision: https://phabricator.services.mozilla.com/D127157
This exposes the system colors that were unexposed in bug 1733354, but
builds up on top of bug 1733569 to get buttons and richlistboxes working
properly.
This causes windows dialogs to be dark in dark mode, etc.
To be landed after the freeze, since it likely has some UI fallout that
I missed.
Differential Revision: https://phabricator.services.mozilla.com/D127260
Introduce ToRefType which takes a string value and returns a reference type
or throws an error. Make ToRefType recognize both anyfunc and funcref as
names for the general function, since we've already shipped code that
recognizes funcref.
Make ToValType use ToRefType instead of doing its own parsing.
Make WasmTableObject::construct use ToRefType instead of doing its
own parsing. This is an attempt to have the system do the same
thing everywhere instead of having ad-hoc solutions.
Introduce a ToJSAPIString that will produce "anyfunc" for funcref,
and use that where it's appropriate.
Make the test case converter generate anyfunc instead of funcref.
Change all test cases that use funcref to use anyfunc, in the JS API.
Differential Revision: https://phabricator.services.mozilla.com/D127248
In the future we need to remove this patch, implement dark form
controls, and probably make those tests pass some other way (like
forcing the chrome color-scheme to match content for those tests or
something). Otherwise they are really expected to fail on a Firefox dark
theme.
But this is a somewhat-easy fix for now.
Differential Revision: https://phabricator.services.mozilla.com/D127473
"This is nightly so we don't know what partials we need" is not the same
as "we're making a release and we know we don't want partials". In one
case (when called from get_decision_parameters) partial_updates is None,
in the other (called from release_promotion_action) it's an empty dict.
The latter case still enforces non-empty partial_updates for production,
but for staging it's not really necessary and falling back to nightly
behaviour in populate_release_history is just wrong.
Differential Revision: https://phabricator.services.mozilla.com/D127228
This patch will also resolve bug 1732291, since we will use the correct light or dark value of -moz-mac-source-list-selection.
Depends on D127300
Differential Revision: https://phabricator.services.mozilla.com/D127301
When we navigate in history to the same entry that we're current at then we
actually do a reload. The problem is in the way we detect whether to do a reload
in the parent process.
If a page does a back and a forward one after the other in a script, then the
parent will calculate the index for the back and tell the child to load the
entry at that index. While the child is processing the load of that entry, the
BC in the parent process still has the same entry as its active entry (until the
child commits the load of the entry over IPC). The parent then processes the
forward, calculates the index for the forward and finds the entry at that index.
This is the same entry that we were at before doing anything, and so the same
entry as the active entry in the BC in the parent process. We used to compare
the entry that we're going to load with the active entry in the BC to determine
whether we're doing a reload, and so in this situation we would assume the
forward navigation was actually doing a reload. The child would reload the page,
and we'd run the script again and we'd end up in a reload loop.
Comparing the offset with 0 to determine whether we're doing a reload fixes this
issue.
Differential Revision: https://phabricator.services.mozilla.com/D126585
Webrender encounters a shader compilation error when rendering video
in firefox for android on intel based chromebooks. The error is due to
a missing definition of textureSize(samplerExternalOES), which should
be defined when using the OES_EGL_image_external_essl3
extension. However, these devices are running Mesa drivers, and due to
a Mesa bug affecting versions 19 and earlier this was not defined.
We already have a fallback path for devices which do not support
OES_EGL_image_external_essl3: we use the ESSL 1.0
OES_EGL_image_external extension instead. This patch detects when we
are running on Mesa 19 or earlier, and forces us to use the fallback
path.
Differential Revision: https://phabricator.services.mozilla.com/D127418
This patch adds a crash annotation named *LastInteractionDuration*, that indicates
the length of the user interaction duration if the crash happen when the user is
inactive.
Differential Revision: https://phabricator.services.mozilla.com/D125718
I wrote a tool to simplify reftest annotations, and it tripped over this
because I didn't teach it operator precedence. However I think it's
better to be explicit, so just fix the two instances of it.
Differential Revision: https://phabricator.services.mozilla.com/D127415
- Use gdk_screen_get_monitor_workarea() on KDE/Sway to get screen sizes as it's reported correctly there.
- Remove unused code.
Differential Revision: https://phabricator.services.mozilla.com/D127261
We take this opportunity to refactor the `_authenticate` method.
Since it's already an async function, we don't have to explicitely return
Promise objects.
Differential Revision: https://phabricator.services.mozilla.com/D127283
