Bug 1632096 added the capability to shared gl context with WebRender. This bug extends the support to non shared gl context.
Differential Revision: https://phabricator.services.mozilla.com/D72579
The `webext_storage_bridge` crate introduced in this commit bridges the
`mozIExtensionStorageArea` XPCOM interface to the `webext_storage` Rust
component from Application Services.
This commit factors out the following parts from bug 1623245, so that
we can land them piecemeal:
* The `mozIExtensionStorageArea` interfaces, which implement all the
methods needed to support the `storage.sync` API.
* A Rust implementation of the above, in `StorageSyncArea`.
* A `StorageTask` type, for dispatching storage operations to a
background task queue.
* A `LazyStore`, which wraps the Rust component's `Store` and lazily
initializes it on the background queue the first time it's used.
* A `StorageSyncService`, which is our singleton. It holds on to a
configured `StorageSyncArea`, and hands out references to it via
`getInterface`. Eventually, we'll extend this to support syncing,
too.
Differential Revision: https://phabricator.services.mozilla.com/D71897
Hooray, our first Application Services Rust component! This is a
mechanical run of `mach vendor rust`, split out into its own commit
to make reviewing the Firefox bindings easier.
Differential Revision: https://phabricator.services.mozilla.com/D71895
Actually, we use `Thread.sleep` to get next sampling duration. But as long as
old comment, this sampling min duration is 10ms. But when I test
`Executors.newSingleThreadScheduledExecutor` on old device (10 year's old
Galaxy Nexus) instead of Thread.sleep, it can use 2ms sampling duration.
So we should use ScheduledExecutorService instead.
Differential Revision: https://phabricator.services.mozilla.com/D70401
The out params mean the last collapsed selection range's result (although,
the meaning is odd and offset and length are not overwritten when there is
another collapsed range and it causes `DeleteNodeTransaction`). Additionally,
when and only when `DeleteNodeTransaction` and `DeleteTextTransaction` are
added to the `EditAggregationTransaction` created by
`CreateTransactionForSelection()`. Therefore, same result can be looked for
from its only caller, `DeleteSelectionWithTransaction()`.
Note that this makes the method slower if there are too many selection ranges,
but such case must be rare because:
1. We can assume that users rarely use multiple selection ranges for removing
multiple ranges of content except table.
2. Multiple selection is supported only by Gecko. Therefore, web apps must
not use multiple selection for this purpose.
So, it must be okay to use this slower approach for making the methods simpler.
If it'd become damage to some benchmarks, let's create faster access to get
transaction type.
Depends on D72293
Differential Revision: https://phabricator.services.mozilla.com/D72294
`HTMLEditor::DeleteSelectionWithTransaction()` calls `EditorBase`'s overridden
method and handles `nsIEditor::eStrip` case. Therefore, we can rename it with
stop calling the `EditorBase::DeleteSelectionWithTransaction()`, and make it
called by `EditorBase::DeleteSelectionWithTransaction()` only when it's
necessary.
Additionally, we can make all internal method callers of editor classes always
set `nsIEditor::eNoStrip` if the instance is `TextEditor`. This must make
the code easier to understand.
Depends on D72292
Differential Revision: https://phabricator.services.mozilla.com/D72293
The parameter is used only by `EditorBase::CreateTxnForDeleteRange()` to
extend collapsed range, but it accepts only `nsIEditor::eNext` and
`nsIEditor::ePrevious`. Therefore, using `nsIEditor::EDirection` does not
make sense. Instead, they should use new `enum class`,
`HowToHandleCollapsedRange`.
Depends on D72291
Differential Revision: https://phabricator.services.mozilla.com/D72292
`DeleteSelection*()` are members of `TextEditor`, but they are also used by
`HTMLEditor`. Therefore, they and pref cache members for them should be
in `EditorBase` too.
Depends on D71911
Differential Revision: https://phabricator.services.mozilla.com/D72290
Currently, all input (including user pastes) to an input field is truncated to
`maxlength`. This diff disables truncation for user pastes.
When (1) `GetEditAction` is `ePaste`, `ePasteAsQuotation`, `eDrop`, or
`eReplaceText` (ie we are dealing with a paste) and (2) `GetEditActionPrincipal`
is `nullptr` (ie we are dealing with a user edit and not a JS edit), allow a
paste without truncation. That means that, in this case, we will return
`EditActionIgnored` instead of trying to truncate the string.
This behavior is controlled by a new preference `editor.truncate_user_pastes`
which is `false` by default (set in `StaticPrefList.yaml`).
We also modify `editor/libeditor/tests/test_bug603556.html` which currently
expects the output of a paste longer than maxlength to be truncated.
Testing: Created
`editor/libeditor/tests/test_pasting_text_longer_than_maxlength.html` which
checks if a user can paste a password longer than `maxlength` and if the field
is then marked as `tooLong` (this was the original concern of the reporter of
Bug 1320229), and
`editor/libeditor/tests/test_setting_value_longer_than_maxlength_with_setUserInput.html`
which checks if `eReplaceText` has consistent behavior regardless of whether the
field has an associated editor (this test works by calling `setUserInput()`
before and after the element gets focus.) `./mach test editor/libeditor` tests
pass.
Differential Revision: https://phabricator.services.mozilla.com/D71689
They aren't used, so can easily be removed as the first part of
this seried of patches.
If this functionality is ever required, it can be handled by the
caller defining complex clip nodes explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D72261
Initial mach perftest for fenix, gve, fennec cold process applink.
Key metric is processLaunchToNavStart, although the standard navigation metrics are also captured.
Differential Revision: https://phabricator.services.mozilla.com/D72160
Currently we check heap thresholds after collecting the nursery but then clear majorGCTriggerReason if it was set. This leaves the trigger amounts set in the Statistics object.
Depends on D72383
Differential Revision: https://phabricator.services.mozilla.com/D72384