When using split window, the position of selection context menu is
strange position.
When on Android 11+, it has independent window manager per split
window, `onGetContentRect` of `ActionMode.Callback2` seems to use this
coordinates, instead of screen coordinate.
So we should consider this situation.
Also, our CI has no Android 11+ and no way to set split window, so I
cannot add unit test for it.
Differential Revision: https://phabricator.services.mozilla.com/D170472
This patch:
- adds a new pref "extensions.formautofill.addresses.capture.v2.enabled". When the pref is on,
we will use "save address" and "update address" doorhnager instead of
"first time use" doorhanger for address capture.
- adds a AddressComponent class, which converts "address record" into an
object that we can more easily compare each address field.
- defines when we consider one address is a duplicated address of another
one (See AddressComponent.isDuplicate for details)
- defines when we consider one address can be merged into another
address (See AddressComponent.isMergeable for details)
This patch does NOT:
- implements comparison heuristics for individual address fields.
This patch simply compares string directly.
Differential Revision: https://phabricator.services.mozilla.com/D170352
It's called by `PeekOffsetFor*` and `GetPrevNextBidiLevels`, so it's used for
considering whether to put caret or move a selection range boundary.
Therefore, it should treat nodes which can be managed by `Selection` as
selectable. In theory, even if a native anonymous subtree does not have
an independent selection, its content nodes should not be the container of
the selection range boundaries of selection outside the subtree since
Selection API shouldn't expose nodes in native anonymous subtrees. Therefore,
it can simply treat content nodes in different anonymous subtrees are not
selectable.
Note that it's not standardized that how `Selection.modify` works with various
content nodes.
https://w3c.github.io/selection-api/#dom-selection-modify
And also Chrome cannot cross generated content like form controls with this API.
This could cause web-compat issues, but it does not make sense for caret
navigation, and anyway out of scope of this bug. Therefore, this patch just
adds the crash test.
Differential Revision: https://phabricator.services.mozilla.com/D172204
What was added in bug 1378830 was broken by bug 1255485. Not in a super
visible way, but the undesirable side effect is that C programs end up
being linked against the C++ runtime. Which didn't cause practical
problems until bug 1820947.
Differential Revision: https://phabricator.services.mozilla.com/D172519
The extant code would fail if the user switched languages while the dialog was
open, as fluent would throw the manually-inserted content away. This patch
properly uses fluent to insert the channel, which also means we don't need to
wait for it to happen after `load` (because of the previous patch in this
stack), it'll be there immediately.
Differential Revision: https://phabricator.services.mozilla.com/D172299
Add a JS::Heap<JS::Value> in WorkletFetchHandler to hold the script's
error to rethrow object.
This also requires to change WorkletFetchHandler to a CC class so it can trace the
mErrorToRetrhow
Depends on D166550
Differential Revision: https://phabricator.services.mozilla.com/D170162
Add a Runnable class called FetchCompleteRunnable to be dispatched from
main thread to worklet thread to call
ModuleLoadRequest::OnFetchComplete.
Depends on D167468
Differential Revision: https://phabricator.services.mozilla.com/D166545
Add a nsRefPtrHashtable<nsURIHashKey, ModuleLoadRequest> called mFetchingRequests
to map from nsIURI to ModuleLoadRequest.
When WorkletModuleLoader::StartFetch is called, it will insert an entry
into the table. Later when the main thread finishes the fetching of the module
script, we will use the URI to get the ModuleLoadRequest on worklet
thread and call ModuleLoadRequest::OnFetchComplete.
Depends on D166544
Differential Revision: https://phabricator.services.mozilla.com/D167468
