Skip to content

[🐛 Bug]: Chrome team removes --load-extension switch on Chrome builds #15788

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

Open
vinaghost opened this issue May 24, 2025 · 20 comments
Open
Labels
A-needs-triaging A Selenium member will evaluate this soon! C-dotnet .NET Bindings D-chrome I-defect Something is not working as intended I-regression Something was working but we "fixed" it OS-windows

Comments

@vinaghost
Copy link

vinaghost commented May 24, 2025

Description

They remove --load-extension that cause .AddExtensions() and other similar method broken

their commit https://chromium.googlesource.com/chromium/src/+/290ed8046692651ce76088914750cb659b65fb17%5E%21/chrome/browser/extensions/extension_service.cc

Version affected: Chrome 137

Reproducible Code

var options = new ChromeOptions();
options.AddExtensions(_extensionsPath);
var driver = new ChromeDriver(options);

Debugging Logs

[13564:10684:0524/222309.634:WARNING:chrome\browser\extensions\extension_service.cc:359] --load-extension is not allowed in Google Chrome, ignoring.

ℹ️ Last known working version: it broke on Chrome 137, worked on 136 and below

@vinaghost vinaghost added I-defect Something is not working as intended A-needs-triaging A Selenium member will evaluate this soon! labels May 24, 2025
@selenium-ci
Copy link
Member

@vinaghost, thank you for creating this issue. We will troubleshoot it as soon as we can.

Selenium Triage Team: remember to follow the Triage Guide

@github-actions github-actions bot added C-dotnet .NET Bindings D-chrome I-regression Something was working but we "fixed" it OS-windows labels May 24, 2025
@Delta456
Copy link
Member

We probably would have to remove support for this method. We cannot deprecate this since the flag is removed in the Chrome itself

@vinaghost
Copy link
Author

@Delta456, so no workaround?

@Delta456
Copy link
Member

There isn't a workaround with CDP. You will have to downgrade Chrome version, though this will be available with BiDi. Java and Python will have them implemented by next Selenium release.

@vinaghost
Copy link
Author

can new BiDirectional feature downgrade Chrome version ? or you mean it can help to enable the flag needed for --load-extension ?

@navin772
Copy link
Member

@vinaghost you can still use --load-extension on non-Chrome branded builds like Chromium and Chrome for Testing. Thread - https://groups.google.com/a/chromium.org/g/chromium-extensions/c/aEHdhDZ-V0E/m/UWP4-k32AgAJ

@cgoldberg
Copy link
Contributor

can new BiDirectional feature downgrade Chrome version ? or you mean it can help to enable the flag needed for --load-extension ?

@vinaghost
The BiDi feature will be a new way to load extensions. For a workaround right now, it looks like you will have to use an older version of Chrome (or else current version of Chromium or Chrome-for-Testing).

@cgoldberg
Copy link
Contributor

this will be available with BiDi. Java and Python will have them implemented by next Selenium release.

Note to anyone using Python:

This feature has already landed via #15749 (make sure to read the comments for the necessary startup flags needed to use it in Chrome).

To get it before the official Selenium 4.34 release, you can upgrade to the nightly release with pip install -U -i https://test.pypi.org/simple/ selenium

@cgoldberg cgoldberg removed the A-needs-triaging A Selenium member will evaluate this soon! label May 25, 2025
@cgoldberg
Copy link
Contributor

They remove --load-extension that cause .AddExtensions() and other similar method broken

Looking at this more... this should only break "unpacked" extensions that are loaded via --load-extension arg. Selenium's methods for loading packed extensions via Chrome options doesn't rely on this. Can anyone confirm that this is actually broken in any of the bindings when using the AddExtension/addExtension/add_extension methods with Chrome 137?

If it still works, then we just need to update our documentation for loading unpacked extensions.

@cgoldberg cgoldberg added the A-needs-triaging A Selenium member will evaluate this soon! label May 25, 2025
@selenium-ci
Copy link
Member

@vinaghost, thank you for creating this issue. We will troubleshoot it as soon as we can.

