Since we no longer are using the PaperList or CreateDefaultSettings methods on
nsPrinterBase, and we can remove them from nsPrinterBase.
This should dramatically improve latency when the remote printer is not
available, or when the print server is slower. In the best-case scenario it may
increase the latency to displaying the print preview somewhat.
Differential Revision: https://phabricator.services.mozilla.com/D94482
This also changes the frontend to use this interface.
This will be a bit less efficient in the general case, as it will serialize the
PaperList and DefaultSettings fetches. But most of the large delays seem to
occur when the print server is slow to respond, and ultimately using a single
live connection for both these requests when possible (particularly with CUPS)
should improve the total latency when the printer or print server is not
available, or is very slow.
Differential Revision: https://phabricator.services.mozilla.com/D93688
- Updated layout/svg/tests/test_disabled.html to ensure that this doesn't allow
rendering SVGs on about:blank and about:srcdoc.
Differential Revision: https://phabricator.services.mozilla.com/D95139
We scan for addon changes twice, once early in startup (usually with no scanning) and once after ui startup. We hold on to the startup data, and during both scans we restore that data into the addon location instances. The problem here is if we install a builtin in-between these scans. The new data from the install would get overwitten by the old data. In some cases this caused addons to disappear (e.g. old data has incorrect path). Other issues covered here is that we would never remove addon data for builtins removed from the system, and we would additionally mark builtins as sideloads, which caused other side effects (particularly with search addons) where we would not load the addon, but fortunately the search service later re-installes them.
Differential Revision: https://phabricator.services.mozilla.com/D95422
This also adds a test. The velocities computed in the test are the following:
SimpleVelocityTracker: 0.65 with full data, 0.467 with partial data
AndroidVelocityTracker: 1.225 with full data, 0.833 with partial data
Differential Revision: https://phabricator.services.mozilla.com/D95651
If there is a scrollframe that is inactive but also visibility:hidden, then
we shouldn't create a hit test info for it, because APZ will consider it as
being visible. In the non-fission case this doesn't matter much but in the
fission case the input event could end up getting sent to the wrong process if
the hidden inactive scrollframe is sitting on top of an OOP iframe.
Differential Revision: https://phabricator.services.mozilla.com/D95767
Here, "errors caused by local changes" means "errors whose stack traces contain a reference to a file that is in the set of files changed locally". This implementation is a trade-off:
1. This check will not catch issues caused transitively by changes to local files. For example, consider a function that has been updated and its return type changed in a backwards-incompatible way, whereas callers were not updated appropriately. This would likely manifest as a type error in the calling function after the callee has returned.
2. This check WILL catch issues that come from locally changed files where the cause of the error doesn't originate from those local changes. For example, consider a function that's been locally updated but is never called in the failing codepath; if an exception is thrown, it's not due to this local change, and we shouldn't filter it out.
There are conceivable improvements that we could apply to fix deficiency (1); for example, we could track imports recursively starting from the oldest frame in the stack trace and match on that set of imported files. Note this would not handle dynamic imports properly, and that this could exacerbate issue (2).
Issue (2) could conceivably be addressed by attempting to filter the actual local diffs down to changes that actually may be causing the error. This is difficult to do generally especially in light of Python's dynamism, but there mayb be conservative improvements that we could make in this space.
Overall, neither of the above caveats are deemed to be sufficiently concerning that this patch should be blocked as-is, and the current situation with our Sentry logs is unusable due to all the noise. This patch will probably have a substantial impact on that noise without incidentally filtering out too much signal.
Differential Revision: https://phabricator.services.mozilla.com/D95607
Using the subscript loader is currently our best way of getting the loaded scripts recorded for entry
in the ScriptPreloader which is used to cache startup-related JavaScript within the startup window.
Originally, we were using <script> tags to load those scripts, but unfortunately, that loading mechanism
does not qualify for being noted by the ScriptPreloader.
This is a workaround until the Stencil project by the SpiderMonkey team Phase 2 is complete (see bug 1663956),
which should allow us to more easily note scripts to cache at runtime.
Differential Revision: https://phabricator.services.mozilla.com/D95407
The original change was tested as working on try/try-c-c, but was done during
the window when bug 1673992 had been backed out on mozilla-central. As a result,
the mozharness.zip that was tested had the "mozharness/" top level directory and
everything worked.
Differential Revision: https://phabricator.services.mozilla.com/D95741
- Expose wayland dmabuf related options, which are:
widget.dmabuf-textures.enabled
widget.dmabuf-webgl.enabled
- Expose widget.use-xdg-desktop-portal which enables remote system dialogs like Print/Open/Save.
- Expose general Wayland preferences:
widget.wayland-smooth-rendering - extra buffering of Wayland SW rendering
widget.wayland.use-opaque-region - use transparency hints for Wayland compositor
widget.wayland_vsync.enabled - use independent vsync source
None of them provide sensitive informations.
Differential Revision: https://phabricator.services.mozilla.com/D86939
This introduces a new mangled symbol of the form FILE_<hash>. It's defined
on line 1 of each visited source file, and it's referenced in places that
the preprocessor tells us there was an #include. Both angle-bracket includes
and quote includes are supported here.
Differential Revision: https://phabricator.services.mozilla.com/D95529
In the next patch I'll want to be able to provide the entire source rather than
having visitIdentifier just use the token at `Loc`. The existing call sites
create a SourceRange from the SourceLocation and indicate (by not setting the
LocRangeEndValid flag) that the visitIdentifier function should retain it's
old behaviour of using the token to figure out the range.
Depends on D95527
Differential Revision: https://phabricator.services.mozilla.com/D95528
This extracts a relativizePath function that normalizes a file path to be
relative to the source/objdir, and returns the type of the file.
Differential Revision: https://phabricator.services.mozilla.com/D95527
With this patch, the system font seems to work OK again on 10.15 when building Firefox with SDK10.15,
provided webrender is *disabled*. We no longer trigger the Core Text error messages from InitSystemFontNames(),
and the proper system font is used.
(With webrender, we get garbage because it fails to instantiate the system font and renders "random" Times
glyphs instead.)
Differential Revision: https://phabricator.services.mozilla.com/D95453
Add a telemetry probe tracking the errors in dav1d or aom decoder. We
only care the errors from `aom_codec_decode` and `dav1d_get_picture` so
other error code won't be counted.
Differential Revision: https://phabricator.services.mozilla.com/D94489