fix: mv2 firefox csp header

[itsyoboieltr]

Description

This PR implements a workaround for a long-standing Firefox MV2 bug where the content-security-policy header is not bypassed, triggering an error.

The solution is simple: we check if the extension is MV2 running in Firefox. If yes, we override the header to prevent the error from raising.

Related issues

Fixes: #3133, https://github.com/MetaMask/MetaMask-planning/issues/3342

Manual testing steps

1. Opening github.com should not trigger the CSP error

Screenshots/Recordings

Before

After

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Extension Coding Standards.
• I've completed the PR template to the best of my ability
• I’ve included tests if applicable
• I’ve documented my code using JSDoc format if applicable
• I’ve applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.

[github-actions]

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

[sonarqubecloud]

Quality Gate failed

Failed conditions
1 Security Hotspot
18.8% Coverage on New Code (required ≥ 80%)

See analysis details on SonarCloud

[danjm]

This looks good to me overall. Has anyone manually tested with a prod-like build?

[metamaskbot]

Builds ready [cec02cb]

• builds: chrome, firefox
• builds (beta): chrome
• builds (flask): chrome, firefox
• builds (MMI): chrome, firefox
• builds (test): chrome, firefox
• builds (test-flask): chrome, firefox
• build viz: Build System
• mv3: Background Module Init Stats
• mv3: UI Init Stats
• mv3: Module Load Stats
• mv3: Bundle Size Stats
• mv2: E2e Actions Stats
• code coverage: Report
• storybook: Storybook
• typescript migration: Dashboard
• all artifacts
• bundle viz:

  • background: 0, 1, 2, 3, 4, 5, 6, 7
  • common: 0, 1, 10, 11, 12, 2, 3, 4, 5, 6, 7, 8, 9
  • content-script: 0
  • offscreen: 0
  • ui: 0, 1, 10, 11, 12, 2, 3, 4, 5, 6, 7, 8, 9

Page Load Metrics (2095 ± 90 ms)

Platform	Page	Metric	Min (ms)	Max (ms)	Average (ms)	StandardDeviation (ms)	MarginOfError (ms)
Chrome	Home	firstPaint	309	2475	2030	432	207
		domContentLoaded	1754	2464	2068	177	85
		load	1763	2477	2095	188	90
		domInteractive	22	90	45	19	9
		backgroundConnect	9	153	28	33	16
		firstReactRender	53	289	127	64	31
		getState	5	66	19	18	8
		initialActions	0	1	0	0	0
		loadScripts	1230	1777	1510	139	67
		setupStore	14	85	44	24	11
		uiStartup	2036	2862	2422	242	116

Bundle size diffs [🚨 Warning! Bundle size has increased!]

• background: 3 KiB (0.07%)
• ui: 2.03 KiB (0.03%)
• common: 604 Bytes (0.01%)

[itsyoboieltr]

@danjm I manually tested it today with a prod-like build using the command:

yarn webpack --env production --no-lavamoat --browser firefox

it worked for me locally.

[DDDDDanica]

Hey @itsyoboieltr I used the build from bot above and tested locally the zip in firefox. I noticed that in firefox page we won't receive any errors, while in extension log we still have it, is this expected?

[itsyoboieltr]

Hi @DDDDDanica, thank you for checking out and testing the PR! The error logs in the extension are unrelated to the issue. This PR is about fixing the CSP error messages for websites (not the extension itself). The screenshot you sent seems to be showing a pre-existing error. I could reproduce the same error messages in the console by running the current build from develop.

[DDDDDanica]

@itsyoboieltr thanks for the explanation, just to make sure it is not related, approve now !