Issue 5587, 5748 - Use mobile options page on Firefox for Android

desktop-options.js

Index: desktop-options.js
===================================================================
copy from options.js
copy to desktop-options.js
--- a/options.js
+++ b/desktop-options.js
@@ -740,8 +740,19 @@
     case "prefs.respond":
       onPrefMessage(message.action, message.args[0]);
       break;
     case "subscriptions.respond":
       onSubscriptionMessage(message.action, message.args[0]);
       break;
   }
 });
+
+$(() =>

[Manish Jethani, 2017/09/26 20:37:16]

As the last thing in this script, we add a listener for jQuery's ready event and
dispatch a ping from there.

We could wait until window.load but it is not necessary.

Also note that we could do this in the top frame, but then the top frame would
have to know when the best time to dispatch the ping would be, for both
desktop-options and mobile-options. This knowledge is internal to the two
different pages, hence it's best they do it themselves.

[Sebastian Noack, 2017/09/27 01:38:34]

Perhaps we don't even need this.

All, the old options page, the new desktop options, and the new mobile options
page send an "app.listen" message as soon as they are ready.

The problem, however, is that we still need a way to detect the options page in
case it has already been open. But perhaps, we don't have to bother about timing
that much in this situation. It seems extremely unlikely that the user could
trigger the options page to be opened and then clicks an abp:subscribe (for
example) in less than it takes to load the options page.

So we could just check whether the options page is already open, and if so
assume that it is ready, and if not open it and then wait for the "app.listen"
event. What do you think?

[Manish Jethani, 2017/09/27 11:20:54]

We could use "app.listen" in lieu of "ping" here. It seems to be dispatched
before the frame's load event. Perhaps then it would make sense to move the code
that waits for the "app.listen" message before sending its own message,
"app.respond" or "app.addSubscription" or whatever, out of lib/options.js and
wherever it is specifically needed. Either that, or showOptions takes a
"waitForMessage" parameter and waits until that message before invoking the
callback; then the caller can pass in the appropriate message type.
runtime.openOptionsPage doesn't tell you if the page was already open, so then
we'd have to resort to using tabs.query the way we're doing for Edge and Firefox
for Android, but yeah it would work.

+{
+  ext.onMessage.addListener((message, sender, sendResponse) =>
+  {
+    if (message.type == "ping")
+      sendResponse(true);

[Manish Jethani, 2017/09/26 20:37:15]

We also have to respond to any ping we receive.

+  });
+
+  ext.backgroundPage.sendMessage({type: "ping"});
+});