Selenium Triage Team: remember to follow the Triage Guide

@vinaghost
Copy link
Author

vinaghost commented May 25, 2025

@cgoldberg uhm, how do you load packed extension ? I followed this and this , it gave the result as above.
I have 3 files crx and their path is in the _extensionsPath variable

var options = new ChromeOptions();
options.AddExtensions(_extensionsPath);
var driver = new ChromeDriver(options);
var list = new List<string>();

foreach (var extensionName in extensionNames)
{
   if (!extensionName.Contains(".crx")) continue;
   var path = Path.Combine(extenstionDir, extensionName);
   list.Add(path);
}
_extensionsPath = list.ToArray();

@cgoldberg
Copy link
Contributor

@vinaghost so it must be broken for loading both packed and unpacked extensions. I'm not sure why packed extensions would be affected.

Also note... if you let Selenium Manager handle Chrome/Chromedriver for you, it will download Chrome-for-Testing, where extensions still work fine.

@oliverdunk
Copy link

I'm not sure why packed extensions would be affected.

I took a quick look at how this works in Selenium. If I'm understanding correctly, Selenium was passing --load-extension with the path to a CRX. That was actually just extracting the CRX file (CRX is a ZIP file with additional header data) and then loading the extracted folder as an unpacked extension.

@hadastoroP
Copy link

Help please :)
My product, from C# used:
options.AddArgument($"load-extension={WebContext.CurrentContext.ChromeExtensionPath}");
it loads an unpacked extension.
It does not work on chrome version 137.

is there any simple solution?
Does options.AddExtensions(_extensionsPath); also work for unpacked extensions?

@cgoldberg
Copy link
Contributor

@hadastoroP neither of those currently work. You will have to stay on Chrome 136 or else switch to Chromium or Chrome-for-Testing.

@seleniumghost
Copy link

Thank you for all this information.

(This is the 2nd time now within some weeks where a change in productional Chrome/chromedriver stops us from updating it in automated testing environments. First was #396611138 (Chromedriver 133 creates an extra window handle when opening a pdf in a new tab) which took at first time to find it and then months (from 21.02.25 - 05.05.25) to get into the stable version of 136. Now the next version, 137, got the next big issue. I hope it won't take months again.

It's also sad that the reason mentioned in RFC survey for not using Chrome-for-Testing "The reason is that we want to be as certain as possible that we're getting the same results as customers would get" did not get more attention and that the flag was thrown away without any prior deprecation notice or error/warning message. What a luck that we tested it before the productional update and found it by chance.)

@cgoldberg
Copy link
Contributor

@seleniumghost
if you have complaints about the chrome/chromedriver development or release process, raise them with Google or the Chromium project... they don't belong here.

@cgoldberg
Copy link
Contributor

hah... someone just reported that this can be undone with this flag:

--disable-features=DisableLoadExtensionCommandLineSwitch

I just verified you can still use the old way of loading extensions if you start Chrome using this flag.

Should we add this by default to our Chrome Options? or just update the documentation that this is a workaround?

@oliverdunk is this going to remain working like this?

@vinaghost
Copy link
Author

I confirm that it works

c# example

var options = new ChromeOptions();
options.AddExtensions(_extensionsPath);
options.AddArgument("--disable-features=DisableLoadExtensionCommandLineSwitch");
var driver = new ChromeDriver(options);

@oliverdunk
Copy link

@oliverdunk is this going to remain working like this?

This is part of the feature flag system we use to launch features. Unfortunately, that means it will go away once we are confident we no longer need a killswitch (usually they are around for no more than a few Chrome milestones).

Given that, I don't think this would be a good thing to document. It is only a temporary workaround and it is expected to break in the future at which point there would be the same issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-needs-triaging A Selenium member will evaluate this soon! C-dotnet .NET Bindings D-chrome I-defect Something is not working as intended I-regression Something was working but we "fixed" it OS-windows
Projects
None yet
Development

No branches or pull requests

8 participants