Chrome Extension MV3 Service Worker sporadically does not show

[Michael Wanke]

Hello,

For years, we had a MV2 extension and know it is past time to transition to MV3. We ran our MV3 extension for a year in a select deployment before rolling it out to broadly to try to avoid any issues and impact to our healthcare customers, but we are experiencing some significant challenges.

Problem

On Citrix in a new session, our extension will successfully install and show in chrome://serviceworker-internals 22 times in a row. Then, the next session the extension will show in the force installed extension list, but it won't work. When this occurs, our service worker will not show in chrome://serviceworker-internals. Occasionally (a subset of the sporadic times, the service worker will appear a couple minutes later. Most often when this happens, it seems to never show up.

We are already following the wrapper/try...catch approach to load our service worker:

ourExtensionWrapper.js:

try {

    importScripts("myServiceWorker.js");

} catch (err) {

    console.error(err);

}

Out of desperation, we even modified the above and added retry logic here with a delay to no effect. Getting Chrome.exe debug logs are incredibly challenging but have been requested again.

Any ideas on what we should look/try? 

Mitigations we have tried:

1. Leverage wrapper approach with try/catch around service worker code
2. In the wrapper, retry importing the service worker code
3. Using alarms to try to keep the service worker running. We don't have any technical reason we need this but did it anyway. When the above circus
4. For content.js - we are subscribing to chrome.runtime.onInstalled, chrome.runtime.onStartup, chrome.management.onDisabled, chrome.management.onEnabled to reinject our content.js to prevent invalid extension context within our background service worker code (not the wrapper). 

I saw https://issues.chromium.org/issues/336832598?pli=1 which seems possibly related, and https://groups.google.com/a/chromium.org/g/chromium-extensions/c/Tv0Q8rtDohg, but my posts to that thread were never approved by a moderator.

Thanks,

Michael

[Oliver Dunk]

Hi Michael,

Thanks so much for sharing this. All of your posts should be approved now and any future ones should go live immediately. We don't want this to be a heavily moderated forum and generally accept whatever comes in - but we had to introduce the queue since we saw an increase in spam that was impacting everyone who is subscribed to the posts here.

The behavior you're describing sounds wrong for sure, and as you mentioned there have been a couple of other reports of interesting behavior in Citrix environments. I can't speak to specific workarounds because it's not an environment I'm familiar with, but none of them should be necessary. It seems like it would be worthwhile investing some time on our side to see if we can reproduce what is described.

I'm going to chat to the engineering team today to see if they have any thoughts here and I'll let you know when I hear back. I appreciate your patience.

Thanks,

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/ab2782b7-d24f-4978-bd1f-bf15b53d6958n%40chromium.org.

[Michael Wanke]

Thanks Oliver. We really appreciate it. 

I'm happy to provide anything and everything that would help.

Michael

---

From: Oliver Dunk <olive...@google.com>
Sent: Thursday, November 14, 2024 6:26:35 AM
To: Michael Wanke <Michae...@forwardadvantage.com>
Cc: Chromium Extensions <chromium-...@chromium.org>
Subject: Re: [crx] Chrome Extension MV3 Service Worker sporadically does not show

 

[Michael Wanke]

I am looking over a log and the sporadic failure seems to have a "not found" error on the log:

[7792:18548:1113/134754.740:ERROR:service_worker_task_queue.cc(196)] DidStartWorkerFail cbcjdhblcnboaegpdapojngjkckbklim: 5

It can work repeatedly on the same host, and then the above. We're just struggling to figure out the cause or how to avoid it. 

I learned this morning from our support team that if the customer removes another extension (that was also pushed by GPO), our extension seems to load successfully every time.

Michael

---

From: Michael Wanke <Michae...@forwardadvantage.com>
Sent: Thursday, November 14, 2024 7:35:59 AM
To: Oliver Dunk <olive...@google.com>

[Oliver Dunk]

[7792:18548:1113/134754.740:ERROR:service_worker_task_queue.cc(196)] DidStartWorkerFail cbcjdhblcnboaegpdapojngjkckbklim: 5

At least in some cases, my understanding is that this error is expected. It's worth posting on the bug though in case it's helpful to the team.

I learned this morning from our support team that if the customer removes another extension (that was also pushed by GPO), our extension seems to load successfully every time.

