Extend roadmap: web extensions

[sadym-chromium]

#403

[sadym-chromium]

TODO: split in load and debug

[mnoorenberghe]

Support for loading unsigned web extensions would be super helpful for extension developers (e.g. as part of continuous integration, especially since Chrome Web Store doesn't provide an API to download a signed .crx). Can we be explicit about whether this is for signed vs. unsigned extensions?

[whimboo]

@sadym-chromium when you split this pull request maybe you can file an issue as well so that we can discuss how loading of an extension should actually happen? People would like to see definitions via capabilities so that no custom code needs to be added to tests. But additional caps would be required to control temporary installation, private browsing mode etc. See mozilla/geckodriver#1476 (comment) for more details around geckodriver. A non vendor prefixed capability is probably better.

[sadym-chromium]

• Web Extensions: install / uninstall #548
• Web Extensions: access background page #549

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed Web Extensions testing.

The full IRC log of that discussion

<AutomatedTester> Topic: Web Extensions testing
<shs96c> ScribeNick: shs96c
<orkon> q+
<jgraham> q+
<jgraham> ack orkon
<shs96c> orkon: we support limited extension testing. For install and remove, for Chrome it is only done in capabilities. The Web Extensions group tell us this is difficult to change in chromium.
<shs96c> orkon: is there some cross-browser agreement we can have on how to install an extension
<whimboo> i don't see an issue. probably we can file one and then attach the log in there afterward
<shs96c> ack next
<shs96c> jgraham: the thing that happened earlier in the week, the web extensions CG's goal is to incorporate web extensions into WPT, where each test will be its own extension. The API they're looking for is `install extension` and `remove extension` without needing to restart the browser every time. They may want more (eg. activate and de-activate extensions), but the main thing is being able to install extensions at run time,
<shs96c> jgraham: this would be useful for Mozilla.
<shs96c> jgraham: I think there are use cases for things other than the extension just lasting the lifetime of the browser.
<whimboo> request for geckodriver and WebDriver classic: https://github.com/mozilla/geckodriver/issues/1476
<shs96c> orkon: was told that installing extensions at run time was "practically impossible"
<shs96c> q+
<shs96c> ack next
<shs96c> shs96c: do we want to make this a problem for the web extension CG to solve using a webdriver bidi extension?
<whimboo> q+
<shs96c> orkon: perhaps, yes
<shs96c> ack next
<shs96c> whimboo: in geckodriver we can install an extension at runtime. Can even do this in private browsing mode.
<jgraham> q+
<shs96c> whimboo: the goal is to avoid changing the payload of the test per browser
<shs96c> whimboo: the most important short-term goal is to be able to install extensions at `new session` time by having a standardised capability containing the extensions we want to install. Both Firefox and Chromium have support for this.
<shs96c> jgraham: do we think ignoring the web extensions cg stuff, do we have use cases in firefox that require us to install and remove extensions at run time
<shs96c> q+
<shs96c> whimboo: probably not
<shs96c> whimboo: I can imagine that extension authors might want to test the `install` and `unload` scripts are being correctly called
<shs96c> ack next
<shs96c> ack next
<orkon> ScribeNick: orkon
<orkon> shs96c: I remember from the Selenium project what SauceLabs has said: being able to install extensions at runtime is really useful because it allows having the browser ready to go and then users amend it with extensions at runtime
<whimboo> q+
<orkon> shs96c: it is debatable if the time is any different but looks like it's use case
<shs96c> ScribeNick: shs96c
<sadym> I created an issue: https://github.com//issues/548
<shs96c> ack next
<shs96c> whimboo: whenever people want to test extensions, enabling and disabling is useful. It would still be good to have extension installation at runtime
<shs96c> q?
<shs96c> jgraham: summarising. There seems to be a general appetite for a capability for installing extensions at start up time, and that's something we can standardise. Runtime seems more of a requirement of the Web Extensions CG. The CG cannot write web standards, so for practical reasons it might be easier for us to write the standard, but they could also specify a non-standard track document which specifies the whole thing
<orkon> sgtm
<shs96c> shs96c: Is anyone opposed to us adding that capability ourselves?
<shs96c> Zakim (IRC): I've filed issue 548 for this
<orkon> q+
<jgraham> github: https://github.com//pull/421
<whimboo> shs96c: shs96c: fyi it's sadym (IRC)
<shs96c> q?
<shs96c> ack next
<whimboo> s/Zakim (IRC): I've filed issue 548 for this/sadym (IRC): I've filed issue 548 for this
<shs96c> orkon: imagine an extension is there, and it has background pages and popups. Do we need to change anything in the spec to make this work? I'm not sure all the extension contexts are the same as the regular browser contexts. Does anyone see any blockers in the current spec for working with extension contexts? We may need some special types to differentiate them
<shs96c> q?
<orkon> q+
<shs96c> ack next
<jgraham> q+
<shs96c> orkon: maybe this is some sort of bidi extension for dealing with web extensions. Not sure
<shs96c> ack next
<shs96c> jgraham: I think generally the stuff that's in extensions fits into the model, which is running scripts in specific realms.
<shs96c> jgraham: I'm not sure how close the models of brower and extensions contexts are. Chromium may be doing something different. My best guess is that supporting web extensions is a few more properties or enum options that this script is associated with a specific web extension. Maybe `context created` needs a webextension ID. Similarly for realms.
<whimboo> q+
<orkon> q+
<shs96c> jgraham: It probably makes sense to include the Web Extension CG to make sure we understand the model correctly. The question I have is how much of a priority is this for you?
<shs96c> orkon: it's P3 for Puppeteer, P2 for webdriver, and P5 for Selenium. Depends on how much support is needed. We have subscription events, which allow you to subscribe to everything. Should this apply to extensions?
<shs96c> @jgrh
<shs96c> jgraham: is everything the same priority? The proposal has two separate parts. The capability model seems fairly high priority. For access to the extension, it seems to be lower priority
<shs96c> s/webdriver,/webdriver.io,/
<shs96c> q?
<shs96c> ack next
<shs96c> whimboo: it's not only background pages. web extensions can also add chrome to the browser. When there's a button in the toolbar, there are popups that are opened, these may also be a browsing context
<shs96c> ack next
<shs96c> orkon: the thing with background pages is that in cdp there's a special kind of target, and that's supported in puppeteer (eg. service workers)
<shs96c> orkon: there is no way to automatically handle popups
<shs96c> orkon: how will we handle extension actions? Developers also want to test that.
<shs96c> orkon: the difficulty is that we don't have support for this in CDP or Firefox. It's not something that's already supported.
<shs96c> q?
<shs96c> orkon: the summary is that we need to explore more details, and figure out which changes we need to make to the spec. The feeling is that no-one is opposed to being able to access the extension context from bidi.
<shs96c> shs96c: and the feeling is that we should be able to install extensions from �new session�
<gsnedders> q+
<shs96c> ack next
<jgraham> q+
<shs96c> Sam Sneddon [:gsnedders]: I think that our general concern about webdriver being able to interfere with local browser state (and extensions are installed at the browser level, so interact with the user's safari install) It remains the case that we don't want the user's state to be observable. We are probably better getting people from the Web Extension CG involved. There are questions around interacting with things that are a shared state
<orkon> q+
<shs96c> ack next
<shs96c> jgraham: particularly for installing extensions, it would make sense to have a spec that if you can't install an extension for "whatever reason" then you can fail, and if that's in `new session` it can fail the session creation. End users would have the option of "not doing that". Could easily have the spec not make extension installation a requirement
<shs96c> ack next
<shs96c> orkon: asking a clarifying question: does this position include installing at session start up, or just at runtime?
<shs96c> Sam Sneddon [:gsnedders]: Safari on macOS is a singleton. There's only one instance running. If Safari is already running, the session connects to that running instance.
<shs96c> q?
<jgraham> zakim close the queue
<jgraham> zakim, close the queue
<Zakim> ok, jgraham, the speaker queue is closed
<AutomatedTester> rrsagent, make minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2023/09/15-webdriver-minutes.html AutomatedTester