-
-
Notifications
You must be signed in to change notification settings - Fork 8.4k
[🐛 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
Comments
@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 |
We probably would have to remove support for this method. We cannot deprecate this since the flag is removed in the Chrome itself |
@Delta456, so no workaround? |
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. |
can new BiDirectional feature downgrade Chrome version ? or you mean it can help to enable the flag needed for --load-extension ? |
@vinaghost you can still use |
@vinaghost |
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 |
Looking at this more... this should only break "unpacked" extensions that are loaded via If it still works, then we just need to update our documentation for loading unpacked extensions. |
@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 |
@cgoldberg uhm, how do you load packed extension ? I followed this and this , it gave the result as above. 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(); |
@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. |
I took a quick look at how this works in Selenium. If I'm understanding correctly, Selenium was passing |
Help please :) is there any simple solution? |
@hadastoroP neither of those currently work. You will have to stay on Chrome 136 or else switch to Chromium or Chrome-for-Testing. |
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.) |
@seleniumghost |
hah... someone just reported that this can be undone with this flag:
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? |
I confirm that it works c# example var options = new ChromeOptions();
options.AddExtensions(_extensionsPath);
options.AddArgument("--disable-features=DisableLoadExtensionCommandLineSwitch");
var driver = new ChromeDriver(options); |
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. |
Confirm. Works in Java
|
Uh oh!
There was an error while loading. Please reload this page.
Description
They remove --load-extension that cause
.AddExtensions()
and other similar method brokentheir commit https://chromium.googlesource.com/chromium/src/+/290ed8046692651ce76088914750cb659b65fb17%5E%21/chrome/browser/extensions/extension_service.cc
Version affected: Chrome 137
Reproducible Code
Debugging Logs
ℹ️ Last known working version:
it broke on Chrome 137, worked on 136 and below
The text was updated successfully, but these errors were encountered: