There are not enough tests comparing delete operation result and result of
`getTargetRanges()` when selection is in/around/across list item elements.
This patch creates a utility method to make the test body not need to use
Selection API for making simpler tests.
The expected behavior is based on Blink and WebKit unless their behavior is
buggy because their behavior is more reasonable than Gecko's in most cases.
Note that the removing tests are covered by the new tests.
Differential Revision: https://phabricator.services.mozilla.com/D96800
This will report when a telemetry even whenever we load an empty file via a
JAR channel. It will not catch situations where onStopRequest is called with
an error code, or when the listener of the channel does not consume the stream.
Differential Revision: https://phabricator.services.mozilla.com/D96412
AWSY has been using Marionette's "legacy" actions implementation
because spec-compliant actions didn't work yet in chrome scope.
With Marionette's new JSWindowActor-based architecture, which
is now enabled on all builds, chrome scope is now supported by
spec-compliant actions, so AWSY can now use them.
Differential Revision: https://phabricator.services.mozilla.com/D97019
Extension ports should be eligible for garbage collection when
disconnected. This did not happen because there was a strong reference
from the context to the conduit, whose subject was the Port. As a
result, the Port instances were not GCd until the context was unloaded.
This results in significant memory leaks over time, because it is not
uncommon for extensions to have a long-lived background page that
receives messages via Ports. The issue is made even worse by the fact
that ports contain metadata that can potentially be very large.
There are other callers of openConduit, but these are not affected
because their lifetimes are similar to the BaseContext.
Differential Revision: https://phabricator.services.mozilla.com/D96952
The MOZ_MUST_USE macro is defined as clang's and gcc's nonstandard __attribute((warn_unused_result))__. Now that we compile as C++17 by default (bug 1560664), we can replace MOZ_MUST_USE with C++17's standard [[nodiscard]] attribute.
Differential Revision: https://phabricator.services.mozilla.com/D96802
This is a somewhat speculative fix, as I haven't been able to reproduce the issue locally,
but it seems like the right thing to do given that (AFAIK) the DirectWrite APIs don't
make any promises about consistent ordering of faces within the list.
Differential Revision: https://phabricator.services.mozilla.com/D97043
Instead of the scrollframe manually calling ScrollGeneration::New this has the
ScrollPositionUpdate do it automatically. Just makes things a little more
encapsulated.
Note that this patch does contain a small functional change, which is that if
ScrollFrameHelper::ScrollToImpl is called with ScrollOrigin::apz, it will not
increment mScrollGeneration whereas it used to before. As far as I can tell
this should be a harmless change.
Depends on D97036
Differential Revision: https://phabricator.services.mozilla.com/D97037
Note in particular the struct keeps its own static (per-process) counter value,
and uses a uint64_t.
Depends on D97034
Differential Revision: https://phabricator.services.mozilla.com/D97035
This caused some local breakage when using `mach run` due to the privileged
content process being disabled, but the startup cache being enabled (I think?) -
removing it allowed `mach run` to use the privilegedremote process again.
I think the issue which caused this pref to be added here has been fixed now, so
it shouldn't be necessary anymore.
Differential Revision: https://phabricator.services.mozilla.com/D94643
Most of the helper functions in BrowserTestUtils have been updated to deal with
process switches happening during navigations now, so most of these places which
previously tried to wait for a process switch before setting up listeners etc.
are no longer necessary.
This patch removes all of the process switch prediction logic from
BrowserTestUtils.jsm as it's no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D94642
This method only is async in order to allow callers to wait for a process switch
triggered by the call to `loadURI` to be finished before resolving. With
DocumentChannel, we should never trigger a process switch eagerly like this
again, so we don't need any of the async behaviour here anymore.
This part is largely mechanical changes to tests, removing the `await` calls on
`loadURI`, and a follow-up part will remove the actual async logic from
`BrowserTestUtils.loadURI`.
Differential Revision: https://phabricator.services.mozilla.com/D94641
Previously this component was loaded in content due to shouldLoadURI requiring
it, but it is no longer required for that, so can be removed from content
processes.
Differential Revision: https://phabricator.services.mozilla.com/D94640
This formed the backbone of the previous process switching codepath, and
shouldn't be necessary anymore thanks to DocumentChannel's new codepath.
This also removes the eager process switching logic from frontend's _loadURI, as
it would rarely be taken, unless an invalid URI was entered, already.
Differential Revision: https://phabricator.services.mozilla.com/D94639
These methods are no longer necessary, as all loads which can trigger process
switches now go through DocumentChannel.
The shouldLoadURI methods on nsIWebBrowserChrome3 are unfortunately still
necessary as they're used by the disabled-by-default "Single-Site Browser"
feature. In the future this may be possible to clean-up.
Differential Revision: https://phabricator.services.mozilla.com/D94638
WebGPU itself doesn't care about WebRender or even the GPU process.
However, the presentation to canvas as written today only works with WebRender, so
it seems fine to have it as a dependency in general.
An alternative could be to just fail getContext() call if webrender is disabled.
Differential Revision: https://phabricator.services.mozilla.com/D70888
This also fixes an issue where MockFilePicker wouldn't set the mode correctly,
which caused it to always use "modeOpen". For this test we need to pass
"modeGetFolder" in order for the prompt to show.
Differential Revision: https://phabricator.services.mozilla.com/D96526
In https://hg.mozilla.org/integration/autoland/rev/471ad96ddc3e we changed this from calling |Surface().IsFullyDecoded()| to calling Seek because IsFullyDecoded always returns false for large enough animations because we don't keep around all of their frames.
In the old model, where mIsCurrentlyDecoded tracks if the image is fully decoded, we don't want to set mCompositedFrameInvalid to true if simply if the image isn't fully decoded because the current frame could be available.
In the new model, where mIsCurrentlyDecoded tracks if the current frame is available, we definitely do want to mark mCompositedFrameInvalid if the current frame is not available.
Depends on D96944
Differential Revision: https://phabricator.services.mozilla.com/D96945
I'm hoping that the comments in the code are sufficient documentation of this,
but here is a quick overview. The mockup we got from design has rounded rects
in it, and bordered rounded rects in it, so we need to support drawing those.
Initially we tried using the RoundRect function in GDI. However, 1) GDI doesn't
support anti-aliasing, which is unfortunately noticeable, 2) we were
observing strange issues with only some of the corners being rounded with
RoundRect at higher radii / stroke widths. 3) drawing on top of things drawn
with RoundRect would be complicated and inefficient unless we switched
everything over to GDI calls.
As it stands this drawing code is platform agnostic, assuming we have a way of
blitting a raw bitmap to the screen on a given platform, which is a nice trait
to have and makes me think twice about switching all of the drawing over to
direct GDI calls.
Differential Revision: https://phabricator.services.mozilla.com/D95317