The new join/split node direction mode seems working well in the wild because
we have no regression reports about it. Therefore, we won't revert the pref
anymore, thus, the legacy mode behavior check is not required.
Differential Revision: https://phabricator.services.mozilla.com/D186680
It returns the result of
`MakeSureToKeepVisibleStateOfWhiteSpacesAroundDeletingRange()`, but it suggests
caret position only when it modifies the DOM tree since it does not take the
default caret position.
So, `DeleteContentNodeAndJoinTextNodesAroundIt()` does need to return
`aCaretPoint` with tracking it during DOM mutations if
`MakeSureToKeepVisibleStateOfWhiteSpacesAroundDeletingRange()` does not
suggest caret point.
I found this bug when I was trying to fix the unexpected failing of
forward delete at end of the last block in the editing host (bug 1850666)
because changing the error handling anyway cause another error at this line.
https://searchfox.org/mozilla-central/rev/bdd5b85b56885cd48bd91d262647e0d3499b3a27/editor/libeditor/HTMLEditorDeleteHandler.cpp#1652
Therefore, without fixing bug 1850666, I have no idea how to check this fix.
Differential Revision: https://phabricator.services.mozilla.com/D187196
gn -> c3355ed3a721f4ea815dda6fb4ab5c1520f7f376
ia -> 760ded69c73d3d25716b7aa7640db3aeb50bb7a5
ka -> fa81f0e2c7ad99bc3c0188d56cc014a42904d720
ko -> 7ca8fed9c509fdedf0af5d4a73f6da4633048000
ru -> d231b6b20edfba683fbfd3d272b6293accfabae0
sk -> a8e70ac23d19eed360cb6c5814c1fdc1822072e1
th -> 2bc01581c739bceb46145937080a1f3fbbf43111
zh-CN -> 62e9627d775895a0c026ebcf127c8dc496db0f03
Create a new type of nsHttpAtom, namely nsHttpAtomLiteral. This type is
constexpr-constructible and holds a non-owning reference to its name,
which must have global lifetime.
As a side effect, slightly rework nsHttpAtom interface to replace the
dangerous implicit conversion to const char* by a bool operator and test it.
Differential Revision: https://phabricator.services.mozilla.com/D184557
This fixes issues caught by the assertion added in the next patch. These operations
are actually infallible so didn't have the same performance cliff.
Differential Revision: https://phabricator.services.mozilla.com/D187265
This is basically bug 1795066, but for the non-ScreenGetterWayland
code-path.
Properly supporting GetWidgetScreen in ScreenGetterGTK caused this to
surface in environments where we'd otherwise reported the primary
monitor (which usually starts at 0, 0).
Differential Revision: https://phabricator.services.mozilla.com/D187297
`NewObject` implies constraints that the WebGPU W3C committee
specifically did not want, according to @jgilbert. We still need some
`Throws` annotations for fallible allocations, i.e., anything that
constructs a `Promise`, or which has exceptions thrown in cases of
violated constraints. These aren't part of the IDL spec., but they're
necessary for Firefox's implementation because of how our codegen works.
Differential Revision: https://phabricator.services.mozilla.com/D185107
Here comes a possible might cause the crash stack.
RemoteWorkerController creation fails. If it is Shutdown phase or OOM. The point is ServiceWorkerManager::mRemoteWorkerController is kept as nullptr.
WorkerManagerCreatedRunnable::mManagerWrapper is the only holder of the ServiceWorkerManager. And it would be released once the runnable finished.
When releasing WorkerManagerCreatedRunnable::mManagerWrapper, ServiceWorkerManager::UnregisterHolder() is called. In the end SharedWorkerManager::Terminate() is triggered to release the SharedWorker by calling SharedWorkerManager::mRemoteWorkerController::Terminate. However, SharedWorkerManager::mRemoteWorkerController is reasonably a nullptr here, then we meet a de-reference on nullptr.
Differential Revision: https://phabricator.services.mozilla.com/D187269