Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Make extension APIs browser neutral #113

Open
carlosjeurissen opened this issue Oct 20, 2021 · 10 comments
Open

Proposal: Make extension APIs browser neutral #113

carlosjeurissen opened this issue Oct 20, 2021 · 10 comments
Labels
documentation Improvements or additions to documentation implemented: safari Implemented in Safari inconsistency Inconsistent behavior across browsers proposal Proposal for a change or new feature supportive: firefox Supportive from Firefox supportive: safari Supportive from Safari

Comments

@carlosjeurissen
Copy link
Contributor

carlosjeurissen commented Oct 20, 2021

Currently several aspects of the webExtension platform reference specific browsers. This should be streamlined across all browsers.

Examples are:

  • the main API namespace. Google Chrome uses chrome while Mozilla Firefox, the old Microsoft Edge and Safari also support the browser-neutral browser. A request to also support browser in Google Chrome has been filed here: CrBug 798169
  • The chrome_settings_overrides manifest property could be replaced with the neutral browser_settings_overrides
  • The chrome_url_overrides manifest property could be replaced with the neutral browser_url_overrides
  • The omnibox API, mentioned here Proposal: Make extension APIs browser neutral #113 (comment)
  • incognito manifest property

Let me know if I'm missing any of them.

@xeenon
Copy link
Collaborator

xeenon commented Oct 25, 2021

The omnibox API is another example that should have a browser-neutral name.

@xeenon xeenon added documentation Improvements or additions to documentation inconsistency Inconsistent behavior across browsers and removed documentation Improvements or additions to documentation labels Oct 25, 2021
@carlosjeurissen
Copy link
Contributor Author

Added both omnibox and incognito. Seems private is more common in the browser market.

What about devtools_page?

@tophf
Copy link

tophf commented Mar 9, 2022

FWIW, chrome was a term for UI internals aka "browser chrome" (coined by Mozilla, probably) and Google used this term as a reverse joke, so I never considered chrome to mean the name of a particular browser.

@dotproto
Copy link
Member

Anecdotally, the oldest concrete references I've been able to find for "chrome" in the GUI sense are Jargon File v2.1.1 (1990) and Netscape Navigator's source (Mozilla FTP, GH mirror) (1995-1998?).

@js-choi
Copy link

js-choi commented Mar 31, 2022

Whether chrome is a browser-neutral term, it would be good for interoperability to harmonize the naming of the chrome/browser object between implementations.

@xeenon
Copy link
Collaborator

xeenon commented Aug 18, 2022

Safari already supports browser_url_overrides as a synonym along with a browser_specific_settings in the manifest. Same for browser as the namespace JS object.

@abitrolly
Copy link

So, chrome API is the namespace that mixes cross-browser API with Chrome API.
browser is the namespace that is used by Firefox, but so far is it not clear if it is cross-browser or Firefox specific (because there is no common test suite).

So what should the namespace be?

Maybe
from manifest.v3 import ...
or
from browserapi/v2 import ...
?

@xeenon
Copy link
Collaborator

xeenon commented Sep 27, 2023

Safari implements both chrome and browser with promises or callbacks in either namespace. This is compatible with Firefox's browser namespace, so it is cross-browser.

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

@Rob--W
Copy link
Member

Rob--W commented Sep 30, 2023

I have published the meeting notes where the adoption of browser in Chrome was discussed.

I have also posted a comment on the crbug to cross-link this information in the WECG, at https://bugs.chromium.org/p/chromium/issues/detail?id=798169#c10

@patrickkettner
Copy link
Contributor

with the merging of #508, Chrome should be able to initiate the work to support the browser namespace

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation implemented: safari Implemented in Safari inconsistency Inconsistent behavior across browsers proposal Proposal for a change or new feature supportive: firefox Supportive from Firefox supportive: safari Supportive from Safari
Projects
None yet
Development

No branches or pull requests

8 participants