1410511 - userContent.css and userChrome.css are not consistently applied

Status: UNCONFIRMED

(Core :: CSS Parsing and Computation, defect, P3)

Description

[quality+bugzilla]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171019140425

Steps to reproduce:

Created a userContent.css and userChrome.css and placed them in the appropriate folder.

The application of the CSS code within userContent.css and userChrome.css should always be applied.

Up until Firefox 57, this works as expected.  However, starting with Firefox 57, it does not.


Actual results:

With Firefox 57 (tested with Beta 10), sometimes parts of the CSS code within userContent.css and userChrome.css are not consistently applied.

It appears to be random when the CSS code from userContent.css and userChrom.css gets applied.  Hence, I suspect a race condition is involved.

Interestingly, refreshing the page (whether a web page, or a moz-extension page generated by an extension) often causes the CSS code to get applied.  Sometimes refreshing the page more than once is needed to get the CSS code applied.  This further supports the possibility that a race condition is involved.


Expected results:

The CSS code within userContent.css and userChrome.css should be applied consistently.

Comment 1

[Tooru Fujisawa [:arai]]

maybe similar to bug 1394233?
can you open about:support and check the status of multiprocess and style?
also, what's the example of the not-applied parts?

Comment 2

[Tooru Fujisawa [:arai]]

