userContent.css and userChrome.css are not consistently applied

UNCONFIRMED
Unassigned

Status

()

Core
CSS Parsing and Computation
P3
normal
UNCONFIRMED
a month ago
4 days ago

People

(Reporter: quality+bugzilla, Unassigned)

Tracking

57 Branch
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

a month ago
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.
(Reporter)

Updated

a month ago
OS: Unspecified → Windows 7
Hardware: Unspecified → x86_64
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?
Flags: needinfo?(quality+bugzilla)
(In reply to Tooru Fujisawa [:arai] from comment #1)
> can you open about:support and check the status of multiprocess and style?

*stylo
Component: Untriaged → CSS Parsing and Computation
Product: Firefox → Core
(Reporter)

Comment 3

24 days ago
(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.
Flags: needinfo?(quality+bugzilla)
(Reporter)

Comment 4

24 days ago
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

22 days ago
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

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

Updated

7 days ago
Priority: -- → P3

Comment 7

6 days ago
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

6 days ago
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

5 days ago
(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

5 days ago
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

4 days ago
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.
You need to log in before you can comment on or make changes to this bug.