Firefox for Android support

[arantius]

https://blog.mozilla.org/addons/2023/08/10/prepare-your-firefox-desktop-extension-for-the-upcoming-android-release/

It was recently announced that extensions are (finally) coming back to Firefox for Android. An email addressed to me said "Again, we’d love to have your extension be part of the general availability release when it debuts later this year."

Research feasibility and/or implement Firefox for Android support. I don't know when "later this year" is, exactly.

[arantius]

After the above changes, I've: Installed a script, seen it run, opened the editor, changed a script, used a registered menu command. Everything seems to work so far.

[arantius]

While working on this I had noticed some occasional unreliability. But of course, I was working on it at the time and it was intermittent. I had planned/hoped to really look into things. But I probably figured it out just by sleeping on it.

We've probably always had a race condition. When the background script starts ( https://github.com/greasemonkey/greasemonkey/blob/master/src/bg/user-script-registry.run.js#L2 ) we load the user scripts. Separately (i.e. when a page loads) we might want to know which scripts are installed, to choose which to run. If the latter happens too soon, the former will not have (it's async after all) necessarily completed.

The key here is that ( https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Background_scripts#convert_to_non-persistent ) you have to "convert to non-persistent" background scripts, to run on Android now. I've noticed a warning logged, while developing, that because the dev tools are open, it's not unloading the background page. Makes sense, but also masks this issue while developing!

So I think we need to make sure that we block on completion of _loadUserScripts() before we service requests.

[Cerberus-tm]

Interesting. Block requestions before completion: does that mean the Javascript on the (unedited) page should be unable to make any requests to the Internet until all userscripts are loaded? Or is it only about requests from userscripts?

[arantius]

Sorry by "requests" I was referring to messages sent between content and background. I.e. https://github.com/greasemonkey/greasemonkey/blob/master/doc/Messages.md

[Cerberus-tm]

Sorry by "requests" I was referring to messages sent between content and background. I.e. https://github.com/greasemonkey/greasemonkey/blob/master/doc/Messages.md

Ahh that makes sense.

[arantius]

When GM.openInTab() is called:

Error: Type error for parameter createProperties (Property "openerTabId" is unsupported by Firefox) for tabs.create.

on Android. On desktop, it works.

[arantius]

Warnings from AMO:

• browserAction.setIcon is not supported in Firefox for Android version 57.0
  Warning: This API is not implemented by the given minimum Firefox for Android version
  src/bg/options.js line 68 column 8

• extension.getURL is deprecated
  Warning: This API has been deprecated by Firefox.
  src/bg/options.js line 71 column 18

  And a whole bunch from HTML files inside codemirror; files we should probably remove.

[arantius]

Need to confirm but I'm pretty sure this breaks GM.registerMenuCommand(). RMC works by opening a port (chrome.runtime.connect) between content and background.

If I add console.log('registered menu commands at', new Date()); to the script registering the command and

port.onDisconnect.addListener(port => {
  console.warn('port closed!');
});

To function GM_registerMenuCommand(), then load a page (and otherwise do nothing with that browser) I see:

registered menu commands at Date Tue Nov 14 2023 11:15:29 GMT-0500 (Eastern Standard Time)
port closed at Date Tue Nov 14 2023 11:15:59 GMT-0500 (Eastern Standard Time)

In the tab's console. After ~exactly 30 seconds, the port is closed (because the background page suspended?) and the command gets broken. If I keep opening the menu to check, more often than every 30 seconds, causing a message (many messages) to be sent to the background script, I can keep the port alive for at least several minutes.

(I'm scared that there are several other such subtle bugs hiding from this "simple" change to a non-persistent background script.)