Will this project get support for Safari?

[149segolte]

In a WWDC session, Apple announced support for Web extensions on macOS and has provided conversion tools to port extensions.
The official documentation is at the link: https://developer.apple.com/documentation/safariservices/safari_web_extensions

[Poopooracoocoo]

it's only for macOS and not iOS fyi

[149segolte]

If the company is making efforts to make this available on macOS then it might lead to it later being ported to iOS.

[Juraj-Masiar]

I've been looking into porting my addons to Safari but there is one crucial feature missing - the runtime.onMessage API in there doesn't support replying to the message by returning a Promise, only by calling the sendResponse function which I don't use because it's not recommended and it doesn't exists in this polyfill anymore.

Would implementing this feature for Safari be outside of scope for this polyfill?

[rpl]

I've been looking into porting my addons to Safari but there is one crucial feature missing - the runtime.onMessage API in there doesn't support replying to the message by returning a Promise, only by calling the sendResponse function which I don't use because it's not recommended and it doesn't exists in this polyfill anymore.

Would implementing this feature for Safari be outside of scope for this polyfill?

I didn't spent yet enough time on tracking down all the differences in the Safari implementation to answer that question in a way as complete and final as I would like, but the following are some initial thoughts:

• Given that Safari should be already providing a Promised API, most of the code in this polyfill isn't really going to be that much useful on Safari, the runtime.onMessage API that @Juraj-Masiar did mention may be the only piece that may be kind of reasonable to polyfill.

• Safari extension contexts do have both chrome and browser globals, they should be basically aliases and the asynchronous API methods in both of them to be returning a Promise when a callback is not passed (while when there is a callback no promise is returned), and so at the moment this polyfill is likely turning itself into a noop as it does on Firefox, because the browser globals is already defined.

• As an additional side note: to officially support another browser, especially for a separate implementation like in this case, the integration tests in this repo should also run in that browser as part of the CI (which is another detail that I haven't digged into yet), it wouldn't be really "supported" without automated tests running on the CI.

About the support for the sendResponse, it does print a deprecation warning the first time that it is being used but we didn't remove it from this polyfill:

webextension-polyfill/src/browser-polyfill.js

Lines 377 to 386 in b0596ad

	let sendResponsePromise = new Promise(resolve => {
	wrappedSendResponse = function(response) {
	if (!loggedSendResponseDeprecationWarning) {
	console.warn(SEND_RESPONSE_DEPRECATION_WARNING, new Error().stack);
	loggedSendResponseDeprecationWarning = true;
	}
	didCallSendResponse = true;
	resolve(response);
	};
	});

And so as a short term workaround, sendResponse should work fine across the 3 implementation (Firefox, Safari and Chrome).

[Juraj-Masiar]

Thanks @rpl for the info!
I have a huge code base so there is no way I'm gonna refactor it from superior Promises to callbacks :)

But I guess I could write my own simple polyfill, something like this should work:

// if (IS_SAFARI) do this:
browser.runtime.onMessage.addListener = new Proxy(browser.runtime.onMessage.addListener, {
  apply: (addListener, thisArg, [handler]) => addListener.call(thisArg, (message, sender, sendResponse) => {
    const result = handler(message, sender, sendResponse);
    if (result instanceof Promise) {
      result.then(sendResponse);
      return true;
    }
    if (result === true) return true;
  })
});

EDIT: I've just tested it and it works. But I've edit it a bit to still support sendResponse function because there is some internal safari code that uses it and it didn't liked my exception :)

[bcomnes]

I've been looking into porting my addons to Safari but there is one crucial feature missing - the runtime.onMessage API in there doesn't support replying to the message by returning a Promise, only by calling the sendResponse function which I don't use because it's not recommended and it doesn't exists in this polyfill anymore.

Would implementing this feature for Safari be outside of scope for this polyfill?

I ran into this issue this weekend. Also, I noticed that safari did not fire events for browser.storage.onChanged.addListener when you try to browser.storage.local.set a storage key to a falsey value like null. You have to explicitly browser.storage.local.remove the key to trigger that event.

[ivanjeremic]

Wonder why there is no cross-browser extension framework yet on the market.

[Rob--W]

Wonder why there is no cross-browser extension framework yet on the market.

Years ago there was no cross-browser compatible API. These days we do, and the compatibility is going to improve even further by the recent launch of the WebExtensions Community Group - https://www.w3.org/community/webextensions/2021/06/04/forming-the-wecg/

[gangsthub]

Wonder why there is no cross-browser extension framework yet on the market.

+1000 on that.

I went to https://github.com/fregante/Awesome-WebExtensions hoping to find something new... and nope.

At least Chrome has now shiny new docs on Extensions: https://developer.chrome.com/docs/extensions/

[csandman]

Thanks @rpl for the info! I have a huge code base so there is no way I'm gonna refactor it from superior Promises to callbacks :)

But I guess I could write my own simple polyfill, something like this should work:

// if (IS_SAFARI) do this:
browser.runtime.onMessage.addListener = new Proxy(browser.runtime.onMessage.addListener, {
  apply: (addListener, thisArg, [handler]) => addListener.call(thisArg, (message, sender, sendResponse) => {
    const result = handler(message, sender, sendResponse);
    if (result instanceof Promise) {
      result.then(sendResponse);
      return true;
    }
    if (result === true) return true;
  })
});

EDIT: I've just tested it and it works. But I've edit it a bit to still support sendResponse function because there is some internal safari code that uses it and it didn't liked my exception :)

Do you have a consistent way of checking whether or not it is running in Safari in the code, for browser_action popups and background scripts?

[Juraj-Masiar]

Nope, but you can probably parse the value from the userAgent string.
I'm using Webpack to create separate package for each store (Firefox / Chrome / Safari / Thunderbird) and then webpack.DefinePlugin will simply replace these global placeholders. Although it's great that the placeholders are replaced before minification so the dead code is then dropped, it's terrible when you try to integrate existing code into different project that doesn't use Webpack. Also testing is problematic. I would probably used some different method if I turn back time :)

