(In reply to Giorgio Maone [:mao] from comment #29)

(In reply to Jet from comment #28)

(In reply to kernp25 from comment #27)

Firefox screenshots also does not work!

It works fine here with 60.x and 61.x and 62.0b5 all (64-bit) on Windows 10
1709,

Are you sure you're talking in the context of this bug?
Anything that relies on content scripts, including Mozilla's internal
add-ons which more and more Firefox features are based on like Screenshots,
are broken by this:

1. Open https://www.dropbox.com/help/security/enable-two-step-verification
2. Try to take a screenshot from the Page Actions menu (the drop-down from
   the navigation bar)
3. Watch the notification "Whoa! Firefox Screenshots went haywire."

Reproducible on both Firefox 61, 62.0b5 and Nightly 63.0a1 (2018-07-05).

I've just tried this, going through exactly the steps you have provided. On Firefox 67.0.4 (64-bit), Windows 10, taking a screenshot of that page works for me (clicking on the three dots inside the address bar to get the option "Take a screenshot"). Has anything been fixed in Firefox? Or has the Dropbox page dropped its CSP or anything?

Here's another repro:

1. Install https://addons.mozilla.org/en-US/firefox/addon/styl-us/
2. Install https://raw.githubusercontent.com/StylishThemes/GitHub-Dark/master/github-dark.user.css
3. Open https://raw.githubusercontent.com/StylishThemes/GitHub-Dark/master/package.json
4. Notice page is unstyled, should be white text on dark background

My current workaround is to remove the CSP "sandbox" directive via https://addons.mozilla.org/en-US/firefox/addon/header-editor/.

Test file illustrating inability to inject into sandboxed page

I looked into this a little bit. The reason why we fail to apply the content-script to pages with a sandbox CSP directive is simple. Such pages get a null principal. In MozDocumentMatcher::Matches we allow about:blank to match with a null-principal. (And also seemingly for data: URIs, which is not documented!)
But because this isn't the case here we are rejecting the principal in WebExtensionPolicy::IsRestrictedDoc.

I found this test page for testing CSP sandboxing.

Detailed manual test case to explore more conditions (source code of page hosted at https://robwu.nl/s/content-script-sandbox/ + extension to test with):

• same-origin iframe
• cross-origin iframe
• srcdoc iframe
• data:-URL iframe.

With the following combinations:

• sandbox="" (=unique origin).
• sandbox="allow-scripts" (just to confirm that injection didn't fail due to scripts being blocked)
  (for blob:-URLs I also added sandbox="allow-same-origin" variants to )
• No sandbox (=origin of the page).

Firefox 78's current behavior is to only run content scripts in:

• http(s), but only if not sandboxed.
• srcdoc frames, but only if not sandboxed.
• same-origin blob:-URLs.
• (no content scripts in data:-URLs - bug 1475831)
• (no content scripts in sandboxed pages - this bug (bug 1475831))

Chromium 86.0.4215.0's current behavior is:

• http(s), including sandboxed pages.
• srcdoc frames, but only if not sandboxed.
• no content scripts in blob: or filesystem: URLs.
• no content scripts in data:-URLs yet, but will be: https://bugs.chromium.org/p/chromium/issues/detail?id=55084#c45

Also, I would like to highlight the issue reported in Bug 1517017.

For iframes with sandbox="" in a moz-extension:// page with sandbox="", hosting cross-origin http/https URLs:

• Firefox 78 - Content scripts do NOT run. BUT changing sandbox to "allow-same-origin" allows content scripts to run.
• Chrome 86 - Content scripts do run.

Following discussion with Chrome (in crbug 55084, linked from bug 1475831#c16), the future injection behavior in Chrome is as follows:

• http(s) including sandboxed pages.
• about: (blank/srcdoc), blob: (and filesystem: - only supported in Chrome), data: if match_origin_as_fallback is true - see https://bugzilla.mozilla.org/show_bug.cgi?id=1475831#c16

In Firefox, we will follow the same behavior. This means that bug 1475831 should be fixed by implementing match_origin_as_fallback, and this bug should be fixed by considering the URL of the document when the origin is opaque (i.e. use document's http(s) URL when document principal is null principal). In case the document's URL does not represent the origin (e.g. about:, data:, ... opposed to http(s)), we would have to somehow determine the non-null origin that was responsible for creating the document. That will probably be handled in bug 1475831 (and if not, we should file a follow-up bug to support content scripts in sandboxed frames where the origin cannot be derived from the document's URL).

(In reply to Rob Wu [:robwu] from comment #43)

In case the document's URL does not represent the origin (e.g. about:, data:, ... opposed to http(s)), we would have to somehow determine the non-null origin that was responsible for creating the document. That will probably be handled in bug 1475831 (and if not, we should file a follow-up bug to support content scripts in sandboxed frames where the origin cannot be derived from the document's URL).

bug 1715167 introduces principal.precursorPrincipal that offers this information - https://searchfox.org/mozilla-central/rev/c12a59323ee46b29b90c9917a3a7a70ea714ffec/caps/nsIPrincipal.idl#550-563

see also https://github.com/uBlockOrigin/uBlock-issues/issues/2072
any suggestions?

Something must have changed recently, because raw.githubusercontent.com pages are now themed properly.

Still an issue for extensions. Problematic for many NoScript features.

This is not just an issue with tabs.executeScripts and content_scripts / contentScripts.register / userScripts.register,
but also an issue with the scripting.executeScript (and scripting.registerContentScripts) API.

I looked at this and finding something that works around this issue isn't hard, but the hard part is deciding when to do the unwrapping so that everything stays reasonable secure.

One approach would be handling this in DocInfo::Principal like this:

@@ -1035,7 +1046,14 @@ nsIPrincipal* DocInfo::Principal() const
         return aLoadInfo->TriggeringPrincipal();
       }
     };
-    mPrincipal.emplace(mObj.match(Matcher(*this)));
+
+    nsCOMPtr<nsIPrincipal> principal = mObj.match(Matcher(*this));
+    if (principal && !URL().InheritsPrincipal() && principal->GetIsNullPrincipal()) {
+      if (nsCOMPtr<nsIPrincipal> precursor = principal->GetPrecursorPrincipal()) {
+        principal = precursor;
+      }
+    }
+    mPrincipal.emplace(principal);
   }
   return

The function doesn't even have that many callers, with WebExtensionPolicy::IsRestrictedDoc being the important one that currently just denies any non content principals. For a more targeted fix we could also use the precursor principal there. Notably as well is that DocInfo::PrincipalURL would fallback to the document URL for non content principals in that scenario.