helium/core: use webstore when extension proxy is off

[Umbranoxio]

For your pull request to not get closed without review, please confirm that:

• An issue exists where the maintainers agreed that this should be implemented
  (an approved feature request, or confirmed bug).
• I tested that my contribution works locally, and does not break anything,
  otherwise I have marked my PR as draft.
• If my contribution is non-trivial, I did not use AI to write most of it.
• I understand that I will be permanently banned from interacting with this
  organization if I lied by checking any of these checkboxes.

Tested on (check one or more):

• Windows
• macOS
• Linux

---

closes #1031 (probably #451 too but i didn't test that case)

changes:

• extensions now download from the chrome web store directly when the proxy setting is turned off
• installs, updates, snippets and pending installs now follow that setting more consistently
• made url matching stricter

testing:

• built on macos
• installed and updated an extension with proxy on and off
• did a quick test with chrome://net-export -- off used google, on used proxy
• didnt test the external extension warning path but should be fine

[dumbmoron]

this should be a flag and not default behavior

[greptile-apps]

Comments Outside Diff (1)

1. patches/helium/core/proxy-extension-downloads.patch, line 419-422 (link)

   if ((true)) return false; is an unusual pattern

   CanUseUpdateService now unconditionally returns false via if ((true)) { return false; }. The double-paren is presumably there to suppress a "condition is always true" warning, but this reads as leftover debug code. If the intent is to permanently disable UpdateService in Helium, an unconditional return false; at the top of the function (with a comment explaining why) would be clearer.

   Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

_{Reviews (1): Last reviewed commit: "helium/core: use webstore when extension..." | Re-trigger Greptile}

[greptile-apps]

Unchecked Profile::FromBrowserContext return value in update loop

Profile::FromBrowserContext(context_.get()) can return nullptr when context_ is not backed by a Profile (e.g., certain off-the-record or system contexts). The previous code guarded this behind if (prefs && ...) and also restricted the block to extensions whose host matched baseUrl. The new code executes the profile/prefs lookup unconditionally for every pending extension, so a null profile will cause a crash on profile->GetPrefs().

[greptile-apps]

Stale downloader config after proxy-setting toggle

manifest_query_params and ping_enabled_domain are baked into the ExtensionDownloader at creation time in EnsureDownloaderCreated(). When the user toggles kHeliumExtProxyEnabled, the pref-change hook triggers CheckSoon(), which calls EnsureDownloaderCreated() — but since downloader_ is already non-null, it is not recreated. The old query params (e.g., CRX_DUMMY vs CRX) and ping domain stay in effect until the downloader is destroyed (typically on browser restart). On the OFF→ON transition the proxy receives real platform params instead of the spoofed ones, defeating privacy.

[greptile-apps]

ShouldAccessExtensionService called twice for the same pref state

helium::ShouldAccessExtensionService(*profile->GetPrefs()) is evaluated separately for set_manifest_query_params and set_ping_enabled_domain. Computing the result once into a local variable would be cleaner and avoids the redundant prefs read.

[Umbranoxio]

this should be a flag and not default behavior

ah, alrighty
saw what was said in the linked issue but guess i misunderstood

[Umbranoxio]

thought about it, guess that changes things a bit then.. there's a few ways this can be handled, which would you prefer @dumbmoron

1. flag can be enabled but only "works" when the proxy setting is disabled
2. flag acts as an override for the extension proxy setting silently (state not visible in the settings ui)
3. flag disables extension proxy setting and greys it out appending a notice to its description thats its disabled cause the flag is enabled (basically a nicer override)
4. ??

[dumbmoron]

flag acts as an override for the extension proxy setting silently (state not visible in the settings ui)

i think this would be fine since it's kind of a fringe configuration, flags usually take precedence over everything else

[TotoCodeFR]

i could test this out on windows if you want (once @Umbranoxio confirms it works for them), especially since that issue affects my work computers (services.helium.imput.net is blocked there)

actually maybe not, can't get the original code to build because of my pc specs, would have loved to though