webextension-polyfill: Compatibility with environments that have the `browser` namespace but don't support promises

The Edge issue has been re-opened by Edge team…

Considering Microsoft’s track record of not following standards and their somewhat recent desire to not be like that anymore, it’s really weird that they’re so dismissive about this…

I guess supporting this in the polyfill would be the only solution for now 😦

What a sad state of affairs. It looks like Chrome doesn’t care about Mozilla’s WebExtensions standardization effort and Edge just (barely) follows whatever Chrome does. On top of that, Chrome’s original API is pretty ridiculous to begin with.

At this point I wish mozilla came up with a sound API and polyfilled that.

@rpl and I talked about this:

• We want to support Edge, with minimal efforts (i.e. no large changes).
• That is, a simple feature detection as shown in https://github.com/mozilla/webextension-polyfill/issues/3#issuecomment-259425339 (guarded on the existence of the Edge-specific msBrowser API).
• The (existing) browser object will be replaced with the polyfilled one, which uses the global chrome object to implement the polyfill.
• The polyfill should be tested (at least manually, ideally with continuous integration).

@Rob--W Sadly AppVeyor won’t support Microsoft Edge testing. All tests on AppVeyor run on Windows Server 2012/2016, but MS Edge doesn’t support Windows Server at all. So far the only option that I know is BrowserStack, which has free plan for open-source projects, but I guess it would take some time to set up Selenium.

I think we Edge users would be happy enough if Edge is supported on a best-effort basis. We don’t need any guarantee about non-breaking release because we understand the difficulty.

One of the big blockers is the ability to load an extension in Edge for automated testing (locally and on continuous integration, e.g. on AppVeyor).

If someone spends time on researching that, then I am willing to make the desired changes to the polyfill to support Edge.

Any ideas when this will be completed? I’ve seen multiple proposed pull requests and they always get shot down for some reason or another. It seems like a lot of “paralysis by over-analysis”. It’s been almost 2 years. Please implement something, even if it’s temporary and not your ideal solution.

At the moment, neither a working polyfill, nor any other cross browser solution exists. An unfortunate state of affairs, but we people of the web are used to this by now.

May I suggest some possible improvements:

1. Address idiosyncrasies of each browser vendor explicitly, based on the user agent, instead of the current approach.
2. Instead of polyfilling globals, export an object with Mozilla’s version of the API.

On point 1, I argue that it is more robust and simpler than attempting non-trivial feature detection, as in #43. The set of browsers currently supporting WebExtensions is known and the chances of your extension working in some other incarnation of the API without being explicitly targeted is slim.

On point 2, an anecdote.

I just had a fun time on a project that also uses pastak/chrome-browser-object-polyfill. That polyfill makes its own assumptions about the browser global. MetaMask/extensionizer makes different assumptions still.

A cross platform library is more useful to me as a developer than a polyfill that seals off all escape hatches by monkey patching globals.

Well, I presume it will still take a while until Microsoft Edge will support promises, and when it does extension developers might not be able to drop support for older versions of Microsoft Edge right away. Also what if Chrome (or a new platform) will start to provide the browser namespace but doesn’t support promises in the same step.

As for detecting the promise-based API, the best idea I have is just calling any asynchronous function and check whether it throws an exception (because a callback is expected) or whether a promise is returned.

if (typeof browser == "undefined")
  var browser = chrome;

var _supportsPromises = false;
try {
  _supportsPromises = browser.runtime.getPlatformInfo() instanceof Promise;
}
catch (e)
{
}

if (!_supportsPromises)
  browser = wrapAPI(browser);

TBH Microsoft announced that too early. Now nobody would develop against the classic MS Edge no matter when the new Edge come out. This is not the only project; there is also some discussion at EFForg/https-everywhere#5101.

There are many companies using Edge right now. It will take time for MS to release a Chromium based version and more time for companies to upgrade.

that’s pretty minor compared to using promises instead of callbacks