As an additional data point, it's also affecting styles injected via the `manifest.json` rules.

r509096 might be related

As per comment comment #2 cc'ing to the file owner and reviewer for more updates on this issue.

Thanks!

The cascading order is correct:

https://www.w3.org/TR/css-cascade-3/#cascading

https://developer.mozilla.org/en-US/docs/Web/CSS/Cascade#Cascading_order

What has changed is that style sheets injected by extensions are now treated as user style sheets.

DevTools must be modified to reflect the new priorities.

> I can "fix" this by applying !important to every single line in my CSS files but that seems suboptimal.

Why do you say that it's suboptimal?

If you're talking about performance of the browser itself, !important rules are no different than normal rules, they're just applied in the reverse order. It's not suboptimal at all.

I don't think anyone is arguing that user stylesheets should be higher priority than author stylesheets - I think the argument here is that treating extension stylesheets as user stylesheets is suboptimal for extension developers because extensions, by their nature, often involve modifying and tweaking existing code (including CSS styles) on existing sites.  Placing a typical extension CSS rule lower in priority than a typical rule on an existing site basically makes non-!important style rules useless for extensions.

The bigger issue here may be not how Chrome -should- treat extension stylesheets, but rather how it -has- in the past.  There are sure to be a great many extensions which will be negatively impacted by this change, including my own.  I'm fairly certain the only reason there hasn't been more pushback is because this change hasn't made it to a stable release channel.

Another interesting data point is tabs.insertCSS() in the WebExtensions API:
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/tabs/insertCSS

See "cssOrigin" - Firefox supports specifying the origin of the injected CSS, and when not supplied, defaults to author (rather than user).

Just another thing to think about...

Even before this change non-!important rules in extensions did not override author rules [1]

[1]: https://crrev.com/e4488e2/third_party/WebKit/Source/core/css/DocumentStyleSheetCollection.cpp#91

Are you using tabs.insertCSS?

#6: I'm not familiar with Chromium internals, but it effectively worked at the same level as author rules, as if included as the last stylesheet in the page.

I can't comment on correctness or standards, but I'm certain this will break most page-altering extensions.

#6 - Seconding #7, I believe they were treated as author stylesheets, which put them at the same priority as the embedded stylesheets on the page - so the outcome came down to the specificity of the rules.  Typically that means the extension styles win, since (at least in my case) I'm applying specific classes to elements, whereas the styles already present on the page are typically based on inheritance.

Unfortunately I can't provide a way to reproduce the issue, since the site in question on my end requires credentials, but I can whip up an example if it's needed.  Thanks for looking in to this.

#10: I'll be very happy if you provide an example.

#11: I've attached a dead-simple extension ["ChromeStyleTest.zip"] which is intended to turn the background on https://www.google.com red.

On Chrome 61 (stable), it behaves as expected ["Chrome 61 Stable.png"] because the CSS rule we're applying is more specific than the Google-applied rule ("html body" vs "body").  However, on Chrome 64 (canary), our rule is ignored ["Chrome 64 Canary.png"] since it's now lower-priority (user) than the Google rule (author).  The real trouble here is that even if we set an ID on the body tag and use that ID in the CSS rule, it would still be ignored, even though that's about as specific as you can get.  The -only- way to get our rule applied is to use !important.

I've read through a lot of the discussion and documentation that was build around this change, and I generally agree that having the -option- to inject styles as user-origin rather than author-origin is a good thing, but changing the default behavior yanks the rug out from under extension developers.  That's only made worse by the fact that we don't have a choice in that change - there's no way to switch things back to the way they were before this change.  I just fear that the "hopefully minimal breakage" will be more than minimal.

Let me know if there's anything else I can do to assist - thanks!

Deleted: Chrome 61 Stable.PNG 15.7 KB

	Chrome 61 Stable.PNG 15.7 KB View Download

Deleted: Chrome 64 Canary.PNG 15.4 KB

	Chrome 64 Canary.PNG 15.4 KB View Download

Deleted: ChromeStyleTest.zip 449 bytes

ChromeStyleTest.zip 449 bytes Download

#11: Thanks!

I see what the problem is now.

Why does the extension use a specificity hack rather than !important in the first place?

Using specificity isn't a hack. It's a proper use of cascading. Using !important is rather a hack by definition. 

#13: This is a rather contrived example, designed to show the issue with changing the priority.  In the actual extension I work on, it's not a "specificity hack" like adding "html" to the front of the selector - rather, we apply styles through CSS classes to elements we're adding to the web page.

The styles already present on the page include some very broad "reset" styles, which set margins/padding/borders/etc. to 0 for basically every HTML tag (div, span, table, etc.)  This works exactly as expected, where our styles are applied to our elements because the CSS class is a more specific selector than a tag-based one, but the reset styles are used where we don't specify a style.  That's the way CSS is supposed to be used, with more specific styles building on more general ones, as #14 mentioned.  However, with this change, these reset styles now override our class-based styles entirely, meaning we basically can't add margins, padding, borders, or most other styles to any element on the screen without also adding !important.

Basically, we're trying to cooperate and build on the CSS already in the page, rather than replace it entirely - if a style specified in the page is marked as !important, that SHOULD take priority over our CSS, unless we want to further override that with our own !important declaration.

