Open Bug 1367161 Opened 7 years ago Updated 1 year ago

Implement contentSettings API for Javascript


(WebExtensions :: General, enhancement, P5)

54 Branch


(Not tracked)


(Reporter: geoffreydebelie, Unassigned)



(Whiteboard: [triaged])

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170501203640

Steps to reproduce:

Allow WebExtensions to disable JavaScript for a specific domain with some API (to be determined, maybe pageSettings).

See comment 9 in bug 1363859
Priority: -- → P5
Whiteboard: [triaged]
I kindly ask you to track this bug. Firefox 57 will be the first release that allows only WebExtension based addons. Many users (myself included) rely on switching JavaScript on and off for different reasons.

While JavaScript can be blocked via CSP, it is not really turned off. As a result <noscript> will not be rendered. 

The number of users that have addons installed which turn JS off is more than 1.7 million for the famous NoScript addon alone.
This was triaged by the add-ons team months ago, I'm not going to second-guess them so not tracking for 57.
IMO this is a duplicate of bug #1392090.
Also, in bug #1392090, comment #5  I've summarised what it seems the situation currently is with uMatrix and uBlock and link to their tracking issues.

It seems it is, in fact, possible for an addon to flag a docshell as non-javascript, so uMatrix could, for example, set as non-javascript, but flag an iframe under it to, oh, as javascript.  bz commented to this effect in the uBlock bug.

That said, using CSP as a flag to parse <noscript> does seem super reasonable, so while the fact that uMatrix is broken right now kinda seems to be due to their failure to implement the existing flag, there's no reason I can see that the uMatrix/uBlock CSP filtering should not be handled the same way in Firefox...
Well. I guess to be fair, since this one was filed first, it takes precedence... The other bug sure is more specific tho 
The chrome.contentSettings.javascript API lets you do that:
Ever confirmed: true
Summary: Allow WebExtensions to disable JavaScript for a specific domain → Implement contentSettings API for Javascript
Just wanted to mention something I noticed as of a recent NoScript webextension update... bug 1392090, comment 14
As I am still in need of a fix for this bug - waiting on 52 ESR right now without possibilty to upgrade to any Quantum based version - I tried my best and took my first look at FF source code ever.

At this point, there are in my opinion some alternatives to workaround or fix this bug. Here they are, sorted from simple to complicated:

0.) -- TEMPORARY WORKAROUND ONLY! -- Try to parse <noscript> elements if your extension has any impact on JS behaviour. 

This is what NoScript currently does. NoScript uses a basic "getElements", then adds a <div> and changes its innerHTML to that of the <noscript> element. There is some logic to include the parsing of <meta http-equiv="refresh"> stuff.

- It is a hack that has hackish results. (wrong css applied for example).
- Incomplete functionality
- Every extension has to include its own logic for this to work.
- <div> has no semantic meaning, <noscript> has a very clear, well known meaning.

- No bugfix required.

Funny note: I tried to do the same thing months before NoScript, but my addon was rejected because it failed review. I was told that this practice was insecure because of unsanitized code. I have yet to find NoScripts function to sanitize the html.

1.) Allow the webExtension API "browserSettings" to change the state of JS. 

This is a very simple solution. Actually one only needs to add 9 lines of code (!) to make this work.

In "toolkit/components/extensions/ext-browserSettings.js" you need to add

enableJS: getSettingsAPI(extension,
  () => {
    return Services.prefs.getBoolPref("javascript.enabled");

and in "toolkit/components/extensions/schemas/browser_settings.json"

"enableJS": {
  "$ref": "types.Setting",
  "description": "Enable/Disable JS"

A webExtension based addon can now toggle JS in whatever context they want (based on URL, domain, for all sites...) with the browserSettings.enableJS API.

Here is an example:

function toggleJS() {

  function toggle(current) {
    console.log(`Current value: ${current.value}`);
    console.log(`Current level of control: ${current.levelOfControl}`);
    console.log(`New value: ${!current.value}`);
    browser.browserSettings.enableJS.set({value: !current.value});


browser.browserAction.onClicked.addListener(() => {

- "Old way" of disableing JS (as used by many JS deactivating addons: they had a domain/page list and changed the setting on every location or tab/change)

- Simple.
- Can be implemented right now.
- Works as expected (disables JS as a "browserSetting").

No Drawbeck:
- Can be abused like every "browserSetting".
For example: setup a database for an extension and toggle Notifications based on domain or URL.

2.) Implement the contentSettings API from chrome.

I already figured that this API would basically be a way to toggle the permissionManager from FF.

However, FF does not have a native, page depended setting for JS.
Therefore one would not simply need to implement an API to toggle the Manager (which would probably be the easy part),
but also an API for the permissionManager to include JS.
(Or create a wrapper that would then again toggle the about:config entry...)

- Cannot be made to work right now.
- Complex solution.

- Should be the long term goal.
- "Correct" way.
Product: Toolkit → WebExtensions
Bulk move of bugs per
Component: Untriaged → General

What is the status of this enhancement?

Flags: needinfo?(kmaglione+bmo)

As a P5 this is a bug that we would welcome a patch for, but are not planning on implementing.

Flags: needinfo?(kmaglione+bmo)

How is this a bug, isn't it an enhancement? And suppose I wanted to submit the code for it, can you tell me the guidelines as to how to submit the code and the checks you people do, I am new here.

Flags: needinfo?(ddurst)
Flags: needinfo?(thedurst)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.