Provide alternative to `--load-extension` flag in Chrome

[oliverdunk]

What would you like?

In Chrome 137, we are removing the --load-extension flag from branded builds of Chrome. I believe there are likely Cypress users using this for extension testing.

In impacted channels, there are two alternatives available:

• Using the Chrome DevTools Protocol: https://chromedevtools.github.io/devtools-protocol/tot/Extensions/#method-loadUnpacked
• Using WebDriver BiDi: https://www.w3.org/TR/webdriver-bidi/#command-webExtension-install

It would be great to see official support for invoking one of these within a Cypress test.

A Cypress team member had previously expressed interest in this here: https://groups.google.com/a/chromium.org/g/chromium-extensions/c/aEHdhDZ-V0E/m/hgJBUMlRCAAJ

Why is this needed?

Chrome is making a security focused change that impacts existing testing workflows.

Other

I'm happy to help as needed to support this given our team is making the change.

[AtofStryker]

Hi @oliverdunk. I just want to clarify that Chrome 137 is expected to be released in 2 weeks and our team has those two weeks to navigate this large change, it's implications, test at scale, and make sure there are no regressions for our users?

[oliverdunk]

Hi @AtofStryker - I appreciate that it's a quick rollout, which is in part is because we were seeing the flag actively being abused. We did announce this as early as possible (coming up to six weeks ago) to try and give as much notice as possible. When we did an RFC, we also heard from most developers that they would be comfortable using Chrome for Testing, which hopefully means the impact of this isn't too broad.

That said, I'm very open to helping in any way I can. If you have any questions, feel free to ask here or reach out to me privately. I'd also be happy to see if I could open a PR if you don't have the bandwidth to work on this, I would just need to gain some familiarity with the codebase to figure out what would be needed.

Hopefully it's clear that we want to make this as little work for you as possible, and to keep supporting the genuine use cases while preventing this from being used maliciously.

[AtofStryker]

Hi @AtofStryker - I appreciate that it's a quick rollout, which is in part is because we were seeing the flag actively being abused. We did announce this as early as possible (coming up to six weeks ago) to try and give as much notice as possible. When we did an RFC, we also heard from most developers that they would be comfortable using Chrome for Testing, which hopefully means the impact of this isn't too broad.

@oliverdunk I understand the urgency as there are security implications to allowing loaded extensions. That being said, weeks and not months for a large scale change is quite urgent for us 😅 so we are going to have to work together to come up with something quickly.

That said, I'm very open to helping in any way I can. If you have any questions, feel free to ask here or reach out to me privately. I'd also be happy to see if I could open a PR if you don't have the bandwidth to work on this, I would just need to gain some familiarity with the codebase to figure out what would be needed.

I think the easiest path of resistance is to use the CDP Extensions.loadUnpacked method to load the extension and theme, but it looks to require the --enable-unsafe-extension-debugging or --remote-debugging-pipe arguments. Do you happen to have documentation available on those arguments? It looks like the method is still not available after providing the --enable-unsafe-extension-debugging argument. Are you able to determine what is wrong here based on the following logs?

Hoping to get something up and running by EOD if we can 🤞🏻

Hopefully it's clear that we want to make this as little work for you as possible, and to keep supporting the genuine use cases while preventing this from being used maliciously.

We appreciate that. I am hoping we can come to a resolution ASAP.

[oliverdunk]

I think the easiest path of resistance is to use the CDP Extensions.loadUnpacked method to load the extension and theme, but it looks to require the --enable-unsafe-extension-debugging or --remote-debugging-pipe arguments. Do you happen to have documentation available on those arguments?

So doing this requires both the --enable-unsafe-extension-debugging and --remote-debugging-pipe flags. It looks like you are connected with a port which would be the issue here.

Connecting over a pipe is definitely not quite as simple as with a port, but Mozilla recently added support to the chrome-launcher package which might be a good reference implementation: GoogleChrome/chrome-launcher#347

[AtofStryker]

@oliverdunk Is this documented some place where I can see how these options work together and which other options may or may not work with these flags?

I don't think setting remote-debugging-pipe is going to be feasible, as a lot of the tooling we use relies on --remote-debugging-port and trying to lift that in 2 weeks I strongly believe is not going to be possible.

Our use case is a bit different, because we handle automation traffic through CDP in our server and also allow users to load extensions.

I am going to explore the BiDi route tomorrow morning. Are there any other possibilities here besides this?

[AtofStryker]

@oliverdunk I had some time to explore BiDi and it looks like the Bidi -> CDP tab mapper is coming up? Is there a way to disable this? I found https://issues.chromium.org/issues/42323801 but it doesn't look like the issue has been addressed.

It also looks like the API client we use, webdriver, doesn't support the BiDi install methods yet so I created an issue webdriverio/webdriverio#14471

[MikeMcC399]

@oliverdunk

In Chrome 137, we are removing the --load-extension flag from branded builds of Chrome. I believe there are likely Cypress users using this for extension testing.

Just doing a comparison on GitHub sources:

• (--load-extension OR launchOptions.extensions) AND chrome cypress NOT is:archived has 403 hits, compared to
• chrome cypress NOT is:archived with 185k hits