This is really interesting! Are you able to share what extension this was by any chance? 

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Michael Wanke]

Hi Oliver,

The extension being disabled is bpgncafocbpieaeigfcookhgmeamglgo. It seems like the "success" of disabling this extension must be a misnomer, something we're doing wrong, or a complication of our particular deployments. To elaborate: both this extension and our extension are interacting with the same Electronic Healthcare Record system's web page and leverage native messaging, pushed through GPO, in Citrix, etc. We are also partners with the author of that extension and I have reached out to see review for any additional insights.

Michael

[Michael Wanke]

We continue to troubleshoot and have narrowed the situation down to Chrome with Citrix non-persistent environments. Toggling the extension off and back on again gets it working again. 

Any other environment we think we can ultimately get working normally (instance clones, thick clients, desktops, etc.).

We're currently evaluating our options, including going back to MV2 and having customers add the enterprise policy to allow it.

Oliver - did you get any feedback from the engineering team?

Michael

[Oliver Dunk]

No feedback yet - I raised the issue though and there was agreement that this is worth looking at.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Michael Wanke]

Thanks Oliver. I went ahead and added more notes to https://issues.chromium.org/issues/336832598 and a log I received. We can get more logs with some notice. We're also seeing similarity with bug https://issues.chromium.org/issues/40935316 so I copied a comment there too just in case.

Michael

[Michael Wanke]

An update if helpful: We're hearing consistently that customers are deleting the userData folder as a workaround.

[Michael Wanke]

Oliver - I saw a comment on one of the bugs that one challenge for the Google team is they don't have a Citrix environment. Our team has invested the time the create a Citrix XenApp test environment and can readily reproduce the issue. We are on a trial and have limited time. How do we help the Google Engineers look this over / leverage our environment?

Michael

[Michael Wanke]

In our internal testing, we have found the below workaround. We are hoping to test with a customer tomorrow:

Citrix

• When using template profiles, obtain these folders from a fresh user session using a newly created profile where the extension service worker for the newest version of the extension is present in chrome://serviceworker-internals. 
  • Note: If the extension is listed in chrome://extensions but the corresponding service worker is not listed in chrome://serviceworker-internals, logout and destroy the Citrix session, and try again. 
• Once you have a valid session from the prior step: In the template user profile, include the folder structure leading to these folders and the files they contain found at %LocalAppData%/Google/Chrome/User Data/
  

When using Citrix Profile Management with template profiles, extensions that are installed display in chrome://extensions and should have service workers appear on the chrome://serviceworker-internals page. However, service workers appear intermittently. By ensuring these specific folders and files are present, we have found that the service worker reliably registers and appears on chrome://serviceworker-internals  page every time.

[Michael Wanke]

Attached is the "undefined" that appeared above showing the User Data/Default folder contents including:

• Extension Rules
• Extension Scripts
• Extension State
• Extensions
• Service Worker

[Oliver Dunk]

Hi Michael,

Thanks for sharing these updates. Sorry for missing this thread at the end of last year.

Do you still have access to the test environment? If so, I'll see if any of our engineers are able to spend some time looking into this.

Either way, I'll pass on your findings and see if that leads us any closer to figuring out what's happening.

Glad you have a workaround in the meantime but it would be nice to properly figure this out.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Michael Wanke]

Hi Oliver, I sent off an email asking the team today if it is and will report back.

For the benefit of the thread, the above workaround worked and is deployed at numerous organizations.

The team found the Persistent Citrix XenApp setups need a little more:

• One-off workaround: Delete the folders (listed above from a known good user) from the user's persistent profile and it should work when that user next logs on. This will not stop future new profiles from sometimes having the problem.
• Full workaround: If they are using a template profile
  • install the folders (listed above from a known good user) in the template profile OR 
  • start using a template profile and install the folders OR 
  • install the folders from the non-persistent fix in C:\users\default on every RDS host ("app server") 

Michael

[Michael Wanke]

Hi Oliver,

Unfortunately, the Citrix environment is no longer available.

Michael

[woxxom]

Do you all use importScripts or modules in your service worker? If so, try bundling everything into one file.

[Oliver Dunk]

Hi Michael,

Thanks for your patience. I was able to speak to the engineering team last week and get some more thoughts on this.

