Enable executeScript restriction on extension pages on all channels

As a followup to Bug 2011234, we plan to enable the restriction on all channel as part of the Firefox 152 cycle and let it ride the train (in the meantime the restriction is enabled on Nightly builds by default and a deprecation warning logged in the target extension page when the restriction is being hit).

The bug 2011234 says it's blocking dynamic code execution, but from what I can see, even fixed code execution is blocked.
Is this really intended behavior?

(In reply to juraj.masiar from comment #1)

The bug 2011234 says it's blocking dynamic code execution, but from what I can see, even fixed code execution is blocked.
Is this really intended behavior?

Yes, this is intentional. Access control is based on the target of the execution, and we wanted to consistently apply the change to the all methods without exceptions. And unlike tabs.executeScript, we never documented that scripting.executeScript allows execution in extension documents. Here is the relevant diff of the documentation change:

• scripting.executeScript (added information only, without deletions): https://github.com/mdn/content/pull/43108/files#diff-4448cf7eb023b27ee11e787fb3ee7463c49ca69d8dc18c64e90ed567dba66839
• tabs.executeScript (deleted mention of support in extension documents along with adding notes): https://github.com/mdn/content/pull/43108/files#diff-5deb2dfa11563fd0afc3bfcb77db087458086d22e30c9cb34fd7afd2fe326df3

But why restrict it for the modern scripting namespace at all?
It doesn't allow any dynamic code execution, that was the whole point of MV3.

Being able to use "any" extension API on your own extension tabs is a huge consistency help.
The fact that it wasn't documented is not a good argument as most API doesn't state this, because why should they get a special treatment? It's like updating tabs.setZoom documentation and writing that it works on extensions pages...

I understand the security reasoning in the tabs namespace, but I don't see it helping anyone on already secure scripting namespace.
All I see now is a lot of code I need to change in multiple of my addons :(, and I'm sure it's not just me.

dev-doc-needed: The deprecation announced in 149 is now enforced by default in 152, so it should be added to https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/152

(not to be documented on MDN, but good to know:) Users who discover too late of the breakage due to the extension authors having missed the deprecation announcement can temporarily get their extension working again by flipping the preference back to true. This preference is not expected to be long-lived, however! It will be removed in bug 2039393.

For future reference, here is the analysis of telemetry data to assess the potential impact of the deprecation.
I looked at telemetry (added in bug 2011234) to detect affected extensions, from the past two weeks:

• ~800 extensions inject in top-level moz-extension documents: https://sql.telemetry.mozilla.org/queries/119850
• ~120 (overlaps with other group) inject in extension frames: https://sql.telemetry.mozilla.org/queries/119860

I took a sample of 64 add-ons with at least 100 users among the items at https://sql.telemetry.mozilla.org/queries/119850 and analyzed them.
Most of the injections are unintentional. Only 7 were conclusively affected by the change.

• Tree Style Tabs, fixed by https://github.com/piroor/treestyletab/issues/3867
• Tridactyl, tracked at https://github.com/tridactyl/tridactyl/issues/5368
• Sidebery, fixed by https://github.com/mbnuqw/sidebery/issues/2356 (I have already provided feedback to the extension developer before in that thread; this information may be of interest to other extension developers who were also using executeScript in an extension document as a work-around for the tab getting closed on update)
• "Formatta fattura elettronica" - version 1.15 calls tabs.executeScript with a file, in an extension tab that it had just opened.
• Quick Dial, reported at https://github.com/MatMoul/quickdial-webext/issues/192
• RSS Sage-like, appears to already be fixed: https://github.com/arielgee/Sage-Like/commit/6caed50af1020af442d9f0ce158d88bdaf985940
• Web pages scanner, non-core functionality impacted, reported at https://github.com/WaldiPL/webpageScanner/issues/94
• Conex, reported at https://github.com/kesselborn/conex/issues/341 . The extension was last updated 7 years ago, so odds are that this extension won't be fixed.
• Pywalfox, uses insertCSS (not executeScript). Reported at https://github.com/Frewacom/pywalfox/issues/168

https://hg.mozilla.org/mozilla-central/rev/f956769dfb91

Release note added in PR [https://github.com/mdn/content/pull/44123) #44123

(In reply to juraj.masiar from comment #3)

But why restrict it for the modern scripting namespace at all?
It doesn't allow any dynamic code execution, that was the whole point of MV3.

Mainly for consistency within the APIs and across browsers. insertCSS is not as dangerous either, but we still treat it the same as executeScript. And with this enforcement, we also don't need to be concerned with content scripts having access to higher privileged APIs than they usually do.

The data I analyzed (comment 5) shows that the vast majority of executions in extension documents are not intentional, and those that are were able to migrate to alternatives. That comment only enumerates extensions "negatively" impacted by the deprecation. An example of an extension that would positively have been impacted is shown in https://bugzilla.mozilla.org/show_bug.cgi?id=2011234#c2