Inconsistency: Streamline homepage_url, author and developer keys

[carlosjeurissen]

How browsers deal with the homepage, developer and author info seems to differ greatly.

Author and developer name

First, there is the author info, defined either with the author key or developer.name.
author is supported in Chrome, Firefox, Edge, Naver Whale, Safari, but not in Opera. Even tho MDN states it's supported: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/author

Then we have developer.name which is only supported in Opera and Firefox. Firefox supports both author and developer.name; if both are defined, developer.name is preferred by the Firefox.

Homepage and developer URL

Next we have the website URLs. We have homepage_url and developer.url. Interestingly enough homepage_url is supported everywhere. While developer.url is only supported in Firefox and Opera.

However, when both are defined, Firefox prefers developer.url while Opera prefers homepage_url. Potentially because Opera sees one URL as product URL, while the other is seen as developer URL.

Summary and proposal

Ideally we would have one URL for the product, and a separate one for the publisher, and lastly a publisher name. Everything else could sit in a readme or something else. Practically speaking the homepage_url could be kept for the product. And for the publisher, we can use the object notation currently used for developer. We can then either keep it under developer, or create a new key publisher. This could also make it easier to get rid of the inconvenient override by developer.url on Firefox.

[Rob--W]

@xeenon This came up recently in mdn/content#34715

What does Safari expect or support in the author key? I summarized Chrome and Firefox's current behavior at mdn/content#34715 (comment)

[xeenon]

@Rob--W Safari does not parse or use author.

[carlosjeurissen]

Chrome seems to have introduced author as an object with just one key being "email" in mv3. Interestingly enough it seems both Chrome and the Chrome Web Store do not throw a warning or an error with extensions having their manifest author value set to a string.

It seems to requires author.email to be equal to the publisher of the extension on the Chrome Web Store. I would guess this is currently not enforced and would suggest it to be not enforced to protect the Google account publishing the extension from being hacked. The publisher email is also bound to be changed and thus would break this logic.

Added needs-triage as we never discussed how we want to proceed with this.