Hopefully that clarifies the situation - thanks!

My extension also provides specific per-element overrides and additional styles in content that has lots of broad "reset" styles. I use !important a handful of times where it's required, but adding it to every style rule - I have thousands - would be a real mess and would prevent me from using !important when I actually need it.

In practice if this bug persists I would just stop using insertCSS and manually insert raw style elements into the page, using a content script. In my experience this is a bit slower and creates flashes of unstyled content, which isn't great.

#15: Thanks for the clarification, this really helps.

I've uploaded a modified version of ChromeStyleTest.zip here that is a little more reflective of the issue.

Deleted: ChromeStyleTest.zip 1020 bytes

ChromeStyleTest.zip 1020 bytes Download

Reddit Enhancement Suite [1] (2.5MM users, if it matters) is also significantly affected by this change (disclosure: I'm one of the developers). Per #16 we'll just resort to injecting <style> elements if this change goes stable.

We're in a unique(ly bad) position here, as we want our styles to sit between two separate "categories" of author styles: above styles which are common across the site (which generally have low specificity), but below custom styles written by users of the site (which generally have high specificity). I realize this is a niche use-case, but I don't believe it's possible after this change.

Also, Firefox and Edge still treat extension stylesheets as author stylesheets (try ChromeStyleTest.zip), so extensions which inject CSS are less portable.

[1]: https://chrome.google.com/webstore/detail/reddit-enhancement-suite/kbmfpngjjgdllneeigpgjifpgocmfgmb

(deleted and reposted since I used the wrong account)

Deleted: CanaryOnTheRight.PNG 221 KB

	CanaryOnTheRight.PNG 221 KB View Download

I think this should be discussed with the Chromium team.

Please include some of the folks who were involved in the decision-making over  crbug.com/632009 

Speaking only for myself, I do see now that there are seemingly valid use cases for author style sheets in extensions and "!important" is no substitute. As things stand though the only option I see for extension developers is to inject the CSS directly into the page by adding a <style> element containing the code. This may not work on all pages though, especially those that prevent inline styles using CSP [1], but in those cases one could resort to using a data URI [2] or even loading the style sheet from a remote location (possibly served by the extension anyway by intercepting the request). In adversarial cases where the page tries to remove the injected CSS, there is the option of using Shadow DOM v0 similar to the way Adblock Plus does it [3].

[1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
[2]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs
[3]: https://github.com/adblockplus/adblockpluschrome/blob/9f593a8c9def5f3aac906e4fbc44370779b3352c/include.preload.js#L358

I previously tried loading my styles inside a shadow root but had problems with the styles not properly applying to the containing document. I got the impression style elements inside a shadow root are supposed to only apply to elements within the shadow DOM. Is that incorrect?

The proper solution would be to allow extensions to specify the origin - "author" or "user" - in chrome.tabs.insertCSS and in manifest.json.
BTW page CSP that forbids inline styles does not apply to style elements injected by an extension in Chrome, but does in Firefox.

Adblock Plus calls Element.createShadowRoot on document.documentElement (<html>) and then inserts a <shadow> element into the returned shadow root. It then adds a "::content" prefix to all the selectors so the styles actually apply to the host element.

I admit I'm still not very good at understanding how Shadow DOM works, but if I create a shadow root on the document element or the body element the viewport becomes black because shadow DOM suppresses rendering of the host element. Should I really be using the <shadow> element? I see now from messing around that adding one to the shadow root causes the host element to reappear (?) but MDN says this element is deprecated and shouldn't be used.

Would I need to apply ::content to all of my selectors? I have something like 60KB of css so while adding a new prefix to all of my selectors isn't as bad as adding !important to every rule, it's still kinda awful.

#24: A lot of the v0 stuff is deprecated [1]

You would have to use the "::content" prefix if you want the styles to apply to the "shadow host" (in this case <html>)

[1]: https://hayato.io/2016/shadowdomv1/

Closed shadow roots are nice (thanks!) but you can't attach a shadow root to the document element. The spec doesn't permit it on <html> so it seems like the Adblock Plus method is spec-violating and could break later. I could try to attach to <body> but there is no body element when my content script runs (I need to run as early as possible to inject script into the document before the document runs its own scripts).

#26, FWIW you can wait for <body> using a nonrecursive MutationObserver on <html> element:
  new MutationObserver(mutations => {
    if (mutations.some(m => [...m.addedNodes].includes(document.body))) {
      console.log('hey');
    }
  }).observe(document.documentElement, {childList: true});
The only nuisance is that MutationObserver coalesces mutations so by the time its callback is invoked, the body may have a [small] bunch of elements inside.

Why is the issue status still "unconfirmed"? Isn't it like absolutely obvious that the new behavior is not universally acceptable and should be reverted in favor of implementing a user-specified "origin" that can be "author" (default) or "user"?

Moved this to original  issue 632009 .

> I don't think anyone is arguing that user stylesheets should be higher priority than author stylesheets

Why do you inject stylesheets just to be overridden? Extension are privileged, webpages are not, extensions should be able to force styles onto webpages without leaving webpages a way to resist. Currently, there isn't a way to enforce element hiding from extension without patching page context JavaScript API.