Skip to content

feat(firefox): add MV3 compatibility - #671

Merged
Sandeep (s-n-d-p) merged 1 commit into
masterfrom
user/sandeepgupta/firefox-mv3-compat
Sep 4, 2026
Merged

feat(firefox): add MV3 compatibility#671
Sandeep (s-n-d-p) merged 1 commit into
masterfrom
user/sandeepgupta/firefox-mv3-compat

Conversation

@s-n-d-p

@s-n-d-p Sandeep (s-n-d-p) commented Sep 3, 2026

Copy link
Copy Markdown
Contributor

Summary

  • add a Firefox MV3 build and XPI package using background.scripts
  • preserve the historical Firefox add-on identity
  • fall back when Chrome offscreen APIs are unavailable

Validation

  • npm run build:prod
  • Firefox package lint: 0 errors
  • loaded the generated XPI in Firefox

@s-n-d-p
Sandeep (s-n-d-p) force-pushed the user/sandeepgupta/firefox-mv3-compat branch from 78b0a54 to 085b6e8 Compare September 3, 2026 15:30
@s-n-d-p Sandeep (s-n-d-p) changed the title Add minimal Firefox MV3 compatibility feat(firefox): add MV3 compatibility Sep 3, 2026
@s-n-d-p
Sandeep (s-n-d-p) force-pushed the user/sandeepgupta/firefox-mv3-compat branch from 085b6e8 to 6acf449 Compare September 3, 2026 15:43
@s-n-d-p
Sandeep (s-n-d-p) marked this pull request as ready for review September 3, 2026 15:52

@ipdutta ipdutta left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code review summary

Clean, well-scoped port. I checked the build wiring against the Chrome path rather than reading it in isolation, and it's a faithful mirror:

  • exportFirefoxJS correctly drops offscreen.js from the bundle list, and exportFirefoxSrcFiles correctly drops offscreen.html — so no orphaned offscreen document ships in the XPI.
  • The targetDirHasExportedCommonJs memo key was added for the new target; missing that would have silently skipped logManager.js.
  • The gulp.src-created-before-await pattern in exportFirefoxJS looks like a race on logManager.js, but exportChromeJS does exactly the same thing. Pre-existing, not introduced here.
  • esbuild emits format: "iife", so background.scripts without "type": "module" loads correctly. The asymmetry with Chrome's service_worker + "type": "module" is right, not an oversight.
  • Manifest diff is exactly what it should be: permissions identical apart from dropping offscreen, host_permissions unchanged at <all_urls>, minimum_chrome_version dropped, browser_specific_settings added. No permission drift in either direction, and the version matches Chrome at 3.11.2.
  • ClientType.FirefoxExtension already existed in the enum, so no renumbering.

Keeping Clipper@OneNote.com as the gecko id is the right call for upgrade continuity on AMO.

Status as of e33a940: no outstanding items.

# Raised Location Outcome
1 getHostname fallback diverged from the offscreen implementation for opaque-origin schemes offscreenCommunicator.ts Fixed — now builds from protocol/host, identical to offscreen.ts
2 Unknown-message-type failure mode offscreenCommunicator.ts Withdrawn — my description of the Chrome behaviour was wrong; the original throw was defensible. Current console.warn + undefined is fine
3 Omits WebExtension.offscreenUrl that chrome/edge set firefoxExtension.ts Declined, and I agree — the field is never read, so assigning it would preserve dead state

Nothing blocking from me.

Comment thread src/scripts/communicator/offscreenCommunicator.ts Outdated
Comment thread src/scripts/communicator/offscreenCommunicator.ts Outdated
Comment thread src/scripts/extensions/firefox/firefoxExtension.ts
Add a Firefox build target, preserve the existing add-on identity, and fall back when Chrome offscreen APIs are unavailable.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot-Session: 9e480e5f-43e9-47fc-a6c4-8de1eaec8dfa
@s-n-d-p
Sandeep (s-n-d-p) force-pushed the user/sandeepgupta/firefox-mv3-compat branch from 6acf449 to e33a940 Compare September 4, 2026 08:46
Comment thread src/scripts/communicator/offscreenCommunicator.ts Outdated
Comment thread src/scripts/communicator/offscreenCommunicator.ts Outdated
@ipdutta

ipdutta commented Sep 4, 2026

Copy link
Copy Markdown
Contributor

Verified both fixes at e33a940 — thanks for the quick turnaround.

getHostname now returns url.protocol + "//" + url.host + "/", which is character-for-character the same construction as getHostname in offscreen.ts. That closes the gap for opaque-origin schemes too: file:///C:/x.pdf now yields "file:///" on both paths instead of "null/" on the fallback. The two implementations are genuinely equivalent now rather than equivalent-in-practice, so the latent dependency on file:// staying out of the match patterns is gone.

One correction I owe you, on the unknown-message-type thread. I re-checked that path after posting and my original claim was wrong: the offscreen handler returns false from onMessage without calling sendResponse, so on Chrome the callback fires with undefined, handleResponse does JSON.parse(undefined), that throws, and the promise returned by sendToOffscreenDocument is never settled. Chrome doesn't cleanly resolve undefined there — it hangs. So "matching the existing offscreen path" wasn't an accurate description of what I was asking for, and the throw you had originally was defensible.

I deleted that thread once I realised it was wrong, not noticing you'd already addressed it — that was premature on my part and made your reply look orphaned. Apologies for the churn.

No need to revert: console.warn + return undefined is a fine landing spot, and it's a defensive branch that no current caller can reach since every call site passes an OffscreenMessageTypes constant. The Chrome-side hang is pre-existing and out of scope here.

Your reasoning on WebExtension.offscreenUrl is right and I'd drop my suggestion — assigning dead state to look symmetric is worse than the asymmetry. Agreed on the content-script point too; it isn't an active path.

Nothing outstanding from me.

@s-n-d-p
Sandeep (s-n-d-p) merged commit 1660c5b into master Sep 4, 2026
8 of 9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants