- Chair: Simeon Vincent
- Scribes: Rob Wu
Call-in details: https://lists.w3.org/Archives/Member/internal-webextensions/2021Jun/0000.html
Zoom issues? ping @robwu
(Rob Wu, Mozilla) in chat
Agenda: github issues
- Labels
- Issue 31: Adjust regular meeting schedule to accommodate the other side of the globe
- Publish a schedule
- Send reminders to internal list and matrix 2 days before
- Issue 13: Where do we start for a draft?
Issue 30: Set up Bikeshed spec pipeline
PR 36: Initial bikeshed file- Tess to review PR
- Issue 19: APIs and infrastructure to simplify cross-browser automated testing
- Issue 11: WebExtensionWorker instead of Service Worker
- (sign up here)
- Rob Wu (Mozilla)
- Simeon Vincent (Google)
- Luca Greco (Mozilla)
- Todd Schiller (PixieBrix)
- Nick McGuire (1Password)
- Oliver Dunk (1Password)
- Daniel Glazman (Dashlane)
- Tim Hatcher (Apple)
- Thierry Régagnon (Dashlane)
- Jon Howard (Easyfundraising)
- Bradley Cushing (Dashlane)
- Mukul Purohit (Microsoft)
- Pawel Wszola (OceanHero)
- Marwan Liani (Dashlane)
- Richard Worth (Capital One)
- Don Hopkins (Ground Up Software)
- Jack Works (Sujitech)
- Denis Schneider (Dashlane)
- Joshua Rampersad (1Password)
- Mélanie Chauvel (Dashlane)
- Michael Leggett (Simplify)
Introduction
- [simeon] Created “task” and “inconsistent” labels for issue tracker
- “Inconsistent” is to collect inconsistencies between platforms, for future discussion
Issue 31: Adjust regular meeting schedule to accommodate the other side of the globe
- [simeon] Current plan is to alternate between 8 AM and 11 PM PDT to cover all time zones. See issue tracker for more details (including what this means in your local time zone).
- [rob] We should publish a schedule with a list of upcoming future meetings.
Issue 13: Where do we start for a draft?
- [simeon] Issue 30: Set up Bikeshed spec pipeline
- PR 36: Initial bikeshed file
- [mukul] This is ready for review and needs sign-off
- [mukul] pasted in the chat link to the tools https://tabatkins.github.io/bikeshed/ and https://github.com/rtoy/auto-deploy-spec
- [hober] In response to modularization, the draft is currently empty and modularizing the draft spec is currently premature.
Issue 19: APIs and infrastructure to simplify cross-browser automated testing
- [mélanie] noted that the previous browser-ext group has already tried to write about testing in their draft: https://browserext.github.io/browserext/#wd
- [simeon] filed an issue in the chromedriver project
- [luca] At Mozilla we do run integration tests using selenium for the webextension-polyfill project (https://github.com/mozilla/webextension-polyfill)
- [timothy] At Apple we would also prefer using WebDriver as it has better cross-browser support
- [simeon] mentions https://w3c.github.io/webdriver-bidi/ as the nextgen webdriver standardization effort in the future. Early work, possibly years from now.
- [timothy] WebDriver is designed to drive the browser, the remote debugging protocol wasn’t designed for that.
- [Luca] reaching extension pages not opened in a tab is also a gap in current webdriver support (e.g. reaching a background page or a browserAction popup, as well as the less common devtools page and devtools panels)
- [simeon] Requests the community to comment on the issue about their experiences.
- [Todd] share existing experiments and know gaps with testing extension in the issue would also be useful
Issue 11: WebExtensionWorker instead of Service Worker
- [simeon] Initially (before there was an extension standardization effort), the Chrome team had concerns about the introduction of another concept separate from the existing web platform. Intentionally tried to minimize the gap and maintenance cost between the web platform and extension platform.
- [jack] Service worker and extension worker are not the same thing in practice. If you mix different things with the same concept, it leads to more confusion.
- [simeon] A common complaint that the Chrome team has received is about the maximum lifetime of 5 minutes of extension workers. We will likely not relax this constraint.
- [jack] it's acceptable to keep the event-based and timing limitation, but I think we really should not just copy the whole service worker cause it will bring many unreasonable thing into extension worker.
- [glazou] leads to critical issues with native messaging and parse time of large SW will lead to degraded UX
- [mélanie] removing background pages in favor of service workers results in the removal of many APIs, away from what web developers are familiar with. Asks for (opt-in) access to APIs.
- [simeon] Challenges with introducing capability of asking for specific access, e.g. fragmentation of APIs across devices.
- [timothy] References #25 (don't standardize around lowest common denominator platform). Because of these resource constraints, Safari for iOS required non-persistent background pages. Safari for desktop doesn’t have this constraint.
- [simeon] Challenges with introducing capability of asking for specific access, e.g. fragmentation of APIs across devices.
- [Rob] The original issue is about introducing an “extension” worker concept in order to expose extension-specific APIs/behavior to the extension worker. The discussion is now going in the direction of the apparent need for replacing background pages with Service Workers because of performance. Requiring service workers is not strictly necessary for that (e.g. Safari for iOS requires event pages).
- [simeon] Intends to address feature gaps / capabilities separately on a case by case basis.
- [timothy] recognizes that in the Web Audio case, the 5 minute limit may be impractical for extensions.
- [Jack] the only similarity between service worker and extension worker is the timing limit and the event-based model. They have different purposes and different sets of APIs. Using one name for two different things only creates confusion. And I guess in the implementor's code, they need to add many patches in the service worker code to make it fit the extension worker.
- [simeon] Intends to address feature gaps / capabilities separately on a case by case basis.
The next meeting will be on Thursday, July 22nd, 11 PM PDT (6 AM UTC). Following issue 31 we will alternate between the two time slots from now on.