Charter and administrivia for the WebExtensions Community Group (WECG)
License: Other
The charter of the WebExtensions Community Group (WECG).
🏅 Charter: https://github.com/w3c/webextensions/blob/main/charter.md
🌐 WECG at W3C: https://www.w3.org/community/webextensions/
📆 WECG calendar: https://www.w3.org/groups/cg/webextensions/calendar/
📝 Minutes of meetings: https://github.com/w3c/webextensions/tree/main/_minutes
💪 Contributing guidelines: CONTRIBUTING.md
The chrome.tabs.executeScript API (and also Chrome's proposed chrome.scripting.executeScript API) have an inherent design flaw (TOCTOU) that is not present with statically registered content scripts.
The executeScript API looks like this:
chrome.tabs.executeScript(tabId, {
frameId: ...,
file: "contentscript.js",
});
For script execution at runtime by the extension, the typical pattern is that an extension calls executeScript in response to an event related to a tab or frame (e.g. a navigation, network request or user interaction with an extension button). The problem with the executeScript API is that it only takes a tabId and frameId as an identifier. These IDs uniquely identify a frame (BrowsingContext), but not the document within the frame. Consequently, it's possible for a page to have been navigated and for the extension to inadvertently run a content script on an unexpected website.
This issue is not present with content_scripts in manifest.json (or APIs that register scripts in a declarative way such as browser.contentScripts.register), because the browser engine checks the URL right before injection.
There are multiple ways to mitigate this issue with executeScript, e.g. any of the following:
tabId + frameId + documentId), and allow extensions to pass this to executeScript (and potentially any API where this is relevant, beyond content scripts, e.g. extension messaging APIs).
documentId may not always be known when an extension uses this.history.pushState).Update captureVisibleTab() so it's not limited to the visible area.
https://developer.chrome.com/extensions/tabs#method-captureVisibleTab
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/tabs/captureVisibleTab
Firefox does support ImageDetails.rect to specify the area to capture.
There is a Chrome Feature Request from May 2010. And it is possible to take a full size screenshot from DevTools - using the Command Menu (Cmd + Shift + P) and selecting "Capture full size screenshot".
(My use-case: An extension that stops animations, an accessibility feature to help people reading. I simply take a screenshot of the page and overlay it, but I need to remove that screenshot when the user scrolls, and create a new screenshot after a short delay).
alarms api only support "1-minute timer" and may delay some time(e.g. 30 seconds). So this is not a precise timer, it cannot be used to do clock-like functions.
I suggest in manifest.json add a new "highPreciseAlarm" permission, that supply precise timer function.
This might be already on the table but I couldn't find it explicitly mentioned in the charter.
A large majority of extensions opt to rip out CSP headers completely[1]. They have to do this because extension scripts (like content scripts) are subject to CSP headers and so can be prevented from running by any website.
Browsers being user agents, I feel that extension permissions should not be influenced by website security headers. Conversely, I also do not think website security headers should have to be sacrificed for extension compatibility. I would like to see this community group come up with a model that preserves a websites security settings on one level, but allow extension content scripts to run as well.
[1] https://therecord.media/thousands-of-chrome-extensions-are-tampering-with-security-headers/
Both Firefox and Opera implements a mostly non-overlapping API under the sidebarAction namespace (agreeing on the sidebar_action key of the manifest.json).
Considering that most browsers don’t implement it, should this be described somehow, and considered part of the main spec while being optional, or an extension of it? Is two implementors sufficient to be considered something we want to describe, for interoperability purposes? Anyway, I guess it could be good to have guidelines for vendor-specific extensions of the WebExtensions API so that the whole stays coherent (and fit for a potential later standardization).
The previous community group had a section on manifest.json in their draft. I propose that we use it as a base to discuss what we want/don’t want for our own draft, or even copy (some part of) it if we feel like it’s appropriate.
For example, I’m not sure that the 5.4 The activeTab permission section has exactly its place in this section. Maybe we would like to describe permissions in another section entirely, especially since the list of permissions varies a lot and depend on API namespace available on each platform.
Keep in mind that the goal is to have some minimal, useful text in the spec, to start iterating on it. 🙂
Context/Background
Template engines (e.g., Mustache, Handlebars, Nunjucks, jq) are valuable for providing end-user customization without code.
However, template engines pose a security risk when used with user-defined templates (e.g., XSS and prototype pollution)
Request
Design Considerations
Prior Art:
sandbox: https://developer.chrome.com/docs/extensions/mv2/manifest/sandbox/sandbox: https://developer.chrome.com/docs/extensions/mv3/manifest/sandbox/user_scripts: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/user_scriptsRelated Information:
Extensions can override browser's default bookmarks, history and newtab pages. But they are opened in different ways on different browsers.
For example, on Chrome it opens bookmarks manager and history page in a new tab page, if extensions override them, you can assume it is a wide-width page for UI design. Recently, Edge browser changed this behavior, when you click or use shortcuts to open history, bookmarks pages, it no longer open in a new tab page, instead, it opens a very narrow pop-up page.
Some browsers open bookmarks/history/downloads/tabs on the left sidebar. These differences in behavior may affect the implementation of extension functions.
As suggested in #13, we should…
Once we have this, we can begin drafting drafting the discussing the manifest.json specification.
Context
With the growing ubiquity/importance of mobile, and the Safari team announcing support for mobile extensions. There's a need to account for the unique needs of the mobile form factor in the standardization process
Some efforts, e.g., moving the background processing to an ephemeral service worker, will have positive resource impacts on all platforms. And, if designed properly, will not be at the expense of functionality
In the first meeting, #23, @dotproto raised the idea of including stricter resource guarantees into the manifest to account for mobile
Request
Account for the unique needs of mobile (e.g., energy consumption), but do not constrain desktop extensions to meet those needs
Context
In practice, the extension manifest is a combination of 1) technical specification, 2) browser implementation quirks/bugs, 3) the technical limitations of the web store, and 4) the review policies of the web store
Examples:
3. The Firefox web store has a maximum file size of 4mb: mozilla/addons#662
4. For Manifest V3: the Chrome Web Store has a review policy that "Specifically, all logic must be included in the extension's package", but allows for "remote configuration files": https://developer.chrome.com/docs/extensions/mv3/intro/mv3-overview/#remotely-hosted-code
Request
When standardizing the "manifest", also consider any relevant web store factors — i.e., the "API" of the web stores
Web stores can/should be able to have different review policies, but aligning on standard terminology (e.g., "logic") would help simplify debate
Hello Folks,
I think we should discuss adding an issue template to help make sure the issues we accumulate here are in scope towards the discussions and the charter. We are mainly aiming to specify the current extensions landscape, and feature requests on top may end up being out of scope. Having an issue template may help reduce issues to triage, and direct participants to other venues where their request would be more helpful (Chrome's crx list, Mozilla's discourse, etc)
Would love to gather your thoughts on this and what we should include.
PR #61 introduces prose that more fully describes two manifest keys, name and short_name. The text for both of these keys tee up the topic of localization handling by stating "This property can be localized." The immediate question this phrasing raises is, "how?"
default_locale manifest keyRelated prior art to consider when specifying localization behavior includes:
Right now the i18n API lays the groundwork for some interesting language processing applications. It can detect the language of content on a page (or guess at it and provide a confidence rating), get the UI language of the browser, and allows developers to publish extensions in multiple supported languages by providing a locales/lang/messages.json file (among other things).
Users can also download individual language packs which are then added to that user's list of available languages to spell check in.
Problematically, it is impossible to remove or manage custom dictionary words (which are tied to the logged in browser profile and are not, as far as I know, specific to any one dictionary the user has installed). Users must manually edit the persdict.dat file (hidden away in the roaming data folder of the host machine) to be able to clear or edit custom dictionary words.
What's more is that despite some browser extensions being able to literally read/consume the content of any webpage (given the right permissions), an extension cannot see what custom words a user has saved nor is the native Hunspell spellchecker exposed.
The reason I point this out is that I do not believe being able to access a users custom dictionary list or the browser bundled spellchecker is somehow more invasive than an extension given permission to read the content of a web page the user is visiting, therefore this proposal would not introduce new or otherwise complex permissions that are foreign to the web extensions landscape or go against Mozilla's privacy first principles.
To rectify this I would propose adding a new "spellcheck" API permission scheme that exposes the native Hunspell/spellchecker instance.
The below updated permissions are based on the following spellcheck API extension proposals:
Something like:
spellcheck.MisspelledWord (Object)
currentSuggestion: string - the currently suggested word (default to word with closest proximity)suggestions: array - strings from 0 to N, 0 having the closest proximity, N having the least proximitymisspelledWord: string - the misspelled wordnode: object - contains the location of the misspelled word inside the input/textfield (so that we can draw over it)spellcheck.Options (Object)
limit: the maximum number of words to suggest for a misspelled wordSomething like:
spellcheck.onShowWordSuggestions - fired when a user asks to see misspelled word suggestionsspellcheck.onCycleWordSuggestions - fired when a user moves up or downspellcheck.onSelectWordSuggestion - fired when a user selects a wordSomething like:
spellcheck.getCurrentSuggestion(MisspelledWord)spellcheck.setDictionary(string) - a 4 character dictionary locale (i.e. en_GB, de_DE), set the currently in use dictionaryspellcheck.replaceWord(MispelledWord, string) - replace a misspelled word with a stringspellcheck.cycleSuggestedWordUp(MispelledWord) - cycle the suggested word up (updates MisspelledWord.currentSuggestion)spellcheck.cycleSuggestedWordDown(MispelledWord) - cycle the suggested word down (updates MisspelledWord.currentSuggestion)Similar to how the clipboard permission scheme works, the spellchecker could be updated to have a "write" permission too, which would allow an extension with the write permission to:
The read permission would be able to:
A nice side effect of setting up the permissions this way is that an extension without a contentScript permission, but with a read/write i18n permission, would not necessarily need or be able to read the textual content of a page (nor would any script need to be injected). By plugging into the native Hunspell instance an extension could, for example, listen for a misspelled word event/message (and do something) without having any idea what the surrounding content is, and without being able to read content of non-spellcheck-able fields, which allows for more fine tuned privacy controls.
For an example project (currently on hold) that demonstrates some of the above functionality, see here: https://grayedfox.github.io/multidict/
The above extension bundles nspell (a JavaScript wrapper of Hunspell) and it's own dictionaries (mostly clones of those available in the extension store) in order to achieve a much slower spell check. What's more each enabled dictionary eats up a lot of resources, and users must go into their settings and disable spell checking (to prevent the red squiggly underline appearing), and all of this just to be able to achieve the simple task of automatically changing what dictionary is used when spell checking and providing some customization of how to show misspelled words.
One thing I'm not too clear on is how to handle customization of a misspelled word's appearance. Being able to change the color of the squiggly line would be a great start (just use a HTML color picker and pass in a valid HEX color scheme).
A more advanced feature, which would vastly open up customization options, is allow extensions to provide a CSS object that could style misspelled words. As long as the CSS is valid, the browser could handle styling the words (and could even whitelist certain style options if needed).
As mentioned in issue #39 - Web development is no longer just dominated by JavaScript.
Whilst Typescript is a valid and viable alternative and easy enough to work with for extension development. It would be useful to enable / document how to provide the necessary bindings so that application developers using languages that offer a javascript as a build target can create web extensions in their language of choice. For instance Dart, Go, Python, Ruby etc.
Clicking the browser action icon gives the extension temporary access to the current tab
Browser Behavior Matrix
Reference
In order to get the organisational domain in an extension (rather than the sub-domain), it is currently required to download the list from publicsuffix.org and then write your own code to parse it and search it.
I believe browsers must already have this list installed and have a way of using it, so it would be great to open access to that to extensions.
Issues with the current approach include:
Right now, tabs.duplicate() as implemented by browsers (except Firefox) doesn’t permit to duplicate a tab at a given index and with a given active state.
For example, Chrome opens the duplicated tab after the tab it’s duplicating, and activate it. Right now, to duplicate a tab at a given place in the background in Chrome, it’s possible by saving the tabId of the active tab, duplicating the tab we want to duplicate, use chrome.tabs.move() to move the tab at the place we want, and make the previously active tab active again if needed with tabs.update(); however it’s a workaround that results in a bad user experience since it switches the focus two times and opens a tab somewhere and moving it immediately at another place.
Those sort of things should be able to do easily to empowers developers to implement innovative and useful add-ons, and extending the duplicate feature of browsers is one area where it’s harder than it should be.
I propose that browsers must implement a duplicateProperties options for tabs.duplicate() which allows the developer to ask for a specific index and active state. I implemented this on Firefox and it was easy to implement, and I don’t believe there’s any reason for that not to be a simple change for other implementors.
Here follows the definition of the function as implemented on Firefox’s side, for reference and compatibility purpose:
var duplicating = browser.tabs.duplicate(
tabId, // integer
duplicateProperties // optional object
)integer. The ID of the tab to be duplicated.
object. An object describing how the tab is duplicated. It contains the following properties:
integer. The position of the new tab in the window. The value is constrained to the range zero to the number of tabs in the window.boolean. Whether the tab becomes the active tab in the window. Does not affect whether the window is focused. Defaults to true.https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/duplicate
Currently, both Firefox and Chrome (not sure about the others) don’t report the favIconUrl as changed when a tab «loses its favicon».
«Losing its favicon» means that at some point the tab has a favicon (for ex., because the tab currently displays https://www.w3.org/), but then the tab loads a website that doesn’t have a favicon (for ex., https://example.net/).
Right now, it’s possible to workaround the issue by checking the third tab argument, but it defeats the purpose of the changeInfo argument while being counterintuitive and very easy to miss, especially since it’s undocumented. There is no good reason to not tell the developer that the favicon was updated.
See also:
I would like the specification to recommend the implementors to make the features available both through the WebExtensions API and the browser interface to follow the same defaults.
Examples:
Calling browser.tabs.create() (without arguments) should do exactly the same as a user clicking on the general «New Tab» button/hitting the general «New Tab» of their browser.
Calling browser.tabs.create({ url: "https://example.net/" }) (without defining the index) should do exactly the same as the user opening a link from another application.
Calling browser.tabs.duplicate(tabId) should duplicate the tab at the same place than it would if the user had called the browser duplicate feature on the tab with tabId through e.g. a contextual menu.
One place where standardisation of behaviour would be especially helpful is when trying to broadcast messages to all scripts in an extension.
To understand the problem, first it helps to understand the behaviour across browsers:
Messages sent using chrome.runtime.sendMessage do reach chrome-extension:// pages in an iframe.
From @dotproto in the Chromium Slack:
Yep, verified that this is the expected & intended behavior in Chrome.
Messages sent using chrome.runtime.sendMessage do not reach moz-extension:// pages in an iframe.
From @zombie in the Mozilla matrix:
in firefox, a moz-extension iframe in a web page only has content script level APIs, and as such receives only messages intended for content scripts, not for extension pages
This means it is hard (impossible without ports?) to broadcast messages to everywhere in an extension without duplicates.
Different options you might consider are:
Idea 1: Use chrome.runtime.sendMessage only
Problem: Iframes containing moz-extension:// pages will not receive the message
Idea 2: Use chrome.tabs.sendMessage only
Problem: Listeners in the background page will not receive the message
Idea 3: Use chrome.runtime.sendMessage and chrome.tabs.sendMessage
Problem: In Chrome, extension pages open in a tab of their own will receive duplicates
Idea 4: Use only chrome.runtime.sendMessage in Chrome and both in Firefox.
Problem: Normal content scripts will not receive the message in Chrome
Idea 5: Opening a port to the background from everywhere that wants to get broadcasts.
Problem: Introduces the requirement to track open ports in the background
With all of this considered, it feels like the ideal solution would be tweaking the behaviour of these so they are consistent. This would ideally be done in a way that supports the broadcast use case - not all behaviours meet this criteria. The other option would be introducing a new API that reliably broadcasts to absolutely everywhere that's listening.
Context
Chromium browsers support a externally_connectable manifest key that enables websites to message the extension directly and securely
However, the list of externally_connectable sites is static in the manifest. Therefore, the primary current use case is connecting to the website associated with the extension
As there are many non site-specific extensions, making the list of externally_connectable sites to be dynamic (similar to optional hosts) would allow deeper extensibility between sites and these extensions. In this world, browser extension authors could provide a companion JS library that website developers would use to make their site customizable/extensible via the browser extension
Request
externally_connectable in the web extension standardbrowser.permissions or a similar APIexternally_connectable, so that the extension can react even if it doesn't have the activeTab permission yet (E.g., by confirming that the user should see a permissions prompt to give access). Potential methods: an HTML meta tag, an JS API available to the external site, e.g., browsers.permissions.acceptExtensions(ids)References
document.defaultView.postMessage which requires access to the page to inject a content script: http://github.com/pixiebrix/pixiebrix-extension/blob/9acb556f36e5bf99d35daeb3dc1d77c0c9565287/src/contentScript/externalProtocol.ts#L191-L191A couple members of the chromium-extensions group commented in a thread about the creation of the WECG with concerns around the use of the term "WebExtensions." Given that these concerns directly apply to this group, I have migrated the relevant discussion into this issue.
Don't want to be too pedantic, but "WebExtensions" is a deprecated name for browser extensions, as far as I know. Unfortunately I couldn't find any source to support this statement.
The word we should consider using is https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions.
ilyaigpetrov - Sat, 5 Jun 2021 21:15:58 -0700 (PDT)
I kind of agree with that. The term WebExtensions is misleading. It implies that what's being extended is the Web or Web technologies, when in fact is an extension to the browser's functionality.
Or in more purist terms, it's just a Web application with additional privileges. Kind of like a Progressive Web App with privileges.
hrg... @gmail.com - Sun, 6 Jun 2021 12:27:01 -0700 (PDT)
One of the problems we faced at Dashlane is dealing with frameIDs. It's currently super tricky to associate a frameID to a given <iframe> element and it's even too complicated to retrieve a frameID at all since the only existing way to do that ATM is to send a message, from the inner context to that iframe, to the background, collect the frameID there and send it back to the origin iframe.
I think there should be an easy way to retrieve a frameID for a given iframe element, from the enclosing context of that iframe element. Similarly, from the JS context inside an iframe, there should be an easy way to retrieve the current frameID without having to ping-pong the background.
Web development is no longer just dominated by JavaScript with the emergence of more WebAssembly runtime and framework.
There are certain limitations when it comes to using WebAssembly to develop an extension, such as longer load time and bigger package size.
With this in mind, decisions such as deprecating persistent background in favour of service worker needs to be reconsidered because if the extension has a fresh start for every event, we will face similar issue of having "cold start" in serverless applications. I have been using Blazor to develop extensions and generally the pages take about 3 seconds to startup. I haven't been developing more advanced scenarios so that is all I can think of so far.
Manifest v3 introduces some security improvements which are great for consumers. They reduce the risk that an extension installed from the store will harm the user. This is great as most users lack the knowledge and tools to assess the security level of an extension they install from the store.
On the contrary, in an enterprise use case, the Manifest v3 changes limit the functionality of existing extensions. There are many use cases where an extension requires elevated permissions. For example, extensions used for QA, security or digital adoption.
In the enterprise world, extensions are pushed to the end users using an IT policy (either from the store or from a self-hosted location) and the extensions usually go through a security review before being pushed.
Therefore we suggest treating extensions installed manually from the store differently than extensions force-installed.
This is already the case for the blocking version of the webRequest API (https://developer.chrome.com/docs/extensions/mv3/intro/mv3-migration/#when-use-blocking-webrequest) so it appears that our line of thought is in the right direction.
As a general rule, we suggest that any security related restriction in the extension would be excluded from force-installed extensions, or at least there would be a discussion about it.
More specifically, our ask is to allow us to load remotely hosted code into a website's page when using force-installed extensions. We believe this has much use in enterprise use cases.
Context: last meeting, we discussed issue #11, I invite you to read the meeting notes about it. I’m writing here my proposal more formally, so that it can be properly discussed.
One of the most disruptive change of the MV3 is to request ServiceWorkers (SW), with a limited lifetime, instead of a (possibly persistent) background page. I believe this will cause more deviation from standard web development:
The idea behind my proposal is to give the capability to WebExtensions to be persistent if they need it, with an additional permission in manifest.json. This doesn’t rule out the possibility of default to and encouraging the use of SW, and leave the possibility to only allow this capability on desktop. The stores distributing the extensions could also warn that an extension can stay permanently in the background.
As noted in the charter, there was a previous effort to standardize extensions in the Browser Extension CG, which stalled for lack of engagement.
Though nothing has happened there for years, I'm still the chair of that CG. That doesn't mean a whole lot given that there isn't an active community there anymore, but I still have control over the CG's github repositories and its publications under github.io (Browser Extension spec, Native Messenging spec, meeting minutes…), as well as its twitter account.
Assuming this new attempt gets traction (I very much hope it does), I think it's worth thinking about whether this new CG wants to take over those assets, or if they should stay largely as is as a reflection of the prior attempt, but possibly with explicit pointers to where the new work is happening. Maybe we want to officially close the old group (instead of being permanently dormant), or maybe instead of creating this new group, the activity should be used to resurrect the old one? Relatedly, the old group has mailing lists. Should they be reused? Closed?
I'm in no way trying to challenge the creation of the new group or wrestle control. Just offering cooperation to ensure, if desired, smooth transition of the old assets.
Context
The availability of the permissions.request API in developer tool pages is implemented inconsistently across Firefox and Chrome
Browser status:
Reference:
This is related to #44, #11, #25, #39 and #73.
Service Worker-based extensions are Event Pages (persistent: false background pages) made mandatory and with additionally degraded capabilities. Some extensions fit the non-persistent/ephemeral model well. Many do not. Requiring all extensions to become non-persistent appears to be a fundamentally extension developer and user hostile requirement. It violates "user-centered", "compatibility", "performance" and "maintainability" design principles.
The downsides of Service Workers-based extensions include higher development1 and debugging2 complexity, worse performance3, and missing features (no DOM!). The third point in particular gates innovation behind browser developers. Working on an idea that requires Web APIs not supported in SWs4? Now at minimum you have to get Chromium and Firefox on board.
Consider also that there are still unaddressed showstopper bugs5 as well as inexplicable functionality gaps (such as #93) with SW-based extensions in Chrome.
Background pages will be replaced by background service workers (bug 1578286). This is a substantial change and will continue to be developed over the next few months. We will make a new announcement once we have something that can be tested in Nightly.
What are the benefits of Service Worker-based extensions for extension developers? Is any public discussion available from the Mozilla side?
[1] See crbug 1185226 where a whole new, otherwise unnecessary storage API is created in an attempt to fill some of the egregious gaps in the ephemeral model. Also see crbug 1128240 that proposes headless windows (something you already get by default in MV2).
[2] Examples: degraded browser UX, missing tooling.
[3] An overview of the inherent performance problem, see also this crbug with further discussion.
[4] Examples: playing audio, using the clipboard, communicating via WebRTC data channels. In short, everything in Window and Document that's not also in WorkerGlobalScope.
[5] Examples:
should we document browser_action and page_action or document the Manifest v3 action
Add some prose for the name and short_name manifest keys.
This week the group's chairs received an email announcing that W3C has begun organizing TPAC 2021. Like last year, this will be a completely remote event. The following comes from the announcement email.
TPAC 2021 will be virtual, and will be held from 18 to 29 October.
*The week from 25 to 29 October will be dedicated to the Joint and Group
meetings.*
The format we propose focuses on collaborative meetings that bring together the community
and create momentum and brainstorming.
Full details on this event can be found at https://www.w3.org/wiki/TPAC/2021/GroupMeetings. Guidance on the role TPAC serves and recommendations for participation can be found at https://www.w3.org/Guide/meetings/tpac.html.
This is a good opportunity for us to publicise our CG and to begin collaborating with other with other groups relevant to our work. Let's use this issue to begin identifying the groups we want to reach out to, topics we want to discuss, conversations we'd like to organize, etc.
One important API that is not currently available in all browsers is browserAction.openPopup, which provides a way to programatically open the popup associated with an extension. It would be great if through discussion here we could encourage adoption and also standardise some behaviour that works for as many use cases as possible.
We've wanted this many times over the years at 1Password and continue to encounter situations where it would be useful. Examples include:
There is clearly an understanding that this a useful API, even among browser vendors. In Chrome, it has previously been made available for the Google Cast extension to show a device list.
Firefox has implemented this API, but unfortunately the way it has been implemented does not work for us. As mentioned on MDN, "you can only call this function from inside the handler for a user action.". The thinking here makes sense, but unfortunately, user actions like clicking a button get lost if a message is sent to the background page. Ideally the browser would preserve the action across boundaries or allow us to call this API directly from a content script.
Tracking issues:
As discussed in our 2021-08-05 meeting, we should decompose the manifest.json specification work in allow group members to work in parallel on the spec.
Duringour 2021-06-24 meeting we briefly discussed the fact that our current meeting schedule takes place during the middle of the night for people living in in timezones between +7 UTC and -9 UTC.
In order to accommodate people in these timezones, the suggestion was put forward that we alternate between the current recurring meeting time (8 AM Pacific) and another time.
If possible, I would like the chairs and editors to be able to attend both meetings. Chairs are in PDT/PST while the editors are in CEST and IST. Given this, it looks like our best (only?) option may be 11 PM Pacific.
There is a need for web pages to proactively trigger access to services provided by a web extension.
Security: the web page and web extension need to communicate with one another in such a way that communication cannot be eavesdropped.
Privacy: the extension must not have access to anything on the web page. The web page must not have access to anything on the extension not explicitly provided by the extension.
Right now, it appears that the native extension mechanism where the browser spawns a separate process and communicates via stdin/stdout fits the security and privacy criteria, but not performance, as this represents just one communication channel, and thus forces an extra background.js proxy. A unix domain socket style approach would have been better, but I recognise this ship might have sailed.
It also appears that the browser.runtime.connectNative() function (and friends) fits the criteria when called from a background script, but given that browser.runtime.connectNative() can only be called from a background script, this does not meet the performance criteria when the background script is being an unnecessary proxy.
The browser.runtime.connect() function fits the security and privacy criteria, but not the performance criteria, as it requires one suboptimal proxy (background) on Chrome derivatives, and one suboptimal and one useless proxy (background and content) on Firefox. Safari behaviour is undocumented.
The externally_connectable option in Chrome allows a webpage to communicate securely and privately with a background script. This appears to not be supported in Firefox with no obvious plans to do so https://bugzilla.mozilla.org/show_bug.cgi?id=1319168. Safari is undocumented, but Apple did confirm lack of support in a discussion thread https://developer.apple.com/forums/thread/675091. The externally_connectable is crippled currently as the extension is forced to limit the functionality to known domains only, which breaks privacy.
The externalFunction() call in Firefox offers a mechanism for a webpage to communicate with a web extension, but meets none of the criteria as this requires that the extension inject a content script into all pages, compromising security and privacy, and being a useless proxy (content script).
The goal of this ticket is to:
I don't know if this repo is going to standardize Manifest V3 but I think I can post it here.
Currently, in Manifest V3, the background worker is reusing the Service Worker, which is a very bad reuse. It inherits many restrictions of the Service Worker which does not make sense to the Web Extension background worker. Here is a list of examples:
I propose to add a new Worker type like ServiceWorker, WebExtensionWorker. Thus we can gain the following benefits:
[Expose]Lots of users need synchronization features. Although the browser has built-in support, the behavior is very different. This is a trouble for developers and users.
Do you know / can recommend tools that would help to check if particular API is in all major browsers?
Just like https://caniuse.com/
Or a checking library, that will tell during build that that feature is not supported by particular browser.
We need to discuss where we should start documenting a spec draft.
manifest.json format or other another area of the common core of APIs?We would like to see specified in our future draft what exactly happens when a message is sent from content to a MV3 ServiceWorker but the SW is shutdown before it could reply back to the sender of the message. As far as we understand, this can happen if the SW has been alive more than 5 minutes and the fact messages are being received/pending is not interrupting that process. More specifically:
browserAction.setTitle() on Edge browser has a compatibility issue. It appends , ${badge_text} to title if the badge text is not empty. For example, if you set the badge text to "badge", and set title to "title", then the real title is "title, badge" on Edge browser.
It’s an unnecessary, smarty-pants behavior, and breaks compatibility. If developers want to set like that, they can set by themself. But Edge force to add badge text to title, developers have no way to remove them and can't show the same title on different browsers.
PS: If there is a issue on Chrome, I will report it to https://bugs.chromium.org/ . But I don't know where to report bug to Microsoft Edge.
When I follow the link to join, I get an error:
But I could join from these links:
An issue hit by all WebExtension vendors is related to manifest properties unrecognized by a given browser. A good example is browser_specific_settings that Firefox relies on but Chrome does not accept at all, triggering a manifest error on install. This forces all of us to have two different manifests or dynamically generate them or even have two different builds.
I think we could/should specify two things wrt manifest:
chrome.runtime.getManifest()Is this an attempt to force everybody to implement the controversial Manifest V3 and kill off ad blockers such as uBlock Origin?
Context
Automated testing tools, e.g., Selenium, Cypress, Puppeteer, and Playwright are invaluable for cross browser web application testing. There's limited support for them for testing browser extensions
There are mocks (e.g,. jest-chrome) for unit testing, but these don't capture the complexity of extension communication and browser quirks
Automated cross-browser testing will be valuable for checking the progress of the browsers vs. this w3c group's proposals.
Request
I don't have a clear recommendation for what's needed here. My goal is to get the conversation kicked off (with people more knowledgable than me!) On the PixieBrix project, we're just now trying to set up our cross-browser browser automated testing infrastructure
I suspect there's needs to be some mix of:
Related context:
In #31 we introduced a second time slot, to alternate between 8 AM PDT (3 PM UTC) and 11 PM PDT (6 AM UTC), to enable more people to join.
Although not everyone signs in, we do have some stats on the number of participants and two surveys with time preferences:
The 8 AM PDT (3 PM UTC) time slot is more popular than the 11 PM PDT (6 AM UTC) time slot, so it may make sense to increase the frequency of the former at the expense of the latter.
The schedule of the biweekly meeting is currently as follows, and alternates between the two:
We could replace one 11 PM slot with a 8 AM slot:
If one out of four is too infrequent, then the following alternative may also work:
Please comment and share your preferences.
Per this discussion in #13, we should expand the contributing guide to include more specific details on how we use our communication channels and our meeting schedule.
- Issues for specific topic and long-running conversations.
- Conference calls to discuss topics that require higher bandwidth conversations than issues typically allow
- Matrix for general chat, quick questions, pings, etc. We may ask participants to open issues here for tracking purposes.
In the past, Chrome supports another type of extensions - Chrome apps, a special web apps distributed through Chrome Web Store. It was deprecated and will stop supporting. One reason for abandoning is that it uses a lot of proprietary APIs instead of web standard APIs. Its successor is PWA, standardized by Web Applications Working Group.
Although Chrome apps is deprecated, but Web apps are highly anticipated by developers. Currently, distributing web apps is a very fragmented experience:
Web extensions can also be considered as a way to distribute Web apps. For example, packaging a web app as a web extension, when users click the extension icon, launch the web app. But this form seems to lack some of the features of a native app or PWA, and users don’t feel comfortable using it.
So I hope browser's extension store can better support web app, including functions and distribution.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.