When it is enabled, CanvasTranslator and mPendingCanvasTranslatorEvents are used to handle TranslateRecording() and related events serially.
For now, mPendingCanvasTranslatorEvents is used only with the following situation.
- gfx.canvas.remote.use-canvas-translator-event
- !mTranslationTaskQueue
pref gfx.canvas.remote.use-canvas-translator-event is enabled only with Nightly, since its usage is going to be synchronized with pref gfx.remote-texture.wait-owner-at-image-host until release.
Differential Revision: https://phabricator.services.mozilla.com/D212219
Back when this was done, we had some trouble with make calling commands
through the shell instead of via CreateProcess on Windows, which made
the intermediate shell replace /ARG with c:\path\to\msys\ARG paths,
which didn't end up well.
This however doesn't happen anymore, so we can get rid of the hack.
That leaves us with only the backslash problem, but because it's a windows
problem, rather than being related to the compiler being clang-cl, we also
fix the condition under which we make the switch to forward slashes.
Differential Revision: https://phabricator.services.mozilla.com/D213538
For some reason, we ended up using -Xclang -std=c++17, when we could
just have used -std:c++17, which simplifies things.
Differential Revision: https://phabricator.services.mozilla.com/D213537
-isysroot was appearing in the llvm-config output on mac in very old
clang.llvm.org builds. The latest builds don't do that anymore, and our
own bootstrapped builds don't either.
-gcc-toolchain was filtered out because we were using it to build our
own clang and that transpired in llvm-config, but we don't anymore, as
of bug 1719226.
Differential Revision: https://phabricator.services.mozilla.com/D213534
`eContextMenu` event may be fired from `widget`. Therefore, different from
`ePointerClick` and `ePointerAuxClick`, they may cross the process boundary,
may be handled by APZ and may be dispatched into the DOM after a delay.
Therefore, this patch is complicated than the previous patch. This adds
* New IPC message handlers for sending/receiving a `WidgetPointerEvent`
* New `DelayedPointerEvent` class and templated `MouseInput::ToWidgetEvent`
* `PresShell::EventHandler` handles `eContextMenu` as same as `WidgetMouseEvent`
Differential Revision: https://phabricator.services.mozilla.com/D213003
This patch makes the all `ePointerClick` event dispatcher in C++ code use
`WidgetPointerEvent` instead of `WidgetMouseEvent`.
Then, this patch also makes the all `click` event dispatcher in chrome code use
`PointerEvent` instead of `MouseEvent`. For detecting wrong trusted event
dispatching of `click` event, this patch adds assertion into `MouseEvent`.
Therefore, all chrome test dispatchers also changed to use `PointerEvent`.
Finally, this patch includes a change of a WPT. That checks the `pointerId`
caused by executing an access key. In this case, the value should be `-1`
rather than the default value `0` because Pointer Event spec defines so for
synthetic pointer events caused by non-pointing devices [1]. Chrome also
sets it to `-1` and fails [2]. Therefore, the new assertion will pass on both
Firefox and Chrome.
1. https://w3c.github.io/pointerevents/#dom-pointerevent-pointerid
2. https://wpt.fyi/results/uievents/interface/keyboard-accesskey-click-event.html?run_id=5087897523060736&run_id=5136270464647168&run_id=5163620816388096&run_id=5201281304231936
Differential Revision: https://phabricator.services.mozilla.com/D213001
While handling an "insertParagraph" command, it's closed at least in the editing
host. Therefore, it's file to use editing host outside `<body>` because it
won't make the tree messy outside the editing host.
Differential Revision: https://phabricator.services.mozilla.com/D213376
I don't reproduce the crash even if I rewrite the test using `attachShadow`
which replaced `createShadowRoot`. Therefore, this patch just adds the reported
testcase into the tree.
Differential Revision: https://phabricator.services.mozilla.com/D213375
This patch ensures that every button in the SelectTranslationsPanel
can be invoked both with the Enter key or the space bar on all
operating systems.
Differential Revision: https://phabricator.services.mozilla.com/D213635
nsAutoTArray was renamed to AutoTArray.
nsDataHashtable and nsJSThingHashtable don't exist any more.
nsTHashMap and nsTHashSet now exist.
nsDeque is properly typed now.
Pair is now CompactPair.
Differential Revision: https://phabricator.services.mozilla.com/D213624
* Rearrange the `ShoppingSidebarManagerClass` to clearly separate
public and private APIs.
* Ensure all public methods include a PBM check and add a comment
encouraging future refactorings to preserve this property of the
public API as a whole.
* Also add a check at the IPC layer, updating the child and parent
actor code to bail out if a message is received in a private window.
Differential Revision: https://phabricator.services.mozilla.com/D213618
Before trying to address the issue in depth (possibly backporting an
upcoming llvm-config change), let's just revert to something that is
known to work for the moment.
Differential Revision: https://phabricator.services.mozilla.com/D213529
On clang-cl builds, the compiler and the linker are two completely different
things. The linker thankfully ignores the flags it doesn't know but
it's not optimal that it has to complain about them.
The historical reason we add compiler flags to linker flags is that some
flags, mostly related to optimization, such as -flto or --profile-generate,
need to be applied to both. This generally keeps being true for builds
using clang or GCC, although ideally we'd set things separately.
Anyways, generally speaking, we don't expect such flags to be necessary
for host linking, so let's start by cleaning up those. This does affect
all builds, but shouldn't matter.
It is worth noting that commands to link target things on clang-cl
builds actually use a different set of flags, so the linker doesn't end
up complaining about unknown arguments there.
Differential Revision: https://phabricator.services.mozilla.com/D213524
This will allow follow up patches to use the render task data
for blurs as suitable surfaces to apply mask sub-passes on.
Differential Revision: https://phabricator.services.mozilla.com/D213487
Tricky to test cache-hit/miss behavior in automation, but tested manually with the
example from the bug and works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D213614
