Stylus: Firefox: styles are affected by CSP

[eight04]

Maybe the extension should add Content-Security-Policy: style-src 'unsafe-inline' to response header.

[tophf]

We don't use webRequest API so we can't modify the site's CSP. This is the first time such issue is reported during the lifetime of Stylish or Stylus. Please elaborate, provide the details, an example URL, etc.

[eight04]

Since the styles were injected into DOM as inline-style elements, they are affected by CSP rules. For example, you can't apply any styles to https://content-security-policy.com/browser-test/, which forbids inline style. And you can see the error message in the console:

Here is the style I created for testing:

@-moz-document url-prefix("https://content-security-policy.com/browser-test/") {
/*csp test*/ body {background: black!important;}
}

Or maybe to use tabs.insertCSS.

Firefox Version 55.0b12

[tophf]

Well, since we don't use webRequest, we don't want to add this API to our permissions just for a couple of sites that block inline style elements apparently just to prove the point it's possible. We'll have to do something only if there are major/popular sites affected, but there were no such reports over the years I've been using/developing Stylish-for-chrome.

As for tabs.insertCSS, it's a dead end, unfortunately: this method is too unwieldy, dumb actually. No way to remove the CSS in Chrome (supported only in Firefox), no way to selectively toggle the inserted styles thus we would have to store a copy of the inserted CSS string in our background page and reinsert the whole nine yards when just a single style is toggled. Imagine how that would work with many open tabs and many styles. Could we insert each style separately? Many async requests for each style on each tab instead of just one per tab currently. And we'd still have to store the previously inserted CSS string for the case of an updated/edited style. Unusable.

[tophf]

It's possible to add webRequest to optional permissions, though, so I guess it's worth implementing.

[da-moo]

Just chiming in to say that this is affecting a site that I use frequently, and I can't use Stylus on it. The site is overcast.fm.

Here is the error I get (similar to the one posted by @eight04) :

[tophf]

Stylus works on overcast.fm in Chrome so evidently it's just another weird FF bug.

[pointlessone]

There are legitimate use cases for blocking inline styles. For instance crates.io (it's a package repository for Rust programming language). It displays formatted ReadMes for packages and ultimately has no control over what's in those ReadMes. But they want to eliminate a possibility of page manipulation either with JS or styles so they block inline (and foreign) scripts/styles.

There are many sites that display user-submitted content and should probably do the same cates.io does.

@tophf You've marked this issue as FF-specific. Is there a Bugzilla ticket for this "another weird FF bug"? I'd like to track progress on their side as well.

[tophf]

But they want to eliminate a possibility of page manipulation either with JS or styles so they block inline (and foreign) scripts/styles.

Meaningless effort. If a user wants to apply styles, it's their choice regardless of what a site designer wants. Which is why Stylish/Stylus and similar extensions thrive. Also, the classic Stylish changed appearance without injecting style elements and no site could prevent that.

There are many sites that display user-submitted content and should probably do the same cates.io does.

Also futile effort. Both Chrome and the classic FF before 57 (the two major browsers) can apply styles circumventing site CSP.

You've marked this issue as FF-specific.

Because it is Firefox-specific. There's no problem in the original Chrome API.

Is there a Bugzilla ticket for this "another weird FF bug"?

There are lots of WebExtension-related issues, some of them might not be even reported on their bugzilla. Here's the two I have in my history: https://bugzil.la/1267027 and https://bugzil.la/1411641

WebExtensions is still a buggy work-in-progress so no wonder users without knowledge of the internals start to think this is the intended behavior... I don't care about it much, but since it was easy to implement we're testing tabs.insertCSS approach which will circumvent the issue reported here.

[ghost]

Coming across more and more sites with CSP preventing styling with Firefox, even from within the FF developer toolbox (inspector). Disabling csp in about:config permits styling, though reckon that should not be the solution. If however CSP becomes a trend and no workaround available then this extention becomes obsolete/extinct, at least with FF

[tophf]

@n8v8R, not a problem at all: 1) CSP is not an issue in Chrome, 2) we're testing a new version that's not affected by CSP in Firefox and 3) extensions can easily modify page CSP via webRequest API.

[tophf]

Firefox 59 finally fixed this bug so I don't think we should do anything. Users of the older Firefox can install a separate extension that alters CSP.

[serjflint]

Firefox 63.0.4, Firefox 64.0b12
https://paste.fizi.ca/*
Content Security Policy: Parameters of the page blocked the loading of the resource inline («style-src»).