(In reply to Tooru Fujisawa [:arai] from comment #1)
> can you open about:support and check the status of multiprocess and style?

*stylo

Comment 3

[quality+bugzilla]

(In reply to Tooru Fujisawa [:arai] from comment #1)
> maybe similar to bug 1394233?
> can you open about:support and check the status of multiprocess and stylo?

Multiprocess Windows 	1/1 (Enabled by default)
Stylo 	true (enabled by default)

I'll post an example as soon as I have a little time.  Note that the styles get applied sometimes and not other times (with nothing changing), so testing will take a little patience and repeated attempts.

Comment 4

[quality+bugzilla]

If I wait until I have time, I'll never have the time... so I put together an easily reproducible case now.

Here is an example that is easy to reproduce.  Tested on Firefox 57.0 Beta 12.

Steps to reproduce:
1. Install the uBlock Origin (uBo) extension
2. Observe the UUID for the uBo dashboard
3. Copy the UUID into the code below
4. Close Firefox
5. Copy the code below (with the appropriate UUID) into userContent.css
6. Save userContent.css in the chrome folder within the profile
7. Open Firefox
8. Open the uBo dashboard
9. Click on the 'My Filters' tab
10. Notice that the textarea containing the filters either fills the entire page, or does not (depending on whether the CSS in userContent.css is getting applied)
11. Refresh the page
12. Repeat steps 10 and 11 as needed to reproduce the bug


Code for userContent.css:
/* uBlock Origin extension dashboard 'My Filters' tab: improve usability */
@-moz-document url("moz-extension://INSERT UUID HERE/1p-filters.html") {
/* HTML and BODY: set heights for entire viewport so child objects will have a reference height to use percentages */
HTML, BODY { height: 100%; }
/* BODY: remove bottom padding to allow more room for data */
BODY { padding-bottom: 0 !important; }
/* increase height of filters textarea so more filters can be displayed (requires HTML and BODY to have a defined height) */
BODY > P:nth-of-type(3) {
   margin-top: 2px !important; margin-bottom: 2px !important; height: calc(100% - 14.9ex) !important; }
.userFilters { height: 100% !important; }
}

Comment 5

[sandthorn]

Platform: Firefox 57 beta12 nightly 27 OCT 2017 64-bit Windows

Symtoms:

1. My userChrome.css is applied as expected:

#urlbar { 
	font-size: medium !important;
}

2. All @font-face replacement of local('font name') 
in my userContent.css are ignored:

@font-face { font-family: 'sans-serif'; src: local('font name'); font-weight:normal; font-style: normal; }

I've opened a ticket on @font-face ignored at 1412624.
https://bugzilla.mozilla.org/show_bug.cgi?id=1412624

Comment 6

[sandthorn]

Additional info:
Multiprocess Windows 	1/1 (Enabled by user)
Stylo  I tried both, they render the same.

Comment 7

[Jon Gjengset]

I'm not sure if this is exactly the same, but userChrome.css is also not applied to chrome://browser/content/browser.xul, which I found surprising.

Comment 8

[Jon Gjengset]

Another (perhaps) related issue:

    :root:-moz-lwtheme { --toolbox-border-bottom-color: none; }

does nothing when added to userChrome.css, but applies correctly to chrome://browser/content/browser.xul.

Comment 9

[Jon Gjengset]

(In reply to jon from comment #8)
> Another (perhaps) related issue:
> 
>     :root:-moz-lwtheme { --toolbox-border-bottom-color: none; }
> 
> does nothing when added to userChrome.css, but applies correctly to
> chrome://browser/content/browser.xul.

Looking further into this, it seems like userChrome.css is not allowed to override CSS variables at all.

Comment 10

[sandthorn]

My issue is resolved by exit Firefox, delete prefs.js, restart Firefox again.

@font-face { font-family: 'sans-serif'; src: local('font name'); font-weight:normal; font-style: normal; }

Now @font-face is replacing as expected.

Comment 11

[K]

Not sure if same bug, but probably related - in Linux Firefox 57 release multiprocess enabled image for background from userContent.css doesn't work. Disabling multiprocess makes the image appear, enabling/disabling Stylo doesn't make a change.

Comment 12

[MarjaE]

I think I'm running into the same problem. user css and user styles which used to work sometimes stops working. I suspect an issue with @-moz-document

For example, a few weeks ago this blocked Twitter backgrounds:

@-moz-document domain("twitter.com") {
.PermalinkOverlay-with-background { background: white !important; }
}

And this changed Tumblr background colors:

https://userstyles.org/styles/77659/green-and-grey-for-tumblr-dash

As of now neither one works in FF 61.

Comment 13

[K]

(In reply to MarjaE from comment #12)
> I think I'm running into the same problem. user css and user styles which
> used to work sometimes stops working. I suspect an issue with @-moz-document

It might be related to this: 
https://bugzilla.mozilla.org/show_bug.cgi?id=798137#c8

Comment 14

[Emilio Cobos Álvarez (:emilio)]

(In reply to K from comment #11)
> Not sure if same bug, but probably related - in Linux Firefox 57 release
> multiprocess enabled image for background from userContent.css doesn't work.
> Disabling multiprocess makes the image appear, enabling/disabling Stylo
> doesn't make a change.

This is likely due to the sandbox, if you can file a different bug for this it'd be appreciated.

(In reply to MarjaE from comment #12)
> I think I'm running into the same problem. user css and user styles which
> used to work sometimes stops working. I suspect an issue with @-moz-document

Is it intermittent or something? Looks like it works for me locally. If it's reproducible, could you file a different bug for this with the precise STR and ni? me? I can take a look :)

Comment 15

[K]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #14)
> This is likely due to the sandbox, if you can file a different bug for this
> it'd be appreciated.

It was, indeed. 
https://bugzilla.mozilla.org/show_bug.cgi?id=1422570
It is fixed now, although it wasn't really a bug, mostly me not understanding the system.

Comment 16

[MarjaE]

It's not intermittent, but it applies to some fixes on some sites, and not others. Some failed months ago, some days ago. The biggest problems emerged after I had to disable and re-enable stylus, and one of my old user styles hasn't worked since, and adding it to user chrome hasn't worked either...

Comment 17

[Masatoshi Kimura [:emk]]

(In reply to MarjaE from comment #16)
> It's not intermittent, but it applies to some fixes on some sites, and not
> others. Some failed months ago, some days ago.

If you can reproduce it reliably, could find a regression range? In any case, please file a new bug instead of taking over an existing bug.

> The biggest problems emerged
> after I had to disable and re-enable stylus, and one of my old user styles
> hasn't worked since, and adding it to user chrome hasn't worked either...

Oh, are you using Stylus to apply user styles? It is a completely different thing from userContent.css from developer's perspective, so certainly a new bug should be filed.

Comment 18

[Matěj Cepl]

I think we are getting on tangent here. Could we return to some simple non-problematic example? Let see if I can provide one.

This is my /home/matej/.mozilla/firefox/r7f7tog2.default/chrome/userContent.css (using Mozilla/5.0 (X11; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0 from the mozilla.org binaries, build ID 20180704003137), and variable layout.css.moz-document.content.enabled is set to true):

@-moz-document domain(build.opensuse.org/) {
body {
        background-color: green !important;
    }
}

(the same happens when I use @document rule instead of @-moz-document). If I comment out the first and the last line and enter https://build.opensuse.org/ its background is green. If reset userContent.css back to this state, nothing happens, and there are no error messages in the console.

What's going on?

Comment 19

[Alice0775 White]

(In reply to Matěj Cepl from comment #18)
> I think we are getting on tangent here. Could we return to some simple
> non-problematic example? Let see if I can provide one.
> 
> This is my
> /home/matej/.mozilla/firefox/r7f7tog2.default/chrome/userContent.css (using
> Mozilla/5.0 (X11; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0 from
> the mozilla.org binaries, build ID 20180704003137), and variable
> layout.css.moz-document.content.enabled is set to true):
> 
> @-moz-document domain(build.opensuse.org/) {
> body {
>         background-color: green !important;
>     }
> }
> 
> (the same happens when I use @document rule instead of @-moz-document). If I
> comment out the first and the last line and enter
> https://build.opensuse.org/ its background is green. If reset
> userContent.css back to this state, nothing happens, and there are no error
> messages in the console.
> 
> What's going on?


The following line is wrong.
@-moz-document domain(build.opensuse.org/) {

It should be
@-moz-document domain(build.opensuse.org) {


Then, Firefox(Linux Mint) works as expected without changing of layout.css.moz-document.content.enabled

Comment 20

[Matěj Cepl]

(In reply to Alice0775 White from comment #19)
> The following line is wrong.
> @-moz-document domain(build.opensuse.org/) {
> 
> It should be
> @-moz-document domain(build.opensuse.org) {
> 
> Then, Firefox(Linux Mint) works as expected without changing of
> layout.css.moz-document.content.enabled

Yes, you are right, it's PEBKAC, sorry.

Isn't @document supposed to work 61.*? It doesn't here, even with the option enabled.

However, we are loosing the point in this bug. What's the issue here?

Comment 21

[MarjaE]

Not working in threadreaderapp either.

Since (a) common web design practices, such as having objects zoom or jump on mouseover, aren't safe and (b) Firefox's own settings do not provide enough ways for users to block these, (c) we may need working user css to use the web without getting hurt all the time.