= approx. 0.2% contained --load-extension or Cypress' launchOptions.extensions. This is not a scientific comparison, just a rough check or sanity check. Edit: based on the assessment of @AtofStryker , this type of usage is not the main issue.

A Cypress team member had previously expressed interest in this here: https://groups.google.com/a/chromium.org/g/chromium-extensions/c/aEHdhDZ-V0E/m/hgJBUMlRCAAJ

The team member you mention is @jennifer-shehane

[alexsch01]

Using Windows, as of Cypress 13.16.0 (where %AppData% and %LocalAppData% are filled with the actual directories)

---

using npx cypress run.....the following is added to the Chrome binary Command Line
{SOME_NUMBER} is replaced by the actual run number

--load-extension="%AppData%\Cypress\cy\production\browsers\chrome-stable\run-{SOME_NUMBER}\CypressExtension,%LocalAppData%\Cypress\Cache\13.16.0\Cypress\resources\app\packages\extension\theme"

---

using npx cypress open.....the following is added to the Chrome binary Command Line

--load-extension="%AppData%\Cypress\cy\production\browsers\chrome-stable\interactive\CypressExtension,%LocalAppData%\Cypress\Cache\13.16.0\Cypress\resources\app\packages\extension\theme"

---

Cypress, by default, uses --load-extension as of the latest release

[oliverdunk]

@oliverdunk Is this documented some place where I can see how these options work together and which other options may or may not work with these flags?

I don't believe we have any documentation which goes into more detail unfortunately. In general, I think any flags other than those used for pipe debugging should work.

I don't think setting remote-debugging-pipe is going to be feasible, as a lot of the tooling we use relies on --remote-debugging-port and trying to lift that in 2 weeks I strongly believe is not going to be possible.

Yeah, that makes sense. I don't think there's an easy answer unfortunately but I completely understand the difficulty there.

I am going to explore the BiDi route tomorrow morning. Are there any other possibilities here besides this?

I think BiDi would be the best approach. As I'm sure you know, that's quite a major change but perhaps it is something you could make opt-in for extension developers and that would be a good compromise.

@oliverdunk I had some time to explore BiDi and it looks like the Bidi -> CDP tab mapper is coming up? Is there a way to disable this? I found https://issues.chromium.org/issues/42323801 but it doesn't look like the issue has been addressed.

I thought this was resolved, but I'm not sure. Let me ask a team member to follow up on this issue.

It also looks like the API client we use, webdriver, doesn't support the BiDi install methods yet so I created an issue webdriverio/webdriverio#14471

Oh, thanks for flagging this. I'll add that to the various libraries we are tracking that might be impacted and see if there is anything I can do to help.

[oliverdunk]

@oliverdunk I had some time to explore BiDi and it looks like the Bidi -> CDP tab mapper is coming up? Is there a way to disable this?

I just confirmed and it should be hidden starting in Chrome 137: https://chromiumdash.appspot.com/commit/753acf9df872f629667c329dcfaf73677e8d9f93.

You can test that in beta, but of course it hasn't quite reached stable yet. Hopefully that's helpful though.

[AtofStryker]

I think BiDi would be the best approach. As I'm sure you know, that's quite a major change but perhaps it is something you could make opt-in for extension developers and that would be a good compromise.

@oliverdunk I believe what we are trying to communicate is that Cypress has it's own unpacked unsigned web extension that we use to help our users test in what we call open, or headed mode. Additionally, we allow users to install their own extensions to test with Cypress. We have to support an approach here otherwise we do not have a web extension.

Luckily for us Cypress is mostly automated with CDP in chromium based browsers, but we use the extension for theming as well as our puppeteer plugin, which is going to break.

I don't believe we have any documentation which goes into more detail unfortunately. In general, I think any flags other than those used for pipe debugging should work.

Yeah, that makes sense. I don't think there's an easy answer unfortunately but I completely understand the difficulty there.

I thought this was resolved, but I'm not sure. Let me ask a team member to follow up on this issue.

Cypress supports the last 3 versions of any major browser. Firstly, all older versions of our binary likely will not work with Chrome 137+, which is disruptive. Secondly, Cypress is likely going to need to flex on version to use either --load-extension or another method, likely BiDi at this moment, because the experience is not up to par with the Bidi/CDP bus displaying in Chrome 136 and under. The extension methods for BiDi aren't supported yet by the node webdriver client so they need to be added. Or we need to communicate with the websocket directly 🙁 .

Either way, we are looking at work that is going to take longer than 2-6 weeks to complete. Respectfully, I don't understand how this tight of a deadline can be expected given the state of the surrounding ecosystem, lack of documentation and migration paths, and fulling understanding the implications of current migration paths that we need to discover on our own.

To comply, we are likely looking at a loss of functionality until we are able to support quality work arounds for our users. Personally, I don't see how this is acceptable, especially from a major browser such as Google. The team will be discussing options today and tomorrow and are going to try to forge a plan around this.

For reference, Cypress recently migrated Firefox to Webdriver BiDi with the help of @whimboo from the Mozilla team. The effort took months to guarantee a seamless transition for our users with a lot of back and forth collaboration.