First of all, we'd be really curious to know if it's possible to get a bad user data directory. You mentioned that if you get a good user data directory, you can load that onto machines and the issue never occurs. If you load a bad user data directory onto a machine, does that consistently reproduce the issue or is it intermittent?

I know you don't currently have a running test environment, but I also asked about if that would be helpful if you were able to get another one. It would be great to know more about how complex the setup is, and what we would and wouldn't be able to do on the machine. Debugging issues usually requires running custom binaries of Chromium so we would need quite a lot of access. This also isn't something we traditionally do just because of the effort involved and the low success rate of diagnosing these issues given the number of external factors.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Neeraj Sharma]

Hello Oliver,

We have been facing the same issue with the users of our extensions

Here is what we saw in the Chrome debug log file,

The log used a random example extension but we have been able to replicate it with multiple extensions

For the extension whose background worker did not run in the initial launch, the following log was not present in the debug log file:

[4060:5512:1212/190002.791:VERBOSE1:script_context.cc(151)] Created context:

extension id: lcdlignfoefnkcfejmlnegoobondbfjb

frame: (nil)

URL:

context_type: BLESSED_EXTENSION

effective extension id: lcdlignfoefnkcfejmlnegoobondbfjb

effective context type: BLESSED_EXTENSION

The background service worker never runs on the initial launch and seems to run on a relaunch. The above log was taken from the log file of the relaunch

This has been blocking our customers from using the extension as it never runs

While we are trying out the User Data workaround to see if it works out for us, it will be very helpful if this can be fixed in Chrome.

The issue has been affecting more users as evident from the following issue threads:

• https://issues.chromium.org/issues/336832598
• https://issues.chromium.org/issues/40860233
• https://issues.chromium.org/issues/40935316
• https://groups.google.com/a/chromium.org/g/chromium-extensions/c/Tv0Q8rtDohg/m/M5zy4LdFCwAJ
• https://github.com/Tampermonkey/tampermonkey/issues/2221
• https://issues.chromium.org/issues/40805401

Thanks,

Neeraj

[Oliver Dunk]

Hi Neeraj,

We have been facing the same issue with the users of our extensions

Could you explain in a bit more detail the issue you're seeing?

This thread in particular is about an issue where a service worker is registered multiple times in a Citrix environment. It seems clear that there are also some other cases of registration issues, but I want to make sure we're not mixing them up and making things harder to troubleshoot.

Once we know that, I'm happy to take this to the team and we can see if there is anything unexpected in that log.

Thanks,

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Neeraj Sharma]

Hi Oliver,

