Gestures not working on some pages (Gesturefy is blocked by the page's Content-Security-Policy)

[beelze]

Well, I know about amazing WE limitations which [after all] prohibits closing or navigating in special/mozilla pages, but here's another one case – raw github pages. Yet another Mozilla's paranoia attack?

[Robbendebiene]

Yet another Mozilla's paranoia attack?

Your guess is quite right: https://stackoverflow.com/questions/47622435/firefox-content-script-not-loading-in-some-pages/47705529 It's a long known problem, but they plan to fix it.

[beelze]

It is good for safety to chop off user's hands. A little offtopic, but is there known related bugs on Bugzilla@Mozilla? I mean it is nonsense to consider close/navigate with keypress/mouseclick – safe, but do the same with gestures – unsafe. At least I can vote somewhere.

[Robbendebiene]

The related bugs are:
https://bugzilla.mozilla.org/show_bug.cgi?id=1267027
https://bugzilla.mozilla.org/show_bug.cgi?id=1411641

[Hubcapp]

cool, so to get around this (mostly) i can just toggle security.csp.enable permanently false, thanks. 👍

[nolnolnolnol]

Gesture also does not work on loading pages and connection failed pages.
For loading page, After I click "X" button to stop loading page, gesture could work.

[Robbendebiene]

@nolnolnolnol There is nothing extension developers can do about that. This is also partially stated in the add-on description limitations section.

[ygoe]

Same issue here? https://archive.newsletter2go.com/?n2g=t3umlphz-doffwyqv-jrg

[Robbendebiene]

@ygoe This seems to be a different problem. I've created a ticket on bugzilla.

[Robbendebiene]

@ygoe I've implemented a workaround for your particular problem. So the page you've provided should now work with Gesturefy 3.2.1 . However the problem that this issue is about does still exist.

[Robbendebiene]

As #258 (comment) no longer works - For testing purposes one can disable the sandbox CSP directive that blocks e.g. Gesturefy by using this extensions code:

1. Create the files manifest.json and background.js
2. Open about:debugging#/runtime/this-firefox in Firefox
3. Click "Load temporary add-on"
4. Select the manifest.json
5. Gesturefy should now work on sites like https://linux-audit.com/

manifest.json

{
  "manifest_version": 2,
  "name": "Disable CSP Sandbox",
  "version": "0.0.1",
  "description": "Removes the sandbox directive from the Content-Security-Policy header.",
  "permissions": [
    "<all_urls>",
    "webRequest",
    "webRequestBlocking"
  ],
  "background" : {
    "scripts" : ["background.js"]
  }
}

background.js

browser.webRequest.onHeadersReceived.addListener(
  onHeadersReceived,
  {
    'urls': ['<all_urls>']
  },
  ["blocking" ,"responseHeaders"]
);

async function onHeadersReceived(details) {
  const sandboxCSPMatcher = /sandbox[a-zA-Z0-9\-\s]*;?/;
  const csp = details.responseHeaders.find((item) => 
    item.name.toLowerCase() === 'content-security-policy' && 
    sandboxCSPMatcher.test(item.value)
  );
  if (csp) {
    console.log('REMOVE SANDBOX CSP');
    console.log(csp);
    // remove sandbox directive
    csp.value = csp.value.replace(sandboxCSPMatcher, '');
    return {
      responseHeaders: details.responseHeaders
    };
  }
}

[ygoe]

Interesting. Now that I read about the issue, I remember I couldn't use my user script on a website with FireMonkey as well, so I used another add-on called "simple-modify-headers" to delete that header on that particular domain. Then it worked. (Maybe the problem was specific to my script that loaded additional .js files from a local server to use their functions.) Obviously this isn't practical to configure for all "offending" sites. But a general header rule for all sites should also be possible. So, no need to write a new add-on for that, it already exists. :-)

Maybe your add-on idea could also be improved to something that removes the problematic "sandbox" part only and, if needed, replaces it with similar but functional other options that at least keep up as much security as possible. That could then be appropriate for everyday use.

BTW, @Robbendebiene have you linked to our issues here in their bugs? I can't seem to recognise any progress there. Those two Firefox bugs are becoming a never-resolved thing. Open for 20 or 30 years with no progress. They have a few of those.

[Robbendebiene]

Interesting. Now that I read about the issue, I remember I couldn't use my user script on a website with FireMonkey as well, so I used another add-on called "simple-modify-headers" to delete that header on that particular domain. Then it worked. (Maybe the problem was specific to my script that loaded additional .js files from a local server to use their functions.) Obviously this isn't practical to configure for all "offending" sites. But a general header rule for all sites should also be possible. So, no need to write a new add-on for that, it already exists. :-)

I didn't know about simple-modify-headers. Thanks for sharing that :)

Maybe your add-on idea could also be improved to something that removes the problematic "sandbox" part only and, if needed, replaces it with similar but functional other options that at least keep up as much security as possible. That could then be appropriate for everyday use.

The little extension I quickly coded up only removes the sandbox directive from the CSP and keeps all the other ones untouched (at least that was my intention)

BTW, @Robbendebiene have you linked to our issues here in their bugs? I can't seem to recognise any progress there. Those two Firefox bugs are becoming a never-resolved thing. Open for 20 or 30 years with no progress. They have a few of those.

No, I'd rather suggest voting on the bugs. My hope is that they will resolve this with the completion of the new manifest V3 API. Let's see 🤞

[Robbendebiene]

The bug is fixed in Firefox 128 🎉

Unfortunately there is still something missing which causes Gesturefy's popup commands to fail (see https://bugzilla.mozilla.org/show_bug.cgi?id=1896824)