feat: allow a full origin in domain so the launcher can load from a bundled extension - #115
Open
mattbodle wants to merge 2 commits into
Open
feat: allow a full origin in domain so the launcher can load from a bundled extension#115mattbodle wants to merge 2 commits into
mattbodle wants to merge 2 commits into
Conversation
mattbodle
force-pushed
the
feat/launcher-origin-scheme
branch
from
August 13, 2026 23:34
4d2cd3a to
cc3bdb2
Compare
…undled extension generateBaseUrl assumed domain was a bare host and always prepended https://, so the Kit could only fetch launcher.js (and the thank-you element) from a remote https host. Inside an MV3 browser extension that is remote hosted code, which the platform forbids — the extension must load the launcher from its own package. Treat a domain that already carries a scheme as a full origin and use it verbatim (trailing slashes trimmed), mirroring the existing generateReportingUrl handling. Extensions can now set mp.Rokt.domain to chrome-extension://<id>/rokt and the Kit loads launcher.js from the bundle; http:// origins also work for local development. Bare hosts (CNAMEs) keep the https:// default. The ad-block probe is skipped for scheme-bearing origins where it would be malformed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
mattbodle
force-pushed
the
feat/launcher-origin-scheme
branch
from
August 13, 2026 23:38
cc3bdb2 to
aa72d25
Compare
crisryantan
reviewed
Aug 14, 2026
crisryantan
reviewed
Aug 14, 2026
… schemes Addresses review on the launcher-origin change: generateBaseUrl is shared with generateReportingUrl, so a chrome-extension:// domain would have sent logs/errors to chrome-extension://<id>/rokt/v1/log. generateReportingUrl now falls back to the default API domain for non-http(s) schemes, leaving bare-host and http(s) reporting unchanged. The ad-block probe now only skips non-https scheme-bearing domains (extension / local) rather than every scheme, and builds its URL via generateBaseUrl so a full https origin is used verbatim instead of being double-prefixed (https://https://...). Adds tests: https origin still fires the probe, chrome-extension:// does not, and reporting falls back to the API domain for an extension integrationDomain while a full https integrationDomain is used verbatim. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
crisryantan
approved these changes
Aug 14, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Background
Inside an MV3 browser extension, all executable code must ship inside the extension package — fetching JS from a remote host at runtime ("remote hosted code") is forbidden. The Rokt self-contained extension bundle (
app.js= mParticle Web SDK + this Kit) exists precisely to satisfy that policy:launcher.js, the controller, etc. are all bundled into the extension under/rokt/wsdk/….However, when the Kit needs the launcher it builds the URL via
generateBaseUrl(domain), which assumesdomainis a bare host and always prependshttps://. So the Kit can only loadlauncher.js(and the thank-you element) from a remotehttps://<domain>origin — which is remote hosted code, and there's no way to point it at the extension's own bundled copy.mp.Rokt.domainandlauncherOptionsare the only inputs, and neither can express achrome-extension://(or otherwise full) origin.What Has Changed
generateBaseUrlnow treats adomainthat already carries a scheme as a full origin and uses it verbatim (trailing slashes trimmed so path joins stay clean); a bare host keeps thehttps://default. This mirrors the existinggenerateReportingUrlhandling forconfiguredUrl.window.mParticle.Rokt.domain = chrome.runtime.getURL('rokt').replace(/\/$/, ''), and the Kit loadslauncher.jsfromchrome-extension://<id>/rokt/wsdk/integrations/launcher.js— entirely in-package, MV3-compliant.http://origins also now work for local development.https://-prefixed URL would be malformed and the probe meaningless.generateLauncherScript/generateThankYouElementScriptcoveringchrome-extension://origins, trailing-slash trimming, andhttp://origins. Bare-host (CNAME) behaviour is unchanged.Testing
npm run lint— cleannpm test— 232 passed (4 new)npm run build— succeeds🤖 Generated with Claude Code