The issue we have been facing is in a non-persistent Citrix environment where our chrome extension is pushed via GPO along with some other extension and it intermittently does not register its service worker (no entry in chrome://serviceworker-internals) when Chrome is launched for the first time in that session even though it shows correctly in the force installed list in chrome://extensions. It happens intermittently as in other sessions the service worker is registered as expected. From what I understand and read in the above messages, this thread is also about the similar issue as also mentioned by Michael in his first message:

> the next session the extension will show in the force installed extension list, but it won't work

When the issue occurs, the service worker registration seems to succeed when Chrome is relaunched in that session in our experience but I cannot say that for sure

Interestingly, content scripts are correctly injected by the extensions (if mentioned in manifest.json) so it seems that only the service worker registration fails.

But this issue leaves our extension essentially inactive as the service worker is not registered.

We were able to replicate the issue without using a Citrix non-persistent environment by the following steps (also mentioned in the drive link attached):

To replicate the issue, you can try out the following steps on a Windows machine (not necessary to be a Citrix or non-persistent environment):

1. Make sure that no registry policies are present for Chrome (SOFTWARE\Policies\Google)

2. Open and close Chrome to make sure any existing policy has been reset and then uninstall Chrome

3. Add the registry entry SOFTWARE\Policies\Google\Chrome\ExtensionInstallForcelist and add at least these extensions - epngggilgnflanfabeldfpbgponcgpgl, echcggldkblhodogklpincgchnpgcdco and lcdlignfoefnkcfejmlnegoobondbfjb

4. Rename Google in SOFTWARE\Policies\Google\Chrome\ExtensionInstallForcelist to any name like Google1 (this is to replicate the scenario of GPO policy being pushed when Chrome is being installed in a non-persistent Citrix environment.

5. Install Chrome and at the same time rename Google1 to Google to replicate the scenario of GPO policy pushes in non-persistent environments

6. Launch Chrome and go to chrome://extensions

7. Switch on Developer Mode

8. You should see one or more of the installed extension's service worker as inactive and clicking on it will not open the dev tools

9. Copy the extension id for which above point occurred and go to chrome://serviceworker-internals to see that no entry was created for this extension id

10. Relaunch chrome and go to chrome://extensions

11. Clicking on the extension's service worker should open the dev tools correctly now

If all your extensions are running correctly, please try the above steps again. As this issue is intermittent, some times it may happen that all extensions may run as expected

You can find the reference videos for replication in the following drive links:

1. Issue Reproduction of extension service worker not running

2. Extension working on a relaunch of Chrome

You can see in the above recording that random extensions failed to register their service workers intermittently which is also what the issue mentions

Please let me know if you have any questions or need any more details

Will highly appreciate if you can take a look into this as this has impacted us in a major manner

Quick note: Although we do not know if the service worker was registered multiple times when things worked for the affected extension, the resulting issue has been the same where the service worker did not register.

Thanks and regards,

Neeraj

[Oliver Dunk]

Hi Neeraj,

Thanks so much for sharing this. It's incredibly detailed and if we're able to reproduce with those steps, it will be really helpful.

I'm taking a look at doing so and I'll let you know how it goes. Thanks for bearing with me.

Thanks,

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Neeraj Sharma]

Hi Oliver,

I appreciate you looking into this. Please let me know if you want any further details as well.

I am attaching the histogram data we gathered recently from chrome://histograms/#Extensions.ServiceWorkerBackground.WorkerRegistrationState in another replication of the issue.

Attached are the following files:

1. Data when the issue occurs on the first launch:
   Link: histograms data when error occured.txt
   My observation: It seems some samples were in registration state 0 (in this case, 3 extensions had failed to start their service workers)
2. Data when Chrome was relaunched and the issue did not occur:
   Link: histograms data when chrome was relaunched and issue does not occur.txt
   My observation: No samples were in registration state 0, all samples were in registration state 1

Regards,
Neeraj

[Michael Wanke]

Oliver - in case it is relevant, the CL discussion and resulting bug below peaked my interest:

https://issues.chromium.org/issues/40680422#comment4

I noticed this bug wasn't in Neeraj bug list and wanted to make sure you both saw it and ruled in/out.

Michael

[Neeraj Sharma]

Hi Simon,

I wanted to follow up to check if you were able to replicate this issue. Please let us know if you need any additional information from us.

This issue has had a significant impact on us, so we would greatly appreciate any updates or insights you can share.

Looking forward to your response.

Thanks and regards,
Neeraj

You received this message because you are subscribed to a topic in the Google Groups "Chromium Extensions" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/chromium-extensions/g8EdtLlbDq4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to chromium-extens...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/27ee3157-f94a-451f-a419-3c7c7a6a3cben%40chromium.org.

[Neeraj Sharma]

Hi Oliver,

In the last few days, we have been able to replicate the issue on other popular extensions and have some updates that could help you point out the problem better.

The problem arises only when specific extensions—such as the following—are installed alongside the affected extensions (this is not an exhaustive list and there could be more such extensions that are causing this issue):

• Extension id: echcggldkblhodogklpincgchnpgcdco [this is the extension that has been causing the issue for us; the problem does not occur when this extension is not pushed via registry]
• Extension id: bpgncafocbpieaeigfcookhgmeamglgo [this was mentioned by Michael previously, we installed it with our extensions to verify this and could see the issue occurring the same as the above extension]

A common factor that I could find between the above two extensions was that they both use native messaging, but I am not sure if that can cause any issues. Can native messaging somehow cause the other extensions to fail and not register their service worker?

Popular extensions like the following have also failed to start their service workers:

• Google Translate (Extension created by the Google development team) -  https://drive.google.com/file/d/1WPO2X_W-bDThWm2SUPLpvDVNFQVqx2Hu/view?usp=drive_link
• Google Keep (Extension created by the Google development team) - https://drive.google.com/file/d/1BqWECT-J09rDOaPT0W7xoncHSQ9uhtgS/view?usp=drive_link
• Loom: https://drive.google.com/file/d/18DnoxdKL2bYTI0d2uQ4nBqdQjAldXPPD/view?usp=drive_link
  As visible in the video, in the first launch, the affected extensions are not present in chrome://serviceworker-internals and relaunch makes the service workers register correctly in chrome://serviceworker-internals

I am sharing another way (simpler) in which you can replicate this issue:

1. Install Chrome

2. Push extensions via Windows registry keys (ExtensionInstallForcelist)

• Add at least these extension IDs:

• "liecbddmkiiihnedobmlmillhodjkdmb"

• "kbfnbcaeplbcioakkpcpgfkobkghlhen"

• "kpfdemggfomjlkpnoniejidiggiogbop"

• "aapbdbdomjkkjkaonfhkkikfgjllcleb"

• "lpcaedmchfhocbbapmcbpinfpgnhiddi"

• "lcdlignfoefnkcfejmlnegoobondbfjb"

• "echcggldkblhodogklpincgchnpgcdco" (This must be included, as it is one of the extensions that triggers this issue.)

3. Delete the entire folder: %localappdata%\Google (Ensure this whole folder is completely removed.)

4. Relaunch Chrome and go to chrome://extensions

5. Check if any extension's service worker is inactive and does not open the dev tools when clicked on it

6. Verify whether all extensions have their entries correctly added in chrome://serviceworker-internals

7. If everything works correctly, try again from step no. 3.

In a few attempts, you should be able to replicate the issue as shown in the video

For users on non-persistent VDIs, since every session is a new user profile session this issue is very evident for them and has affected our extension's users significantly.

It does look to be an issue in Chrome when it is creating the user profile and installing the extensions for the first time in a user session. But strangely, it occurs majorly when extensions like the above-mentioned two extensions are pushed together, and they are never affected, only the other extensions are affected. I am sure that Chrome does not give extensions the ability to interrupt the initialization of any other extension so it looks to be a Chrome issue rather than any extension-specific issue.

Best,

Neeraj

[Oliver Dunk]

Hi Neeraj,

Thanks so much for sharing this.

I started working through the steps you had shared last week but I haven't yet had a chance to go through them end to end. Rest assured that I haven't forgotten about this though, and I'll let you know how I get on. Hopefully I can have some results by the end of the week.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Oliver Dunk]

Hi again,

I spent some more time on this today and I was able to reproduce the issue. I've gone ahead and filed a new bug here, and I've already flagged this to the team so that they can start digging further: https://issues.chromium.org/394523691

Thanks so much for your help and patience. The detailed steps and notes on your environments (from everyone who provided those) is very much appreciated. These are often really tricky to figure out, but with the position we're in now I'm hopeful that we'll be able to make some progress.

I'd definitely encourage you to +1 the bug so you get updates, but I'll also try to update here as well.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Oliver Dunk]

