Inconsistency: path handling across APIs and browsers

[carlosjeurissen]

Current behaviour

The behaviour of paths across APIs and browsers currently is not unified.

For example:

browser.action.setIcon({
  path: 'images/icon.png'
});

Is handled relatively to the current extension URL in Firefox, while it is handled absolutely in Chrome.

In Safari it is always handled absolutely, and generally speaking in Google Chrome as well, while some APIs in Firefox, they are handled relatively. like the action.setIcon API and devtools.panels.create API as can be seen in #270. However, the notifications.create API sets them absolutely in Firefox as well.

Going forward

Preferably this path handling should be the same across browsers and APIs.

We should figure out the current path behaviour in Chrome and Firefox and see if there are any additional inconsistencies.

While allowing relative APIs gives additional ways of setting paths, developers can assume the path handling is the same as in manifest.json, in which case bugs are created.

So it seems to make the most sense to always handle them as absolute. However, this can give breaking changes which we want to delay to a new manifest version.

[erosman]

Please also note the inconsistency in resetting the icon to the default manifest icon.

In Firefox, action.setIcon() (or browserAction.setIcon()):

If each one of imageData and path is one of undefined, null or empty object:

• ...
• ...
• Otherwise, the global icon will be reset to the manifest icon.

browser.browserAction.setIcon({});

However, in Chrome action.setIcon()

Either the path or the imageData property must be specified.

chrome.action.setIcon({});

// Uncaught TypeError: Cannot read properties of undefined (reading 'setIcon')

Resetting in Chrome requires the path to the manifest icon e.g.

chrome.action.setIcon({path: '/path/icon.png'});