1541233 - Stop loading userContent.css or userChrome.css by default unless a preference is set

Status: RESOLVED FIXED

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

Description

[Mike Conley (:mconley) (:⚙️)]

I think we're loading userContent.css in the parent process here: https://searchfox.org/mozilla-central/rev/44a212460990ffffecf50a8e972d3cbde2e7216b/layout/style/nsLayoutStylesheetCache.cpp#375-376

Even if it's not there, we're stat'ing for the file to check if it exists here: https://searchfox.org/mozilla-central/rev/44a212460990ffffecf50a8e972d3cbde2e7216b/layout/style/nsLayoutStylesheetCache.cpp#405

I suspect it makes no sense to support userContent.css in the parent process - not with e10s being the only supported configuration.

We end up only sending down the file URI here: https://searchfox.org/mozilla-central/rev/44a212460990ffffecf50a8e972d3cbde2e7216b/dom/ipc/ContentParent.cpp#2427-2434

So I suspect we can avoid loading it, and maybe we can assemble the file URI without actually doing a stat.

Comment 1

[Cameron McCormack (:heycam)]

Sounds reasonable.

Comment 2

[Mats Palmgren (inactive)]

Is there any reason to load userChrome.css in the content process?

Comment 3

[Mike Conley (:mconley) (:⚙️)]

