Installed privileged addons in GeckoView sometimes need to send messages from
content scripts. Today we use the in-memory flag `ALLOW_CONTENT_MESSAGING` to
allow a specific built-in addon to send messages from content scripts, but for
installed extensions we need a way to persist this flag.
To do this, this patch introduces a new privileged permission
`nativeMessagingFromContent`, when this permission is present in the manifest,
the addon will be allowed to send native messages from content scripts (note:
the addon will also need `nativeMessaging` as usual).
When the permission is not present, any attempt to send a native message from a
content script will result in an error, similarly to what happens before this
patch.
Differential Revision: https://phabricator.services.mozilla.com/D72976
Sometimes extensions call tabs.create immediately on startup. In that case the
delegate may not be attached yet. To avoid losing these messages we store them
until a delegate is attached.
This also includes a refactoring to unify behavior for delegates. Eventually I
want to factor out delegates similarly to what happens in GeckoSession today.
Differential Revision: https://phabricator.services.mozilla.com/D72975
We use this to send a default action to the embedder, but if no one is
listening there's no point, and it causes problems in tests because sometimes
the delegate is attached / reattached too quickly and the second delegate will
end up getting two messages by mistake.
Differential Revision: https://phabricator.services.mozilla.com/D72974
Installed privileged addons in GeckoView sometimes need to send messages from
content scripts. Today we use the in-memory flag `ALLOW_CONTENT_MESSAGING` to
allow a specific built-in addon to send messages from content scripts, but for
installed extensions we need a way to persist this flag.
To do this, this patch introduces a new privileged permission
`nativeMessagingFromContent`, when this permission is present in the manifest,
the addon will be allowed to send native messages from content scripts (note:
the addon will also need `nativeMessaging` as usual).
When the permission is not present, any attempt to send a native message from a
content script will result in an error, similarly to what happens before this
patch.
Differential Revision: https://phabricator.services.mozilla.com/D72976
Sometimes extensions call tabs.create immediately on startup. In that case the
delegate may not be attached yet. To avoid losing these messages we store them
until a delegate is attached.
This also includes a refactoring to unify behavior for delegates. Eventually I
want to factor out delegates similarly to what happens in GeckoSession today.
Differential Revision: https://phabricator.services.mozilla.com/D72975
We use this to send a default action to the embedder, but if no one is
listening there's no point, and it causes problems in tests because sometimes
the delegate is attached / reattached too quickly and the second delegate will
end up getting two messages by mistake.
Differential Revision: https://phabricator.services.mozilla.com/D72974
To support this API, we do the following:
Additions to `GeckoSessionTestRule`:
* We add an overload to `webExtensionApiCall` that accepts a `GeckoSession`
argument. Instead of sending the message to the extension's background script,
this overload instead sends the message to the port for the session's
content script.
* We add `GeckoSessionTestRule.getSessionPid()` which uses the new
`webExtensionApiCall` overload. Moving other existing APIs over to use the
new overload is out of scope for this bug and should be done in follow-ups.
Additions to the `test-support` extension:
* We modify the content script to receive an API call message from the native
port. It then forwards the request up to the background script. By doing it
this way, the background script will receive the message along with the
WebExtension `Tab` object belonging to the sender;
* The background script's message handler merges the tab into the arguments
to the API as a `tab` property;
* The background script then calls the API and the result is returned to
the harness using the native port, just like the normal implementation;
* We add a `GetPidForTab` API for resolving top-level PIDs from a webext tab id.
Differential Revision: https://phabricator.services.mozilla.com/D73723
Raw Cr.ERROR don't get stack information, same as throwing JS literals instead
of `new Error()`s.
This was done automatically with a new eslint rule that will be introduced in
the next commit. One instance of a raw Cr.ERROR was not replaced since it is
used in a test that specifically checks the preservation of raw Cr values in
XPCJS. The rule will be disabled for that instance.
Differential Revision: https://phabricator.services.mozilla.com/D28073
When exporting the addon object, the extension policy sometimes is not ready
yet (very common when `list()` is called at startup), so we need to wait until
it's ready or the values in it will not be correct.
Differential Revision: https://phabricator.services.mozilla.com/D73770
These support the new implementation of the addon blocklist (bug 1620621),
which is a more space-efficient way to represent the blocklist.
A comparison of file size was given in D73159. In short, 913KB for the
old JSON-based blocklist (addons.json), 64KB for the new one.
In practice, addons.json is 273KB compressed.
The new blocklist (addons-mlbf.bin) does not compress that well since it
is already an efficiently packed binary format.
Differential Revision: https://phabricator.services.mozilla.com/D73438
Actually we emulate key event (down, press and up) from replace transaction of
`Editable`. When dispatching key press, we always update current caret position.
Most situations is the following.
1. Dispatch keypress
2. Dispatch another keypress
3. Receive merged text/selection change result by 1. and 2.
4. Sync shadow (Java's Editable) text with 3.'s result. It means selection is
correct position now.
5. Dispatch keypress with correct position.
When this issue occurs, the following situation occurs.
1. Dispatch keypress
2. Dispatch another keypress
3. Receive text/selection change result of 1.
4. Sync shadow (Java's Editable) text with 3.'s result. It means selection is
old position now.
5. Dispatch another keypress with old position.
6. Receive text/selection change result of 2.
7. Receive text/selection change result of 5.
So when dispatching key press, we shouldn't always update selection if unnecessary.
Because selection range is already often set before dispatching key press.
Differential Revision: https://phabricator.services.mozilla.com/D71179
We need to move these tests to their own class so that we can add a `@Before`
function to set up the expected start conditions.
We also need to allocate the second session in such a way that it is
hosted by the same content process as `mainSession`.
The previous scheme of waiting on each `GeckoResult` independently caused
deadlocks if the results are resolved in a different order, so I replaced those
two waits with a `GeckoView.allOf` result that will Just Work (TM).
Note that this scheme works both in single-e10s and multi-e10s
configurations.
Differential Revision: https://phabricator.services.mozilla.com/D67067
Turn on some tests for InputConnection's behaviors. `inputConnection_setSelection` and `inputConnection_bug1133802` are still disabled due to Gecko issue and no good events.
Although I repeat 30 times to run this after this, no error now.
Differential Revision: https://phabricator.services.mozilla.com/D71151
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
`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
We don't currently restart the extension process and this causes extensions to
randomly stop working when Android kills the extension process.
We can re-enable it once Bug 1355239 is fixed.
Differential Revision: https://phabricator.services.mozilla.com/D71790
This patch removes the allowLinkedWebInFileUriProcess pref, but one
code-path is kept because when DocumentChannel is disabled a HTTP POST load
from a file:// page would loose the postData, so that case keeps the FILE
remote type.
Differential Revision: https://phabricator.services.mozilla.com/D69923
John Lin
Simon Giesecke
Csoregi Natalia
Agi Sferro
Mihai Alexandru Michis
Aaron Klotz
Ian Moody
Rob Wu
owlishDeveloper
Dylan Roeh
Makoto Kato
jayati
Shane Caraveo
Masayuki Nakano
Ricky Stewart
Paul Bone
Kartikaya Gupta