Bug 1805414 will move menu event handling to the DOM.
With that change the current synthetic click behavior of XUL menuitems
breaks. On current central, we rely on nsMenuFrame::HandleEvent not
getting called at all for synthetic clicks, and instead we just fire a
command event synchronously here:
https://searchfox.org/mozilla-central/rev/a0d4f8f112c5c792ae272bf6ce50763ddd23ffa2/dom/xul/nsXULElement.cpp#1071
After my patch the command event is fired properly (potentially
asynchronously too) by the regular menu activation machinery, which is
preferable.
* They fire a command event synchronously (even though on some
platforms like macOS activating a context menu item is async).
* They use a totally different codepath from what a user does.
* They don't deal with native menus, etc.
We have a proper API for this (activateItem) which takes a much more
closer codepath to what users do, requires that the menu is shown, etc.
Use that API instead for testing.
As a benefit, tests now do not need to close the context menu manually
when clicking on a menu item (because we trigger the same code path as
users clicking the menu).
Differential Revision: https://phabricator.services.mozilla.com/D164567
These can contain <foreignobject>, which contains HTML but does not normally create its own Accessible.
This means that these Accessibles could have TextLeafAccessible children.
TextLeafAccessible children must always have a HyperTextAccessible as a parent.
Therefore, we must use HyperTextAccessible for <svg> and <g>.
As well as fixing assertions, this allows text formatting to be queried for <foreignobject> content, which was previously broken.
Differential Revision: https://phabricator.services.mozilla.com/D164636
Technically we could still run these tests on the non-langpack parts of the MSIX package -- but ultimately these are the same files as in the win32 build, so it's probably not worth the effort.
Differential Revision: https://phabricator.services.mozilla.com/D164674
Our own updater is disabled when running out of an MSIX build, and we hide update related things from preferences because of that.
Differential Revision: https://phabricator.services.mozilla.com/D164671
This is only done by the Return-to-AMO flow, which is not supported in MSIX anyways.
Also, disable the RTAMO test for MSIX builds while we're here.
Differential Revision: https://phabricator.services.mozilla.com/D164666
Previously we were querying the current ARRAY_BUFFER_BINDING, which
would fail if you did:
```
BindBuffer(ARRAY_BUFFER, a)
VertexAttribPointer(...)
BindBuffer(ARRAY_BUFFER, b)
```
We would assume we should call VeretxAttribPointer again with `b` bound,
when we need to bind `a` instead.
Unfortunately, this is hard to test, and we only hit this on drivers
where we don't use VAOs, which are rare now.
Differential Revision: https://phabricator.services.mozilla.com/D164744
Our test infrastructure runs with midi.testing enabled, which generates
virtual devices. This is mostly what we want, but it does prevent us
from testing the "no devices detected" path in automation. I've tested
it locally.
Differential Revision: https://phabricator.services.mozilla.com/D164722
Nowadays, only the frontend code should pre-populate the nsIPrintSettings
objects with saved prefs (before passing them those objects to platform code).
We removed the InitPrintSettingsFromPrefs calls from the Windows and Linux
native dialog code, but apparently not the macOS code.
Differential Revision: https://phabricator.services.mozilla.com/D164709
Started callback interface functionality to UniFFI. Currently this only
supports the async fire-and-forget use case, where Rust queues a JS
function to run, but doesn't wait (or `await`) for the response.
The basic system is:
- The JS code registers a callback interface handler with the C++
code. This handler is responsible for the specifics of invoking the
callback.
- The C++ code defines a function to call a JS handler. Once the JS
handler registers itself with C++, the C++ registers it's function
with Rust.
- The C++ code queues the call to the JS main thread.
- Because of how UniFFI handles callback interfaces, the C++ code can
be "dumb". UniFFI sends a object id, method id, and RustBuffer
encoding all arguments. This means C++ doesn't need to care about
the specific arguments, they get unpacked by JS.
I tried to keep the generated code as simple as possible by moving the
complexity to static code. For JS this meant writing a generic
`UniFFICallbackHandler` class in the static code that the generated code
constructs. For C++ this meant the generated code defines a
`UniFFIGetCallbackInterfaceInfo` function that returns a struct with all
the data specific to a callback interface (it's name, the UniFFI
scaffolding init function, etc). The static code can then define a
generic `QueueCallback` function that looks up the callback interface
info using the interface ID and then makes the call.
Allow UniFFI functions to run on the main thread rather than always
being dispatched to a worker thread. This allows us to test invoking
callback interfaces from the main thread thread. I don't think we will
use this much currently, since we don't want to block the main thread
for any significant amount of time. However, this will pair well with
the next step in the project which is async -- allowing async Rust
functions to call async JS functions. In that scenario, dispatching to
the worker thread is unnecessary.
Callback interface objects present a potential memory leak, since you
can easily create a cycle between a JS Callback object and a UniFFIed
Rust object, and the GC has no way of detecting it. To try to detect
these there's some shutdown code that checks that there are no callbacks
registered during shutdown and prevents any future callbacks from being
registered.
Added a `config.toml` file and code to parse it. This is needed to
specify which functions should run on the main thread.
Updated the git commits for the several UniFFI examples/fixtures.
Differential Revision: https://phabricator.services.mozilla.com/D156116
This reverts part of Bug 1803486 Part 1.
The crashtest was adapted from bug 1805522 comment 0. I use wpt printing test
since window.print() doesn't work in wpt crashtest.
Differential Revision: https://phabricator.services.mozilla.com/D164635
As this is a capitalization change, it does not require a Fluent migration nor a
key bump for retranslation.
This patch also adds a test, and adjusts the existing test to be more flexible with
which panels it can inspect.
Differential Revision: https://phabricator.services.mozilla.com/D164480
This commit uses a "pull" approach, where the experiment details are
fished at presentation-time and the content `tag` updated.
A few notes:
- With this approach, the update function is pushed down to the leaf
node (the toast notification presentation layer). It would be nice to
do this at the experiment layer, but that layer doesn't resolve the
presentation layer at this time, so it would perhaps violate the
abstraction to lift the work higher.
- No effort has been made to mark `tag` as invalid in the messaging
experiment schemas. At this time, there's no provision for fields
accepted at the presentation layer (`ToastNotification.schema.json`)
but not at the experiment layer aggregating
presentations (`BackgroundTaskMessagingExperiment.schema.json`,
`MessagingExperiment.schema.json`). It's likely possible to arrange
this but not worth the effort at this time.
- The actual tag displayed is not captured in the message as it flows
through ASRouter. This is not likely to pose a problem.
- The actual tag displayed might be `optin-...`, potentially
complicating data analysis. Since it's essentially impossible for
regular users to opt-in to _background task_ messages, that's not a
pressing concern.
Differential Revision: https://phabricator.services.mozilla.com/D164508
