Can I use it already?

[abitrolly]

I just need to write an extension for Firefox and Chrome. Very simple. Without polyfills, webpack and stuff. Because stuff and those two makes it very complicated. I spent few days reading things. Growing restless.

Saw https://www.w3.org/community/browserext/ and got very confused that there is now https://www.w3.org/community/webextensions/ What is the reason? The previous group at least has some artifacts, and here I see only meeting minutes.

I want to use ES6 module to write my extension, and also want to reuse ES6 libs, but that's not the question I have. That's just for you to take notice that people are using webpack and stuff, because they want libs, and that makes the process complicated.

Anyway, good sirs, ladies and those in between, above and beyond, as well as those who finds themselves in other different states. My question is, do you have:

1. a tree list of API to see what API is specific to browser extension and what can I use?
2. isolated namespace for the API that is unreachable to plain JS? (I guess browser is it, but I am not sure)
3. people from Chromium to comment why they don't want to support the browser API
4. API versioning to deprecate the old stuff as the evolution moves
5. popularity score of API items based on analysis of popular extensions
6. UX/UI design for docs to guide people through evolution of specific API items (design, test, release, errata, remove)
7. 7th point on your agenda and what it is?

That's basically all I have to ask. I believe that having browser (that potentially polluted by some non-standard stuff) and chrome (that potentially have a lot of Google specific stuff) namespaces, is the main block. I can not prove it, just the feeling.

Wishing you pleasant days and effortless conflict resolutions.

[bershanskiy]

Unfortunately, almost none of the technologies discussed here are specified (in fact, there is no specification and technically CG can not publish a specification, GC can publish a report as a sort of recommendation to browser vendors to implement something).

What is the reason? The previous group at least has some artifacts, and here I see only meeting minutes.

The old group is no longer active (it ceased all activity nearly four years ago) explicitly naming this CG as a successor.[1]
[1] https://github.com/browserext/browserext

a tree list of API to see what API is specific to browser extension and what can I use?

For Chromium-based browsers alone see Chrome Developers (Google Chrome, the new Microsoft Edge, Vivaldi, Brave, etc.) https://developer.chrome.com/docs/extensions/reference/
For Firefox and Safari and Chromium-based browsers, see this gargantuan page of tables: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Browser_support_for_JavaScript_APIs

isolated namespace for the API that is unreachable to plain JS? (I guess browser is it, but I am not sure)

Not sure what you mean. The Background contexts and extension UIs are completely isolated, while extension iframes embedded into pages and Content Scripts have varying degrees of isolation from the "main-world" JS.

people from Chromium to comment why they don't want to support the browser API

Not sure this is very constructive.

API versioning to deprecate the old stuff as the evolution moves

WebExtensions are notoriously lacking in this regard.

popularity score of API items based on analysis of popular extensions

I am not aware of any such analysis. I saw a few services attempting to assess safety/security of extensions, like crxcavator.io but none seem very advanced.

UX/UI design for docs to guide people through evolution of specific API items (design, test, release, errata, remove)

There is no formal specification document at the moment, but one is being prepared in the mean time.

7th point on your agenda and what it is?

Which agenda are you referring to specifically?

Hope that was (somewhat) helpful.

[fregante]

people from Chromium to comment why they don't want to support the browser API

Not sure this is very constructive.

Hmm I think it's an honest question. This is a place where browser vendors supposedly come to have a shared API.

[tophf]

The term chrome is quite an ancient term coined by Mozilla, IIRC. It means the browser's UI layer, and it predates Google Chrome, which was named as a pun on that term.

[fregante]

Sounds great, I'm aware that Firefox uses the word "chrome" in a few places, but why are other browsers not using chrome.* if that's the meaning of the term in this API? Why don't all converge?

[tophf]

Firefox chose browser because their implementation was Promise-based while chrome was callback-based (ManifestV2). I don't see any reason to use browser in ManifestV3. Firefox's source code still uses chrome a lot, by the way.

[xeenon]

For the record, Safari implements both chrome and browser with promises or callbacks in either namespace.

The historical origin of the "chrome" term in browsers aside, it is now widely associated with the specific capital C "Chrome" browser.

There were some TPAC discussions around this, and I believe the Chrome team was onboard with supporting browser for consistency and testing.

Overall we should strive for browser neutral naming in this group.

[xeenon]

Browser neutral naming is tracked by issue #113, so we should discuss there on that topic.

[xeenon]

Going to close this, since #113 tracks the main issue this originator had, and @bershanskiy addressed the rest. Please open individual issues in the future for anything else.

[abitrolly]

The old group is no longer active (it ceased all activity nearly four years ago) explicitly naming this CG as a successor.[1]
[1] https://github.com/browserext/browserext

Why it was impossible to join the previous group to make it active? The duality looks like xkcd 927 standards.

Not sure what you mean. The Background contexts and extension UIs are completely isolated, while extension iframes embedded into pages and Content Scripts have varying degrees of isolation from the "main-world" JS.

Now I know there are more that just "extension API", but there are several APIs with different degree of isolation. This picture - blocks of different APIs - should be the entrypoint in extensions docs, but that requires clearly defined namespace first.

3. people from Chromium to comment why they don't want to support the browser API
   Not sure this is very constructive.

Let's make it constructive. browser. API is promise based. But Chrome adds support for promises too. Does Chrome injects promise based API into chrome.*?

Does browser.* API has a test suite for different browsers? I guess no. Does this group has an agenda to develop one?

Maybe the APIs are still converging, but it is not visible from outside. Because there is no "tree list of API" and test suite, it is impossible to track the progress.

Also I want to know if Chromium developers feel that API choices in several browser.* API calls are suboptimal? And that could be the reason to invent own wheels.

The unified tree of APIs won't replace UI like https://caniuse.com/ which is essential for people to see the progress and join to participate, instead using both Chrome docs and MDN docs and compare if they work the same.

To me the progress metrics is more important that specification document that is being prepared. The previous group already had the specification, but that didn't help. In general https://caniuse.com/ is a good example how to divide and conquer complicated task and onboard new people. At least it set my expectations high.

Sounds great, I'm aware that Firefox uses the word "chrome" in a few places, but why are other browsers not using chrome.* if that's the meaning of the term in this API? Why don't all converge?

Until reading this thread, I thought that chrome.* is Chrome specific API, and even knowing that Firefox implements it, I still think that chrome.* namespace is full of Chrome specific experiments and details that are easy come and easy go. Maybe Chromium people need this namespace to be that flexible for evolution be experiment?

[xeenon]

Testing is tracked by #441.

[abitrolly]

Still no answer why create new group instead of making old one active.

[xeenon]

See #1.