Just to add, I think there's a chance this new bug duplicates some of the existing ones. With so many different setups though, it felt worth opening a new bug with the much simpler steps to reproduce we now have.

Once we've made some progress here I'll definitely take another look and I'd be happy to move this bug into another if that makes sense.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Neeraj Sharma]

Thanks a lot, Oliver!

I'll share any new findings here and in the bug report. Hopefully, we can resolve this issue soon. In the meantime, do you have any suggested workarounds? Also, is there generally any estimated timeline for a fix? That would help us keep our users informed.

Thanks and regards,

Neeraj

[Oliver Dunk]

We're not quite at the point of having workarounds or a timeline. Once we have a better understanding of the issue though, I'll let you know.

Sorry to not have more to share!

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[woxxom]

Logically, the workaround may be to reload the extension if SW is not registered, which you can perform in the popup or in any UI of your extension that the user is likely to open when they see the extension doesn't work:

if (!navigator.serviceWorker.controller) {

  document.body.textContent = 'Service worker is not registered. Reloading the extension...';

  setTimeout(chrome.runtime.reload, 1000);

[Neeraj Sharma]

Thanks @woxxom
This solution did not work out for us as our extension is passive, and users are not expected to click on any popups, so this was eventually not feasible for us.

But, we did some analysis and have some information that may be valuable for you to understand the issue and the fix that may be needed (and provide possible workarounds if available).

1. Service worker registration pattern when this issue occurs:

This is from the log file: %localappdata%\Google\Chrome\User Data\Default\Service Worker\Database\000003.log when this issue occurs:

:REG:chrome-extension://aapbdbdomjkkjkaonfhkkikfgjllcleb/ => interrupted

:REG:chrome-extension://lpcaedmchfhocbbapmcbpinfpgnhiddi/ => interrupted

:REG:chrome-extension://bpgncafocbpieaeigfcookhgmeamglgo/ => goes to completion

:REG:chrome-extension://echcggldkblhodogklpincgchnpgcdco/ => goes to completion

As you can see, the registration for the affected extension's service worker began but was interrupted when the issue-causing extension started its registration.

In my understanding, this seems to happen when the affected extension's service worker registration begins in close vicinity of the load/registration of the issue-causing extensions.

You can find the log file and its relevant policies.json in: https://drive.google.com/drive/folders/1v3q2j-17ucbVwvzO8GJzGo-JstQHzCl1?usp=sharing

2. Permissions that seem to be causing this:

We noticed that certain extension permissions have been causing this, the permissions that we found to be causing this are:

a. webRequest

b. declarativeNetRequest

The presence of any of these causes issues with other extensions' service worker initialization (on first launch of new profile)

Please note: This may not cover all the permissions that may be causing this issue. We have not been able to figure out if any other permissions may also have caused this issue. But we are certain that these permissions definitely cause the issue.

In the above case, both bpgncafocbpieaeigfcookhgmeamglgo and echcggldkblhodogklpincgchnpgcdco have webRequest permissions. You may also test with an extension with declarativeNetRequest permission and should be able to see the same issue come up again.

3. [Not confirmed] Code in Chromium that may be causing it:

Please note: I am new to Chromium codebase so this may be completely incorrect

While not confirmed, it seems that the following code in WebRequestAPI::OnExtensionLoaded (and possibly WebRequestAPI::OnExtensionUnloaded) dealing with extension load and unloads may be causing this kind of issue. Here's what seems to be happening:

In: src/extensions/browser/api/web_request/web_request_api.cc

In WebRequestAPI::OnExtensionLoaded (and possibly WebRequestAPI::OnExtensionUnloaded):

- Check if extension has any of the webRequest, declarativeNetRequest or webView permissions

- If the extension has any of these permissions, reset the URL loader factories

Can resetting the URL loader factories cause the in-progress service worker queue to get interrupted and marked as failed? Or, can it cause the existing service worker registration to be stopped and skipped in any way?

void WebRequestAPI::UpdateMayHaveProxies() {

bool may_have_proxies = MayHaveProxies();

if (!may_have_proxies_ && may_have_proxies) {

browser_context_->GetDefaultStoragePartition()->ResetURLLoaderFactories();

}

may_have_proxies_ = may_have_proxies;

}

void WebRequestAPI::OnExtensionLoaded(content::BrowserContext* browser_context,

const Extension* extension) {

CHECK(extension);

bool update_may_have_proxies = false;

if (HasAnyWebRequestPermissions(*extension)) {

++web_request_extension_count_;

update_may_have_proxies = true;

}

if (HasAnyDeclarativeWebRequestPermissions(*extension)) {

++declarative_request_extension_count_;

update_may_have_proxies = true;

}

if (HasWebViewPermission(*extension)) {

++web_view_extension_count_;

update_may_have_proxies = true;

}

if (update_may_have_proxies) {

UpdateMayHaveProxies();

}

}

We noticed that adding these permissions to an extension may reduce the chance of that extension being affected by this scenario, however, due to lack of expertise in the code, we need your opinion on this.

- Do you see any possible workaround for this issue now?

- Do you think any other permission or extension type may cause this as well?

- Is there any update related to the issue? We didn't notice any activity in the ticket that you created a month ago, and would highly appreciate it if you can share a plan or some ETA.

Please let us know if you have any questions

Regards,

Neeraj Sharma

[Oliver Dunk]

Hi Neeraj,

Thanks so much for sharing this. One of our engineers is actively investigating this issue, and I've just passed your message along to see if there is anything which might be helpful.

At the moment we don't have a good explanation for what is causing this, or what possible workarounds could be, but I hope we can figure that out soon.

I really appreciate your patience on this one, and all of the helpful troubleshooting in this thread so far. Given we have the steps to reproduce I'm confident we will be able to fix it.

Thanks,

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Michael Wanke]

Any update? This is still impactful to our customers and our staff.

Do you have a preferred bug I should send to our customers to comment on?

Michael