Its default value is `true`. `dom.window.event.enabled` will never be reverted
by default in release builds. So, we can drop it from our tests.
Differential Revision: https://phabricator.services.mozilla.com/D119852
It's default value is `true`.
`dom.keyboardevent.keypress.set_keycode_and_charcode_to_same_value` will neve
be reverted in release builds by default. Therefore, we can get rid of it
from the tests unless testing non-default behavior.
Differential Revision: https://phabricator.services.mozilla.com/D119851
It's default value is `true`. `dom.keyboardevent.dispatch_during_composition`
will never be reverted by default in release builds. So, we can drop it from
the tests unless testing the non-default behavior.
Differential Revision: https://phabricator.services.mozilla.com/D119850
Its default value is `true` and it will never be reverted in release builds
by default. Therefore, we can get rid of it from the tests unless testing
non-default behavior.
Differential Revision: https://phabricator.services.mozilla.com/D119849
`MightBeForwarded` accidentally always used to return `true`, regardless
of the checked `Type`. It didn't cause any bug because the GC still
checks if `t->isForwarded()` returns `true`, but a working
`MightBeForwarded` allows skipping an unnecessary check.
Differential Revision: https://phabricator.services.mozilla.com/D119176
This becomes possible as a side effect of making sure that the current
buffer content is always completely valid, by blitting from the
previous buffer, analogous to
`NativeLayerCA::HandlePartialUpdate` and
`WindowSurfaceWaylandMB::HandlePartialUpdate`.
Apart from reducing overpaint, this improves correctness is many
situations, avoiding glitches.
Note: the approach here may not be optimal concerning efficiency yet
and improvements are planed after further refactoring.
Depends on D118925
Differential Revision: https://phabricator.services.mozilla.com/D119015
In cross-compilation setups (x86_64 host, i686 or aarch64 target), we're
going to need two sysroots. Obviously, we need the sysroot paths to be
different in that case, so the sysroot path themselves need to contain
some distinctive name, and we'll use the `target.toolchain` name for
that (the target triplet with the vendor/machine stripped out).
Because the path name needs to be reflected in the artifact name as well
as the toolchain name, we also change them.
And because the current prefix in the toolchain name is now redundant
with the suffix, we remove the prefix, and allow the bootstrapping
mechanism to try toolchains without the prefix.
Differential Revision: https://phabricator.services.mozilla.com/D119846
`EventStateManager` gives up to track gesture to start a drag if mouse down
content which is stored in `mGestureDownFrameOwner` gets lost its primary frame.
When user tries to start to drag selected text in `<input>` or `<textarea>`
element, mouse down content is an anonymous node in `TextControlElement`. So,
if a reflow occurs after `mousedown` event, the anonymous `<div>` element
is replaced with new one and `EventStateManager` gives up to track it.
Therefore, this patch makes `EventStateManager` do similar things as
`nsBaseDragService`. When `nsTextControlFrame` notifies of remove/add
the anonymous nodes, `EventStateManager` tries to keep tracking gesture with
a new anonymous node.
Differential Revision: https://phabricator.services.mozilla.com/D119488
When `nsTextControlFrame` is reframed, `TextEditor`, anonymous `<div>`, its
`Text` and the independent `Selection`s are deleted temporarily and recreated
them.
If users are dragging text in `<input>` or `<textarea>`, the drag session's
source node is set to the anonymous text node in the element and the selection
is set to the independent selection. So, if the element is reframed during a
drag, the source node is disconnected from the document and `EndDragSession`
failed to dispatch `eDragEnd` event.
Therefore, this patch makes `nsTextControlFrame` replaces the source node and
selection when it's recreated and only when the drag session's original source
node was in the text control element. For checking which text control had the
anonymous text node, this patch makes `nsTextControlFrame` replaces source
node with the `<input>` or `<textarea>` element when the frame is destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D119487
With IIEF, we can guarantee each test block isolated. So, without declaring
semi-global variables a lot for all tests, developers can comment out every
tests to debug only one thing.
Differential Revision: https://phabricator.services.mozilla.com/D119486
When the test is timed out, there is a JS error which is thrown by
`synthesizePlainDragAndDrop`. So, first, make the test handle exception
with `try-catch` and assert the error.
Differential Revision: https://phabricator.services.mozilla.com/D119485
For some h264 videos, MFT decoder will return the incorrect first output which presentation time is always zero. We also saw this issue before after calling draining [1].
If we accept that incorrect output, that will cause an out-of-order video frame get stored in our video queue and causes MDSM triggering the mechanism to request the next key frame because that out-of-order frame is way behind the current audio clock.
Therefore, we should filter that incorrect output out, and make sure we won't incorrectly discard the real first frame when this issue doesn't happen.
[1] https://stackoverflow.com/questions/39695131/windows-mft-media-foundation-transform-decoder-not-returning-proper-sample-tim
Differential Revision: https://phabricator.services.mozilla.com/D119439
For some h264 videos, MFT decoder will return the incorrect first output which presentation time is always zero. We also saw this issue before after calling draining [1].
If we accept that incorrect output, that will cause an out-of-order video frame get stored in our video queue and causes MDSM triggering the mechanism to request the next key frame because that out-of-order frame is way behind the current audio clock.
Therefore, we should filter that incorrect output out, and make sure we won't incorrectly discard the real first frame when this issue doesn't happen.
[1] https://stackoverflow.com/questions/39695131/windows-mft-media-foundation-transform-decoder-not-returning-proper-sample-tim
Differential Revision: https://phabricator.services.mozilla.com/D119439
ActorReadyGeckoProfilerInterface is used in two contexts:
- For the perf actor, which is used when the profiler is used from the
devtools Performance panel or via remote debugging (on about:debugging), and
- On about:profiling, which only exercises a subset of the interface's methods
because about:profiling does not have any UI for capturing profiles.
There are three other ways to capture profiles:
- The global browser keyboard shortcuts (implemented in DevToolsStartup.jsm)
- Clicking the toolbarbutton directly (implemented in popup/menu-button.jsm.js)
- Clicking the Capture button inside the popup (implemented in popup/panel.jsm.js)
These three other ways use functions in popup/background.jsm.js to capture the profile.
They do not call ActorReadyGeckoProfilerInterface.getProfileAndStopProfiler().
When the ActorReadyGeckoProfilerInterface instance for the perf actor is created,
we pass { gzipped: false }. Consequently, ActorReadyGeckoProfilerInterface.getProfileAndStopProfiler()
is only ever called with gzipped: false. So the option can be removed.
The other three ways to capture profiles, which use captureProfile in
popup/background.jsm.js, always get the gzipped profile because captureProfile
calls Services.profiler.getProfileDataAsGzippedArrayBuffer().
Differential Revision: https://phabricator.services.mozilla.com/D119561
Worker targets only set threadActor late, quite asynchronously.
So that the target is registered in TargetCommand, but we can't call target.getFront
without having it to throw.
Differential Revision: https://phabricator.services.mozilla.com/D119672
It looks like this suppression was removed downstream, but StartupCache's behavior still exists so it most likely stopped causing failures because of some other suppression interacting with it. I decided the best course of action was to put it back as a perma suppression in gecko in case we run into it again.
Differential Revision: https://phabricator.services.mozilla.com/D119783