(In reply to Mats Palmgren (:mats) from comment #2)

Is there any reason to load userChrome.css in the content process?

No, I don't believe so. I'd be surprised if we currently do that though... but I've been surprised before. :)

Comment 4

[Mike Conley (:mconley) (:⚙️)]

(In reply to Mats Palmgren (:mats) from comment #2)

Is there any reason to load userChrome.css in the content process?

It doesn't look to me like we actually do that: https://searchfox.org/mozilla-central/rev/ee3905439acbf81e9c829ece0b46d09d2fa26c5c/dom/ipc/ContentParent.cpp#2379-2385

Comment 5

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 1541233 - Stop loading userContent.css in the parent process. r?emilio

Comment 6

[Mike Conley (:mconley) (:⚙️)]

ni?ing for https://phabricator.services.mozilla.com/D28677#854116

Comment 7

[Emilio Cobos Álvarez (:emilio)]

replied there, thanks :)

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0e9ee7d2188b
Stop loading userContent.css in the parent process. r=emilio

Comment 9

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/0e9ee7d2188b

Comment 10

[Serge]

Hi, here.
I do understand that the next comment will be a bit untypical.
I am a member of so called heavy users, that like to style some sections of browser via userContent.css and userChrome.css
After the mentioned change none of CSS assigned via userContent.css, work on about:blabla (aka external) pages.

Are there any plans on restoring this and what about userChrome.css styling, is it on purge list as well?

Comment 11

[Emilio Cobos Álvarez (:emilio)]

For comment 10.

Mike, since this change only ended up having a perf benefit in users which actually use userContent.css, and some of those users seem to care about applying the styles in the parent process, we could consider reverting this, wdyt?

Your call in any case.

Comment 12

[Mike Conley (:mconley) (:⚙️)]

(In reply to Serge from comment #10)
Hi, Serge.

Which about: pages are you attempting to style with userContent.css?

Comment 13

[Mike Conley (:mconley) (:⚙️)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #11)

Mike, since this change only ended up having a perf benefit in users which actually use userContent.css, and some of those users seem to care about applying the styles in the parent process, we could consider reverting this, wdyt?

I guess I just want to understand what about: pages people are trying to style using userContent.css before making a call here, and why.

This will improve the start-up performance of folks who have userContent.css scripts. Presumably there's a set of users that want to be able to modify about: pages using userContent.css. There are also a set of users that only want to modify normal websites using userContent.css. I want to know if the use-cases of the former set of users is worth punishing the latter set of users with worse start-up performance.

Comment 14

[Serge]

Hi, Mike.

Mainly I use it for about:addons/ (chrome://mozapps/content/extensions/extensions.xul)

Here are typical goals that I try to achieve:

• extending Sidebar width to remove cropping on a specific locale
• making extension cards more compact (margin, padding etc)
• extending the width of the main page (to reduce the overall height of the extension list)
• restoring some hidden-by-default sections (for example "Recent updates" in the sidebar)

All-in-all those are small fixes that enhance the browsing experience, still, they are too small to be reported via Bugzilla.

Also, I use userContent.css to modify the appearance of some extensions (this works for now in Nightly).
This is a fairly complicated task: requires the knowledge of dev tools and some investigation in about:debugging.
The goal is to make extension styling consistent with the browser.

As for the custom styles for normal websites, I do not use userContent.css for such tasks.
To my knowledge, it's easier to use a separate extension for those.
At the same time those extensions do not have access to internal about: pages.

Comment 15

[Mike Conley (:mconley) (:⚙️)]

I see, thank you Serge. I think I understand.

I suspect based on how obscure the feature is, the population of users using userContent.css to customize web pages is quite small.

I suppose for now, the most prudent course of action would be to back this set of patches out, and try to encourage users that only want to style web pages to use something like Stylus(1) instead if they want to avoid this extra main-thread IO during start-up. The vast, vast majority of users that don't use userContent.css won't see much benefit from this patch anyways, and we should probably focus our efforts elsewhere to improve their lives rather than trying to make userContent.css performant.

Comment 16

[Mike Conley (:mconley) (:⚙️)]

Hoping to get an fxperf colleague to double-check my thinking here in comment 15. What do you think, florian?

Comment 17

[Mats Palmgren (inactive)]

Fwiw, I have quite the opposite opinion. I don't think being able to style about:
pages using userContent.css was an intentional feature. It was only ever intended
for styling web content, not browser UI. So the use cases listed in comment 14 seems
invalid to me. The MDN page says:

The file 'userContent.css' customizes Web pages, whereas 'userChrome.css' customizes chrome files
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Tutorial/Modifying_the_Default_Skin#Customize_with_userChrome.css

Could we perhaps add a pref for users like Serge that wants it loaded in
the parent process? (default disabled)

Comment 18

[Serge]

Mike,
I agree with you.
From my point of view, there is a little point to use userContent.css to style actual web pages if there are dedicated extensions for those.
Those extensions provide a more convenient way of styling things...
userContent.css is a go-to (wit no alternative for now) for internal pages.

As for performance, I sincerely believe that people that know(use) userContent.css are aware that performance may be affected if the file is used in "untypical way"...

Deeply sorry, but English isn't my first language so I'm a bit confused in terminology.
To sum up does this mean that styling of about: pages via userContent.css will remain possible for now?

UPD. A pref switch would be an ideal solution.

Comment 19

[Marco Castelluccio [:marco]]

Isn't the stat cost being paid by all users, even those who don't have the file, just to check if the file exists?

Comment 20

[Mike Conley (:mconley) (:⚙️)]

(In reply to Marco Castelluccio [:marco] from comment #19)

Isn't the stat cost being paid by all users, even those who don't have the file, just to check if the file exists?

Yes, that's true, though this patch didn't change that.

Comment 21

[[e-mail]]

Maybe userContent.css is not popular for web sites but it definitely is for displaying mails etc. in Thunderbird. Only via userContent.css. you can get rid of the stupid graphical quote bars by replacing them with common used quote marks (> sign). And also via userContent.css you can apply different colours for text and background in quoted text hence making quote levels easier to distinguish. All is gone now for Thunderbird trunk aka Daily. Which now is a major annoyance.

Comment 23

[Mike Conley (:mconley) (:⚙️)]

Okay, I spoke to Florian, and here's what we suggest:

1. We back out the patch as it is and re-open this bug
2. We repurpose this bug to introduce a new pref that enables both userContent.css / userChrome.css, and have it be disabled by default
3. Inform comm-central so that TB / SeaMonkey / etc can have that pref be enabled by default
4. Try to spread the news through the Firefox UI customization community that this pref exists and will need to be flipped in order for userChrome.css / userContent.css customizations to be applied

The end result will that for the vast majority of our users, we can avoid looking for both userContent.css and userChrome.css files, which will be better for start-up performance. For the users that needs these customizations, we're unfortunately adding a one-time interruption where they have to go flip a pref in about:config, but they get to opt-in to these customizations in exchange for start-up performance.

Comment 24

[Emilio Cobos Álvarez (:emilio)]

Backout is https://hg.mozilla.org/integration/mozilla-inbound/rev/06c42ef3ab2b

Comment 25

[Mike Conley (:mconley) (:⚙️)]

I think I'd like Mossop's opinion on the plan in comment 23 before I start trying to make this plan a reality.

Comment 26

[ruediger]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #23)

Okay, I spoke to Florian, and here's what we suggest:

1. We back out the patch as it is and re-open this bug
2. We repurpose this bug to introduce a new pref that enables both userContent.css / userChrome.css, and have it be disabled by default

Best decision. Thank you.

The end result will that for the vast majority of our users, we can avoid looking for both userContent.css and userChrome.css files, which will be better for start-up performance. For the users that needs these customizations, we're unfortunately adding a one-time interruption where they have to go flip a pref in about:config, but they get to opt-in to these customizations in exchange for start-up performance.

My FF-/TB-Trunk showed no better in start-up-time today.

Comment 27

[Dave Townsend [:mossop]]

Seems fine, maybe make sure and put it in the release notes and perhaps a blog somewhere

Comment 28

[wernerfp]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #23)

The end result will that for the vast majority of our users, we can avoid looking for both userContent.css and userChrome.css files, which will be better for start-up performance. For the users that needs these customizations, we're unfortunately adding a one-time interruption where they have to go flip a pref in about:config, but they get to opt-in to these customizations in exchange for start-up performance.

Firefox checks at start-up which files and directories are present or not present in the user profile. If the directory "chrome" doesn't exist, the user logically doesn't want any customization via userContent.css and userChrome.css.

Firefox checks the existence of at least 80 files and directories anyway when starting a profile. Why is a pref in about:config useful if the user decision is already determined by the existence or non-existence of the directory "chrome"?

In my opinion, redundancy generally does not make sense. Why is redundancy a good solution in this case?

By the way: Thanks that 'about:' pages since build ID 20190503041749 process the instructions of userContent.css again!

Comment 30

[Dave Townsend [:mossop]]

(In reply to wernerfp from comment #28)

(In reply to Mike Conley (:mconley) (:⚙️) from comment #23)

The end result will that for the vast majority of our users, we can avoid looking for both userContent.css and userChrome.css files, which will be better for start-up performance. For the users that needs these customizations, we're unfortunately adding a one-time interruption where they have to go flip a pref in about:config, but they get to opt-in to these customizations in exchange for start-up performance.

Firefox checks at start-up which files and directories are present or not present in the user profile.

We would like to stop doing that wherever possible as it slows down startup.

If the directory "chrome" doesn't exist, the user logically doesn't want any customization via userContent.css and userChrome.css.

But it costs more time to check if the chrome directory doesn't exist than it does to check a pref. Also there are old profiles out there in the wild that still contain a chrome directory with no valid .css files in it.

Firefox checks the existence of at least 80 files and directories anyway when starting a profile. Why is a pref in about:config useful if the user decision is already determined by the existence or non-existence of the directory "chrome"?

I can't spot us checking for the existence of the chrome directory at all other than for loading these css directories. If we are, we should stop doing that.

In my opinion, redundancy generally does not make sense. Why is redundancy a good solution in this case?

THe intention is for there to be no redundancy here, either the pref is set in which case we'll do the additional work to check for and load the css file, or the pref isn't set in which case we won't check for the existence of these files making startup for the vast majority of users faster.

Comment 31

[wernerfp]

(In reply to Dave Townsend [:mossop] (he/him) from comment #30)

But it costs more time to check if the chrome directory doesn't exist than it does to check a pref.

Thank you Dave for your explanation.
If checking a pref in prefs.js and additionally in user.js (if existent) is measurably faster, this is indeed a valid reason.

How many milliseconds are saved by this at startup (round about)?

If checking at startup for the existence of user-generated files is too time-consuming, shouldn't the pref in about:config consequently include user.js?

Comment 32

[Dave Townsend [:mossop]]

(In reply to wernerfp from comment #31)

(In reply to Dave Townsend [:mossop] (he/him) from comment #30)

But it costs more time to check if the chrome directory doesn't exist than it does to check a pref.

Thank you Dave for your explanation.
If checking a pref in prefs.js and additionally in user.js (if existent) is measurably faster, this is indeed a valid reason.

How many milliseconds are saved by this at startup (round about)?

It varies wildly depending on platform and hardware. Hardware with slow disks are adversely affected. But even if it is small, we don't generally make startup faster by doing fixes that show a large improvement. We add up lots and lots of fixes that only have a small effect.

If checking at startup for the existence of user-generated files is too time-consuming, shouldn't the pref in about:config consequently include user.js?

We actually discussed this. A challenge is that user.js is used to set prefs so only reading it if a pref is set could be problematic. Someone might be using it bootstrap clean profiles for example.

Comment 33

[Mike Conley (:mconley) (:⚙️)]

Mandy Cheang is taking this on as an intern project.

Comment 34

[Mandy Cheang [:mcheang][she/her]]

Attachment: Bug 1541233 - Don't load customization style sheets if toolkit.legacyUserProfileCustomizations.stylesheets pref is not set. r?mconley

Comment 35

[Mike Conley (:mconley) (:⚙️)]

Hey pascalc, this is a change we're hoping to land in Nightly to ride the Firefox 69 train.

The idea here is that users who want to use userChrome.css or userContent.css files will have to flip the toolkit.legacyUserProfileCustomizations.stylesheets pref to true in order for them to take effect. This is to avoid checking the disk for those files unnecessarily, which adds main-thread IO, and can jank the browser.

One thing to note is that Firefox 68 is going to go out with bug 1550157, which automatically sets that pref for users that have a pre-existing userChrome.css or userContent.css file, so we expect that to help avoid annoying most people who have those types of customizations already - they shouldn't notice a difference.

From Firefox 69 and onward though, folks who want to use userChrome.css or userContent.css will also need to flip the toolkit.legacyUserProfileCustomizations.stylesheets pref.

What's the best way to message this out to the right communities of users who will want to know this stuff?

Comment 36

[Mike Conley (:mconley) (:⚙️)]

While we wait for Mandy's L1 to get put through, here's a try push with the latest patch:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=ff553596229dfd4d7e14856168f53dcf6a39e99b

Comment 37

[Mandy Cheang [:mcheang][she/her]]

Attachment: Bug 1541233 - Remove expired USER_CHROME_CSS_LOADED probe. r?mconley

Depends on D31670

Comment 38

[Mike Conley (:mconley) (:⚙️)]

Here's a try push Talos comparison, for when the try builds are done: https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=bc125e5732292c311b858786a17b98a2fc402b66&newProject=try&newRevision=ff553596229dfd4d7e14856168f53dcf6a39e99b

Comment 39

[Mike Conley (:mconley) (:⚙️)]

Hey Paenglab,

I know you're already following this bug, but wanted to make sure you were aware that we're getting pretty close to landing it. For Thunderbird, you'll probably want to set toolkit.legacyUserProfileCustomizations.stylesheets to true in https://dxr.mozilla.org/comm-central/source/comm/mail/app/profile/all-thunderbird.js.

Comment 40

[Richard Marti (:Paenglab)]

Mike, thank you for the heads-up.

Comment 41

[Mike Conley (:mconley) (:⚙️)]

Release Note Request (optional, but appreciated)
[Why is this notable]:
Some users who use the rather obscure userContent.css or userChrome.css mechanisms to customize Firefox might find that those customizations don't work anymore until they flip a particular preference.

[Affects Firefox for Android]:
Almost certainly not - the hoops that users would need to jump through in order to add a userContent.css file to Firefox for Android would be crazy. And a userChrome.css file wouldn't impact the UI of Firefox for Android, since it's written using the native Android UI toolkit.

[Suggested wording]:
[Links (documentation, blog post, etc)]:
Users who use userChrome.css or userContent.css files to customize Firefox may need to flip the toolkit.legacyUserProfileCustomizations.stylesheets pref to true in order for Firefox to load these files. This is to avoid touching the disk unnecessarily during start-up for users that don't have those files. This pref will have been set automatically for users on Firefox 68 who had either userChrome.css or userContent.css already exiting in their profile directories.

Comment 42

[Mike Conley (:mconley) (:⚙️)]

Hey miketaylr, aja suggested I point you at this too so that you're aware (see comment 35, comment 41).

Comment 43

[Mike Taylor [:miketaylr]]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #42)

Hey miketaylr, aja suggested I point you at this too so that you're aware (see comment 35, comment 41).

👍

As for outreach, a couple of ideas:

• reddit.com/r/firefox and /r/thunderbird posts
• mozillazine post
• MDN updates in relevant places
• tiny Hacks article (...maybe?)

Comment 44

[Mike Conley (:mconley) (:⚙️)]

(In reply to Mike Taylor [:miketaylr] from comment #43)

As for outreach, a couple of ideas:

• reddit.com/r/firefox and /r/thunderbird posts
• mozillazine post
• MDN updates in relevant places
• tiny Hacks article (...maybe?)

I've updated this MDN article, and have added a post to /r/firefox. I believe the Thunderbird community will be flipping that pref to be the application default, so I don't think they'll need to be alerted.

It looks like /r/FirefoxCSS is already aware.

A message just went out on Twitter as well.

Pascal, do you have a Mozillazine account that you can use to alert that community?

Comment 45

[Pascal Chevrel:pascalc]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #44)

(In reply to Mike Taylor [:miketaylr] from comment #43)

As for outreach, a couple of ideas:

• reddit.com/r/firefox and /r/thunderbird posts
• mozillazine post
• MDN updates in relevant places
• tiny Hacks article (...maybe?)

I've updated this MDN article, and have added a post to /r/firefox. I believe the Thunderbird community will be flipping that pref to be the application default, so I don't think they'll need to be alerted.

It looks like /r/FirefoxCSS is already aware.

A message just went out on Twitter as well.

yeah, that was me :)

Pascal, do you have a Mozillazine account that you can use to alert that community?

I had one, haven't used it in years though, I'll check tomorrow if it still works.

Comment 46

[Wellington Torrejais da Silva]

Sorry for the intrusion.
There is a way to active that by command line parameter like '--user-chrome' ?
Because actually we use the Firefox integrated to other programs and need that way of customization.

Thanks!

Comment 47

[Mike Conley (:mconley) (:⚙️)]

ni?ing myself for comment 46.

Comment 48

[Wellington Torrejais da Silva]

(In reply to Wellington Torrejais da Silva from comment #46)

Sorry for the intrusion.
There is a way to active that by command line parameter like '--user-chrome' ?
Because actually we use the Firefox integrated to other programs and need that way of customization.

Thanks!

But just if not increase the startup time. If command line parameter increase startup delay I'm happy to leave the idea of still use the userChrome.css/userContent.css files.

I'm happy for movement of startup performance review and general performance improvements.

Thanks!

Comment 49

[lpy750]

In regards to startup time, as a user of userChrome.css/userContent.css, I've noticed setting the Firefox theme to either Dark or Light has a much greater impact on startup time compared to using the Default theme and/or userChrome.css/userContent.css.

Comment 50

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/409b2e43be0e
Don't load customization style sheets if toolkit.legacyUserProfileCustomizations.stylesheets pref is not set. r=mconley,emilio
https://hg.mozilla.org/integration/autoland/rev/e1d9f28fbaaa
Remove expired USER_CHROME_CSS_LOADED probe. r=mconley

Comment 51

[Mike Conley (:mconley) (:⚙️)]

(In reply to Wellington Torrejais da Silva from comment #46)

There is a way to active that by command line parameter like '--user-chrome' ?
Because actually we use the Firefox integrated to other programs and need that way of customization.

I'm afraid that's not something we've added here. I'm not sure how exactly you're integrating with Firefox, but you might need to ask the user to opt in to using the userChrome / userContent CSS files by telling them to flip the preference.

Comment 52

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/409b2e43be0e
https://hg.mozilla.org/mozilla-central/rev/e1d9f28fbaaa

Comment 53

[frankell]

This is not a bug ! as Mozilla never supported the use of the chrome folder and related bugs !
actually in the Firefox first\clean install the chrome folder is not present neither the userChrome and userContent files,
the Firefox power users must create them by themselves and the UI customization lovers are very well aware of what they are doing,
or I'm missing something ? to ask to the new power user to set: toolkit.legacyUserProfileCustomizations.stylesheets to true is meaning that from now on Mozilla is supporting the resurrection of the chrome folder ?
well it's seems to me incoherent to add a new pref for all the Firefox users !

Comment 54

[Dave Townsend [:mossop]]

(In reply to frankell from comment #53)

This is not a bug ! as Mozilla never supported the use of the chrome folder and related bugs !
actually in the Firefox first\clean install the chrome folder is not present neither the userChrome and userContent files,
the Firefox power users must create them by themselves and the UI customization lovers are very well aware of what they are doing,
or I'm missing something ?

You're missing the fact that it takes more time to check if a directory/file exists than it does to check if a preference is set (prefs are already loaded into memory so no file I/O is necessary).

Comment 55

[frankell]

(In reply to Dave Townsend [:mossop] (he/him) from comment #54)

(In reply to frankell from comment #53)

This is not a bug ! as Mozilla never supported the use of the chrome folder and related bugs !
actually in the Firefox first\clean install the chrome folder is not present neither the userChrome and userContent files,
the Firefox power users must create them by themselves and the UI customization lovers are very well aware of what they are doing,
or I'm missing something ?

You're missing the fact that it takes more time to check if a directory/file exists than it does to check if a preference is set (prefs are already loaded into memory so no file I/O is necessary).

I still confirm it's no a bug ! you just said that this new pref entry will control the presence of the chrome folder
but the power users don't need that and naturally also the normal users don't need that as they will not create the new chrome folder (not existing by default) so the pref: toolkit.legacyUserProfileCustomizations.stylesheets seems to me completely redundant

Comment 56

[Dave Townsend [:mossop]]

(In reply to frankell from comment #55)

(In reply to Dave Townsend [:mossop] (he/him) from comment #54)

(In reply to frankell from comment #53)

This is not a bug ! as Mozilla never supported the use of the chrome folder and related bugs !
actually in the Firefox first\clean install the chrome folder is not present neither the userChrome and userContent files,
the Firefox power users must create them by themselves and the UI customization lovers are very well aware of what they are doing,
or I'm missing something ?

You're missing the fact that it takes more time to check if a directory/file exists than it does to check if a preference is set (prefs are already loaded into memory so no file I/O is necessary).

I still confirm it's no a bug ! you just said that this new pref entry will control the presence of the chrome folder.

This is incorrect. The pref controls whether we will look for a chrome folder and use the files in it.

Comment 57

[frankell]

(In reply to Dave Townsend [:mossop] (he/him) from comment #56)

I still confirm it's no a bug ! you just said that this new pref entry will control the presence of the chrome folder.

This is incorrect. The pref controls whether we will look for a chrome folder and use the files in it.

Thanks for the feedback, OK I noticed that this type of Bug is labelled: enhancement (new feature, improvement in UI, performance, etc. )
in this case pointing to the performance on the other plate of the balance there is the stop (a regression) to the UI customization
actually the chance of a switch off of the chrome folder is scaring the hand-made community of the Firefox lovers
well my last question is if the power and normal users don't need this new pref who's pro ?

Comment 60

[KOLANICH]

legacy in name implyes you gonna drop support for these files completely in future. Before that happened you need to implement measures to compensate this. I mean WebExtension API allowing extensions to insert own stuff into the chrome. I currently use https://github.com/Aris-t2/CustomCSSforFx to achieve multiline tabs and I am very disappointed that you gonna remove this possibility only because of desire to shrink codebase by removing everything not used by housewives instead of actively promoting the use of these "seemengly unneeded" features among users. In fact lot of unexperienced users like these advanced features just have not known about them.

Comment 61

[Florian Quèze [:florian]]

(In reply to KOLANICH from comment #60)

legacy in name implyes you gonna drop support for these files completely in future.

No, the word "legacy" was used in the preference name to avoid giving the impression that with this new preference we are adding a new customization feature.

I'm not aware of any plan to drop support for these files.

Comment 62

[Danny Colin [:sdk]]

(In reply to KOLANICH from comment #60)

legacy in name implyes you gonna drop support for these files completely in future. Before that happened you need to implement measures to compensate this. I mean WebExtension API allowing extensions to insert own stuff into the chrome.

Those two files are a relic from the XUL era. Also, to my knowledge, they have never been officially supported. You can always open a bugreport to ask new APIs or new functionalities to existing one like the Theme API.

(In reply to Florian Quèze [:florian] from comment #61)

(In reply to KOLANICH from comment #60)
I'm not aware of any plan to drop support for these files.

FWIW "This documentation has not been fully updated for Firefox Quantum. Support for the userChrome.css file and any of its elements described below are not guaranteed in future versions of Firefox. Using it may lead to hard-to-diagnose bugs or crashes. Use at your own risk!" -- https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Tutorial/Modifying_the_Default_Skin

Comment 63

[KOLANICH]

You can always open a bugreport to ask new APIs or new functionalities to existing one like the Theme API.

Customizability is also a "a relic from the XUL era". Of course I can ask, but the most likely they will be wontfixed. I know that XUL extensions are still possible, I have personally drafted a couple of Web Extension experiments (one is for reusing Scratchpad as JS editor in addons instead of code-mirror -based ones which are totally unusable, another one is for exposing a fast and maintained by Mozilla JS parser built into SpiderMonkey, both have been rejected). I just have no illusions about Mozilla - Mozilla now has desire to forbid to tinker to their browser (onder "Mozilla browser" I here mean the official stable builds) internals for anyone, if one wants to tinker, he has to maintain an own fork and face all the consequences fo that.

Using it may lead to hard-to-diagnose bugs or crashes.

Using WebGL for a long time have been capable to bring down whole OS (with at least 2 ways to do it, one involving overloading the GPU with vertexes and polygons, another one was to cheat sanitizer to admit the endless loop shader).
Opening a page eating memory actively can bring down whole system, if one uses Linux (Linux is known to be becoming very inresponsive when RAM is exausted with only viable action is to hit reset button on the case. The solution is to disable overcommit, but when overcommit is disabled, the already started apps just start crashing and newly started apps are also starting crashing because of failed allocations. The only viable way here is to have large excess of spare memory, and even it cannot protect from an app just eating it).
Opening a page with JS can result in security be compromised via an exploit doing use-after-free somewhere in DOM API.
Opening a page with JS can result in security be compromised via an exploit using an unmitigated flaw in API design and impl, allowing to exploit side channels.
Opening a page with JS can result in security be compromised via an exploit heap memory corruption when parsing some image or font or video format.

The difference here is that browser extensions and userChrome.css are explicitly trusted and audited, but webpages are not. It is completely OK that userChrome.css can crash the browser. It is completely OK XUL addons can do the same. It is not OK that WebExtension API is intentionally kept too limited despite the needs of legitimate addons (addons which purpose is not to spy on users) developers and users community. I don't beleive the argumentation that a customization feature explicitly enabled by user is more dangerous than allowing arbitrary webpages execute active content automatically without any user's consent and confirmation. Instead of these statements Mozilla probably should just tell the true reasons of the decisions to remove that code. If needed - with all the needed calculations and assumptions, used in these calculations.

Comment 64

[frankell]

thanks to the "relic" chrome folder resources Firefox Quantum can still be so "different" >
https://byfrankell.webnode.com/about/
the ecstasy (the UI customization) is worth the agony (few milliseconds delay on startup)

Comment 65

[Paul [pwd]]

(In reply to KOLANICH from comment #63)

You can always open a bugreport to ask new APIs or new functionalities to existing one like the Theme API.

Customizability is also a "a relic from the XUL era". Of course I can ask, but the most likely they will be wontfixed.

But rather than just moaning here about something that won't change, surely it's better to at least file the bug?

Comment 66

[KOLANICH]

Ok, here it is: https://bugzilla.mozilla.org/show_bug.cgi?id=1554514

Comment 69

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

Added to the Fx69 Beta release notes.

Comment 70

[Karma]

Please do not drop support for userChrome customization. I rely on this for customizing the scrollbar. I'm not a developer, just a casual user and this feature is really important to me.

Comment 71

[Dave Townsend [:mossop]]

(In reply to Karma from comment #70)

Please do not drop support for userChrome customization. I rely on this for customizing the scrollbar. I'm not a developer, just a casual user and this feature is really important to me.

This bug is not about dropping support for userChrome.

Comment 72

[comdudeskip]

It would be ideal to always check once on first run of Firefox or after an update for the presence of the chrome folder and then automatically set this preference flag for the user.

Having this flag results in unexpected failure to load customisations that users add later and makes it difficult for them to discover the need to toggle this flag. If the startup time is a concern, why not delay the check for the chrome folder until later? Then adjust the flag for the user, so that on the next run of Firefox it'll be both recognised as present and fast. This would avoid any confusion and ensure easy customising without needing the user to also find out about this new flag.

Ideally, the user should receive a prompt to ask if they wish to enable the user chrome customisations before automatically setting the flag.

Comment 73

[brunoais]

Ideally, the user should receive a prompt to ask if they wish to enable the user chrome customisations before automatically setting the flag.

Unfortunately, that ideal option is not a good one. Most users won't know what they are being asked and will be completely confused about it. I really thing it is better to just have it change automatically, alert in the change notes and let addons warn power users about it.

Comment 74

[Laurence "GreenReaper" Parry]

For what it's worth: this didn't automatically set the pref for me when I was upgraded on Nightly. I only noticed when pages started slowing down; initially I thought the websites concerned had tweaked their layout, and I only found out about this when a fix for a new annoyance didn't work.

I second #72, this is a sudden annoyance that breaks stuff. You know that "don't break userland" thing Linux has? Might be good to apply here.

Comment 75

[Danny Colin [:sdk]]

(In reply to Laurence "GreenReaper" Parry from comment #74)

I second #72, this is a sudden annoyance that breaks stuff. You know that "don't break userland" thing Linux has? Might be good to apply here.

"Support for the userChrome.css file and any of its elements described below are not guaranteed in future versions of Firefox. Using it may lead to hard-to-diagnose bugs or crashes. Use at your own risk!" -- https://developer.mozilla.org/en-US/docs/Archive/Mozilla/XUL/Tutorial/Modifying_the_Default_Skin

Comment 76

[Laurence "GreenReaper" Parry]

(In reply to Danny Colin [:sdk] from comment #75)

"Support for the userChrome.css file and any of its elements described below are not guaranteed in future versions of Firefox. Using it may lead to hard-to-diagnose bugs or crashes. Use at your own risk!" -- https://developer.mozilla.org/en-US/docs/Archive/Mozilla/XUL/Tutorial/Modifying_the_Default_Skin

That doesn't really address the main issue I was attempting to raise, although it does make me more worried that you're going to take this feature away entirely when you get the chance. 😼

To restate, in a slightly less tetchy fashion: it seems like the intention was to set the preference to true for all existing users by ensuring those who used version 68 with had the pref set (bug 1550157). That sounds a reasonable approach to what would otherwise be a disruptive change.

But... judging by my experience, that pref was never set for people on Nightly at that time. Perhaps it was only ever merged into a branch?

If this is the case, there could be a non-trivial number of people out there who have a CSS file and don't know why it's not working - especially since those on Nightly (or Beta/Dev?) are probably more likely than the average person to have a user*.css.

Maybe it is a trivial number of people, but I'm not in a position to know. All I know is that my own netbook was significantly slower for months, because all the ad and video blocking I had in userContent.css failed to load.

Comment 77

[User Dderss]

I personally use userChrome.css in:

1. ... TB to make the font of the main table with the list of emails rendered in bigger Arial Narrow font (otherwise it is either too small or it is big enough but wide letters make less information available on the screen)

2. ... FF to get rid of many context/general menu items that I never use to have less clutter as well as to re-order some of the rest menu items to they would make more sense. Previously, I also used it to remove otherwise non-removable GUI elements (e.g. Mozilla's foray into social media/communications).

If both scenarios like this will not be possible to fix by standard methods, the "toolkit.legacyUserProfileCustomizations.stylesheets" and the implementation should stay.

Comment 78

[wernerfp]

Before I write a new bugreport...
Since version 72 (Developer) and 73 (Nighly) variables from userChrome.css are no longer processed correctly.
Is this intended?

Comment 79

[Florian Quèze [:florian]]

(In reply to wernerfp from comment #78)

Before I write a new bugreport...
Since version 72 (Developer) and 73 (Nighly) variables from userChrome.css are no longer processed correctly.
Is this intended?

Please file a new bug, nothing has changed here since Firefox 69 so any change you see in 72 and later is not related to this bug.

Comment 80

[wernerfp]

Thanks Florian!
Report: Bug 1601413

Comment 81

[MarjaE]

I user userChrome.css and userContent.css for accessibility fixes. Not being about to use this on about pages in Firefox or in Thunderbird is a problem.

userChrome.css can't fix all the accessibility problems on about:preferences, about:addons, support.mozilla.org, etc. but if it applies, then it can help with some of these accessibility problems.

Comment 82

[MarjaE]

I am photosensitive, so WebExtensions can't meet all my needs. For example, if I use WebExtensions for fonts and font sizes, then the pages tend to load with the default settings, flash, and reload with the WebExtensions. If I use the preferences, then I can't resolve certain font size issues. But if I use userContent.css, they load once, without flashing.

Comment 83

[MarjaE]

This also creates a catch-22 in Thunderbird, and probably in Firefox. It's hard to read about:config without user css to set fonts and font sizes.

Comment 84

[Dave Townsend [:mossop]]

There is nothing to be gained by commenting further on this bug. Please take discussions about the uses of userChrome and userContent to the mailing lists.

Comment 85

[Anje]

If a user has userChrome.css and userContent.css files then the user put them there because they are to be used. So, they should be enabled. There is no logical reason to assume a user suddenly does not want them working. It is illogical to assume otherwise unless FF has issues of some kind and needs to initially start without those files running, in which case those 'issues' should be made clear and a prompt to restart enabling all the users selected options including userChrome.css and userContent.css files should be clearly visible and selectable.

Comment 86

[brunoais]

(In reply to Anje from comment #85)

If a user has userChrome.css and userContent.css files then the user put them there because they are to be used. So, they should be enabled. There is no logical reason to assume a user suddenly does not want them working. It is illogical to assume otherwise unless FF has issues of some kind and needs to initially start without those files running, in which case those 'issues' should be made clear and a prompt to restart enabling all the users selected options including userChrome.css and userContent.css files should be clearly visible and selectable.

What if it was not the user that put those files there?

Comment 87

[Anje]

Then they should be enabled anyway with a pop up mentioning they were enabled. But it is not exactly very likely that someone allows modifications in that way to their computer and does not know about it. If they are an employee and have no control then the files were still put there for a reason by employer in which case neither the employee nor FF should have control.

Comment 88

[sandwichs]

Well, it's 2 years later and I can say "automatically setting the pref" was a BAD move.
By not making it a nuisance you FAILED to notify the powerusers of the pref's existence.
This caused the topic to never go "hot", which made it really hard to find the solution today.

True, you have saved me a brief nuisance, but it would be obvious the upgrade is to blame.
Instead I ran into it while migrating to a new machine, causing a week-long frustration.

Sorry for the rant
Setting up userChrome.css already has too many failure modes and like no debugging facilities.
I know, there are not enough person-hours dedicated to Mozilla to do something fancier.
But, you know, maybe by hiding power tools like userChrome.css and generally pushing people towards "consumer / fixed mindset" instead of teaching them that "everything is possible" you are cutting away dev recruitment paths?

---

Apendix: Top DDG search results for "userchrome.css not applied" (automatically suggested for "userchrome.css not")

On windows (see https://pasteboard.co/JAChZP6.png) it is a tragedy:
o) NOPE "userChrome.css not working | Firefox Support Forum" https://support.mozilla.org/en-US/questions/1184056
o) BURRIED "[Fix] userChrome.css and userContent.css Codes Stopped" https://www.askvg.com/fix-userchrome-css-and-usercontent-css-codes-stopped-working-after-firefox-upgrade
o) NOPE "1410511 - userContent.css and userChrome.css are not" https://bugzilla.mozilla.org/show_bug.cgi?id=1410511
o) NOPE "userChrome.css doesn't apply after restart : FirefoxCSS" https://www.reddit.com/r/FirefoxCSS/comments/jkx9u5/userchromecss_doesnt_apply_after_restart
On linux (https://pasteboard.co/JAChEbk.png) it is OK-ish:
o) NOPE "CSS variables in Firefox's userChrome.css do not take effect" https://stackoverflow.com/questions/59604819/css-variables-in-firefoxs-userchrome-css-do-not-take-effect
o) OK "Firefox 69: userChrome.css and userContent.css disabled" https://www.ghacks.net/2019/05/24/firefox-69-userchrome-css-and-usercontent-css-disabled-by-default/
o) NOPE "userChrome.css not working | Firefox Support Forum" https://support.mozilla.org/en-US/questions/1184056
o) LONG "userChrome.css not working on newly installed FF" http://forums.mozillazine.org/viewtopic.php?f=38&t=3046394
o) OK "How to Create a userChrome.css File" https://www.userchrome.org/how-create-userchrome-css.html

Comment 89

[sonaise]

I see now mozilla userContent.css is quite comfortable

<a href='https://www.brankaspedia.com'>techtutorial</a>