Issue 6865 - Update ABP dependency to version 3.2

toolkit/components/extensions/schemas/runtime.json

Index: toolkit/components/extensions/schemas/runtime.json
===================================================================
--- a/toolkit/components/extensions/schemas/runtime.json
+++ b/toolkit/components/extensions/schemas/runtime.json
@@ -154,16 +154,40 @@
       "id": {
         "type": "string",
         "allowedContexts": ["content", "devtools"],
         "description": "The ID of the extension/app."
       }
     },
     "functions": [
       {
+        "name": "abbRegisterRequestListener",
+        "type": "function",
+        "allowedContexts": ["content", "devtools"],

[Thomas Greiner, 2018/08/27 15:24:42]

From what I understood we only need to communicate with the background page so
instead of exposing it to those other contexts - and thereby increase the risk
of opening up a security hole - what about just checking in extensionBridge.js
whether the API is available before using it?

[diegocarloslima, 2018/08/27 21:19:17]

If I dont add at least the 'content' context, I cant actually call those
functions from extensionBridge.js . I understand that it could be a potential
security breach, but since we're in control of the extensions that are installed
on ABB (for instance, we only install ABP), this shouldnt be a big concern. For
the 'devtools' context, it might not be needed, just added because all the other
functions had it, so I didnt want to have some unexpected edge case behavior

[Thomas Greiner, 2018/08/28 10:36:07]

That's odd because "content" seems to refer to content scripts (i.e. the
extension code that is running in the context of a web page) and not to the
background page which we want to communicate with.

Unfortunately, I couldn't find a proper documentation for it other than what's
mentioned at
https://wiki.mozilla.org/WebExtensions/Implementing_APIs_out-of-process#shoul....
But there appear to be other API functions which don't specify the
"allowedContexts" property (e.g.
https://github.com/mozilla/gecko-dev/blob/master/toolkit/components/extension...).
Note that it's not about whether a different extension could use this API but
about us exposing an API to a part of our extension that is directly interacting
with untrusted content (i.e. the web page). So it'd be great if we could somehow
limit our APIs to only the background page to sandbox it further.

+        "description": "Function required to listen to Android requests. See https://issues.adblockplus.org/ticket/6865",

[Thomas Greiner, 2018/08/27 15:24:42]

Suggestion: The naming confused me at first because "Android requests" makes it
sound like it's about network requests that are passed on by the OS. However,
it's about passing messages between Adblock Browser and the extension.

So what about saying that and use consistent naming with the rest of the web
extension API? Because note that `chrome.extension.sendRequest()` has been
deprecated in favor of `chrome.runtime.sendMessage()`.

i.e.
Renaming `abbRegisterRequestListener()` to `onAbbMessage.addListener()` (see
also `onMessage.addListener()` and `onMessageExternal.addListener()`)
and renaming `abbSendRequest()` to `sendAbbMessage()` (see also `sendMessage()`
and `sendNativeMessage()`).

[diegocarloslima, 2018/08/27 21:19:17]

I will rename 'abbSendRequest' to 'sendAbbMessage', but for the listener, I
prefer to keep it as a function, if I add it as another property that has a
function, it would require more changes in the upstream code than the actual
solution, which is not desired. I will keep it as a function, but will rename it
to 'registerAbbMessageListener'

[Thomas Greiner, 2018/08/28 10:36:07]

Sounds good. :)

+        "parameters": [
+          {
+            "name": "listener",
+            "type": "function"
+          }
+        ]
+      },
+      {
+        "name": "abbSendRequest",
+        "type": "function",
+        "allowedContexts": ["content", "devtools"],
+        "description": "Function required to send requests to Android. See https://issues.adblockplus.org/ticket/6865",
+        "parameters": [
+          {
+            "name": "type",
+            "type": "string"
+          }
+        ]
+      },
+      {
         "name": "getBackgroundPage",
         "type": "function",
         "description": "Retrieves the JavaScript 'window' object for the background page running inside the current extension/app. If the background page is an event page, the system will ensure it is loaded before calling the callback. If there is no background page, an error is set.",
         "async": "callback",
         "parameters": [
           {
             "type": "function",
             "name": "callback",