[csandman]

@Juraj-Masiar I also have a setup which is using webpack to make a build for each browser, any chance you could elaborate on how you added it using that? I'm using webextension-toolbox and I tried to write a custom webpack script for the safari build using it but couldn't quite get it working right.

[Juraj-Masiar]

Just look at the DefinePlugin for Webpack. It will replace all global variables with the specified name. For example this is what I use in the plugins array:

      new webpack.DefinePlugin({
        $IS_FIREFOX: IS_FIREFOX || IS_THUNDERBIRD,
        $NOT_FIREFOX: !IS_FIREFOX,
        $IS_THUNDERBIRD: IS_THUNDERBIRD,
        $IS_CHROME: IS_CHROME || IS_SAFARI,   // to make it simple, Safari will inherit existing Chrome codebase
        $IS_SAFARI: IS_SAFARI,
        $IS_EDGE: IS_EDGE,
        $IS_DEV: IS_DEV,
        $IS_PROD: IS_PROD,
        $IS_WEB: IS_WEB,
        $IS_EXT: !IS_WEB,
        $IS_NODE: IS_NODE,
        $IS_TEST: false,
      }),

But again, terrible testing, terrible inter-project integration.
It may be better to use some environment variables, even if it's at the cost of dead code not being removed from the final build.
Actually the more I think about it, the more I want to do it :D. Especially now when I have 100 other things to do :)

[csandman]

Do environment variables get loaded in a live browser extension?

[Juraj-Masiar]

I have no idea :). I use them only in the backend, but that's integrated in the Nestjs framework I use.
But I would say there must be something for Webpack because people want to environment variables during the build time and they for sure want to drop dead code. I remember I was not able to find it though, but it was years ago.

[fregante]

Do you have a consistent way of checking whether or not it is running in Safari in the code

This is a generic StackOverflow question, let's not notify everyone for unrelated requests 😅

• https://stackoverflow.com/a/23522755/288906
• https://github.com/fregante/webext-detect-page/blob/0f0a8ccef8f84203539322777e5eff9d1199f2f0/index.ts#L76-L77

[fregante]

Returning to topic, I've been using webextension-polyfill on Chrome, Firefox and Safari (same build) for a year, so no custom implementation is needed. If you want to build it for Firefox/Safari specifically, just don't include it.

This issue probably is just about official support and testing in the repo, but you don't necessarily have to wait for it, as a user.

[csandman]

This is a generic StackOverflow question, let's not notify everyone for unrelated requests 😅

Sorry about that 😓 the user agent checking works find for the popup but I still haven't been able to find a consistent way to determine which browser a background script is running in (besides the custom webpack scripts @Juraj-Masiar mentioned). That's the only reason I asked here.

[xeenon]

FYI, Safari does support Promise replies in onMessage listeners (for a couple years now) — since Safari 15.4 (Released 2022-03-14).

I think this issue can be closed.

[Rob--W]

FYI, Safari does support Promise replies in onMessage listeners (for a couple years now) — since Safari 15.4 (Released 2022-03-14).

I think this issue can be closed.

Thanks for checking. It is also listed in the BCD: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/Runtime/onMessage#browser_compatibility

(to those interested, Chrome also expressed interest in implementing Promise support in onMessage)