We then convert that to `#aarrggbb` in GeckoView for convenient use
with `android.graphics.Color`.
Differential Revision: https://phabricator.services.mozilla.com/D57689
--HG--
extra : moz-landing-system : lando
`synthesizePlainDragAndDrop()` synthesizes drag events with `DataTransfer`
object which is set to `DragEvent.dataTransfer` of `dragstart` after starting
drag session explicitly. However, this causes
`EventStateManager::DoDefaltDragStart()` does not initialize `nsIDragService`
instance. Therefore, synthesized drag events cannot work with editor because
`DragEvent::GetMozSourceNode()` returns `nullptr` due to
`nsIDragSession::GetSourceNode()` returning `nullptr`.
On the other hand, synthesized drag events cannot use
`nsIDragService::InvodeDragSession()` normally because of hitting an assertion.
https://searchfox.org/mozilla-central/rev/690e903ef689a4eca335b96bd903580394864a1c/widget/nsBaseDragService.cpp#230-233
This patch does:
- mark drag events caused by synthesized mouse events as "synthesized for tests"
- make `synthesizePlainDragAndDrop()` stop using
`nsIDragService.startDragSession()`
- make `nsBaseDragService` initialize and start session even for synthesized
`dragstart` event
- make `synthesizePlainDragAndDrop()` stop synthesizing drag events with
`DataTransfer` object since it's normal behavior and it'll be initialized
with `nsIDragService::GetDataTransfer()`
- make `nsBaseDragService` store `effectAllowed` for the session only when
it's synthesized session because it's required at initializing synthesized
default `dropEffect` value of `dragenter`, `dragover`, `dragexit` and `drop`
events' `dataTransfer`
- make all tests which use `nsIDragService.startDragSession()` use new
API, `nsIDragService.startDragSessionForTests()` to initialize session's
`effectAllowed` value
- make `EventStateManager::PostHandleEvent()` set drag end point of the test
session to `eDrop` event's screen point
- make `synthesizePlainDragAndDrop()` set drag end point of the session if
it does not synthesize `drop` event because following `endDragSession()`
use it at dispatching `dragend` event on the source element
Additionally, this adds `dumpFunc` new param to `synthesizePlainDragAndDrop()`
because it's really useful to investigate the reason why requesting DnD isn't
performed as expected.
Differential Revision: https://phabricator.services.mozilla.com/D57425
--HG--
extra : moz-landing-system : lando
Remove the security.sandbox.gmp.mac.earlyinit pref now that GMP early sandbox init is the default on release.
Remove the old unused code paths for initializing the GMP sandbox later during process startup (only used when security.sandbox.gmp.mac.earlyinit=false).
Differential Revision: https://phabricator.services.mozilla.com/D54968
--HG--
extra : moz-landing-system : lando
Remove the security.sandbox.rdd.mac.earlyinit pref now that RDD early sandbox init is the default on release.
Remove the old unused code paths for initializing the RDD sandbox later during process startup (only used when security.sandbox.rdd.mac.earlyinit=false).
Differential Revision: https://phabricator.services.mozilla.com/D54967
--HG--
extra : moz-landing-system : lando
Phase 1 is still "profile-change-teardown", where the workers are
terminated. Phase 2 is "profile-before-change-qm", where the
PServiceWorkerManager actors are terminated. This split lets
ServiceWorkerCleanup perform any unregistering needed during
"profile-before-change" (which uses the SWM actors).
Differential Revision: https://phabricator.services.mozilla.com/D58058
--HG--
extra : moz-landing-system : lando
Inheriting from `nsISupports` is too complicated if we just want to support refcounting. Instead, we can use `NS_INLINE_DECL_PURE_VIRTUAL_REFCOUNTING` to declare `Add/RemoveRef()` as pure virtual functions in order to create ref-counted abstract classes.
Differential Revision: https://phabricator.services.mozilla.com/D57714
--HG--
extra : moz-landing-system : lando
We handle media control key events differently from normal key events, and at this point we haven't finished the implementation of capturing media control key events on each platform. Therefore, create a method to generate platform-independent events in order to help testing.
Differential Revision: https://phabricator.services.mozilla.com/D57911
--HG--
extra : moz-landing-system : lando
Without this, the window just stays open in the background, constantly
re-submitting forms to itself.
Differential Revision: https://phabricator.services.mozilla.com/D58034
--HG--
extra : moz-landing-system : lando
The mute event listener needs to be added to the chain earlier as the track
will already have muted after renegotiation occurs. We could remove the
check completely, but this will help ensure we don't regress firing mute events
when the track is stopped.
Differential Revision: https://phabricator.services.mozilla.com/D57865
--HG--
extra : moz-landing-system : lando
Add more log to see (1) if media start playing and (2) if seeking starts, in order to get more information to solve the intermittent failure.
Differential Revision: https://phabricator.services.mozilla.com/D57174
--HG--
extra : moz-landing-system : lando
When a content or plug-in process crashes too early we haven't initialized the
CrashReporterHost for that process. This will cause the crash to be orphaned,
i.e. to miss most of its crash annotations. We added code to finalize those
crashes in bug 1282776 so that we wouldn't miss them entirely. This ensured
that crash reports would have both their .dmp and .extra files but the patch
failed to modify the code that notified various listeners about the crash
report's presence.
This changes always send the crash ID alongside the crash notifications, even
for orphaned crashes, so that listeners such as the content crash handler or
the test harnesses can always find the minidump and .extra file. Additionally
orphaned crashes are recorded in the CrashManager and in telemetry just like
normal crashes.
This also re-enables dom/ipc/tests/process_error.xul which failed frequently
because of this bug.
Differential Revision: https://phabricator.services.mozilla.com/D57634
--HG--
extra : moz-landing-system : lando
With tracks in different MTGs we risk of having thread races if we stop and start immediatelly. Previously, stoping and starting was happenign to the same MTG so this problem did not exist. This change wires a promise in the `MediaTrack::RemoveListener` method and perform the start when that step has been completed.
Differential Revision: https://phabricator.services.mozilla.com/D57947
--HG--
extra : moz-landing-system : lando
The test fails with my <input type=number> rewrite because editor fails to
dispatch one input event caused by these mouse events.
The reason for this is that we schedule them from an input event, which fires
from here:
https://searchfox.org/mozilla-central/rev/6305f6935f496b3a302c7afcc579399a4217729c/editor/libeditor/EditorBase.cpp#965
Not how at that point we still haven't decremented mPlaceholderBatch. That means
that other stuff that triggers input events from there will not dispatch events.
I think that's a bit unexpected, but it is a preexisting problem, and can't
happen for users because mouse events go through the event loop.
Differential Revision: https://phabricator.services.mozilla.com/D57810
--HG--
extra : moz-landing-system : lando
Some calls to `ComparePoints_Deprecated` remain, because adapting them
would require to add boilerplate code, which potentially will be deleted
again once `ComparePoints` supports crossing the Shadow DOM boundary.
Differential Revision: https://phabricator.services.mozilla.com/D57615
--HG--
extra : moz-landing-system : lando
This changeset is a simple find and replace of `MOZ_FALLTHROUGH` and `[[fallthrough]]`.
Unfortunately, the MOZ_FALLTHROUGH_ASSERT macro (to assert on case fallthrough in debug builds) is still necessary after switching from [[clang::fallthrough]] to [[fallthrough]] because:
* MOZ_ASSERT(false) followed by [[fallthrough]] triggers a -Wunreachable-code warning in DEBUG builds
* but MOZ_ASSERT(false) without [[fallthrough]] triggers a -Wimplicit-fallthrough warning in NDEBUG builds.
Differential Revision: https://phabricator.services.mozilla.com/D56440
--HG--
extra : moz-landing-system : lando
When we open a new window from a content process, we create a nested event
loop to wait for it to be initialized by the parent. The problem with this is
that the OpenWindow code which calls the window provider expects the window to
be in-process and uninitialized, so that it can load its own initial URI into
it, and correctly fulfil the spec-codified contract of window.open(). If
another caller initiates a load in the new window during the nested event
loop, those invariants are broken, and any manner of undefined behavior can
occur.
This patch adds a new flag to the BrowsingContext, marking it as uninitialized
until the end of the nested event loop, and blocking any attempts to load a
new URI into it in the meantime.
Differential Revision: https://phabricator.services.mozilla.com/D57667
--HG--
extra : moz-landing-system : lando
This doesn't solve all problems with potential reentrancy during window.open
nested event loops, but it does improve the situation somewhat. Since any
window in the same BrowsingContextGroup can target any window in the same
group, we need to suspend all windows in the group, not just the root of the
new window's parent. We also need to make sure we suspend all in-process
windows, even if we have out-of-process frames somewhere in the parent chain.
This patch takes care of suspending timeouts and input event handling in all
of these cases. It doesn't block all potential paths for running code in the
suspended windows, though, so the next patch explicitly prevents the
problematic reentrancy.
Differential Revision: https://phabricator.services.mozilla.com/D57666
--HG--
extra : moz-landing-system : lando