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

RESOLVED FIXED in Firefox 69

Status

()

enhancement
P3
normal
RESOLVED FIXED
3 months ago
5 days ago

People

(Reporter: mconley, Assigned: mcheang, Mentored)

Tracking

(Blocks 1 bug)

unspecified
mozilla69
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(relnote-firefox ?, firefox68 wontfix, firefox69 fixed)

Details

(Whiteboard: [layout:triage-discuss][fxperf:p1][fxperfsize:XS])

Attachments

(2 attachments, 1 obsolete attachment)

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.

Sounds reasonable.

Priority: -- → P3
Whiteboard: [layout:triage-discuss]

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

Reporter

Comment 3

2 months ago

(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. :)

Reporter

Updated

2 months ago
Summary: Stop loading userContent.css in the parent process → Stop loading userContent.css in the parent process, and stop loading userChrome.css in the content process.
Reporter

Comment 4

2 months ago

(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

Summary: Stop loading userContent.css in the parent process, and stop loading userChrome.css in the content process. → Stop loading userContent.css in the parent process
Reporter

Updated

2 months ago
Whiteboard: [layout:triage-discuss] → [layout:triage-discuss][fxperf][fxperfsize:XS]
Reporter

Updated

2 months ago
Assignee: nobody → mconley
Reporter

Updated

2 months ago
Whiteboard: [layout:triage-discuss][fxperf][fxperfsize:XS] → [layout:triage-discuss][fxperf:p1][fxperfsize:XS]
Reporter

Comment 6

2 months ago
Flags: needinfo?(emilio)

replied there, thanks :)

Flags: needinfo?(emilio)

Comment 8

2 months ago
Pushed by mconley@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/0e9ee7d2188b
Stop loading userContent.css in the parent process. r=emilio

Comment 9

2 months ago
bugherder
Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68

Comment 10

2 months ago

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?

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.

Flags: needinfo?(mconley)

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

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

Flags: needinfo?(mconley) → needinfo?(acid.crash.lv)

Updated

2 months ago
Regressions: 1548519

(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

2 months ago

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.

Flags: needinfo?(acid.crash.lv)
Reporter

Comment 15

2 months ago

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.

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

Flags: needinfo?(florian)

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

2 months ago

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.

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?

(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

2 months ago

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.

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.

Flags: needinfo?(florian)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

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

Flags: needinfo?(dtownsend)
Reporter

Updated

2 months ago
Type: defect → enhancement

Comment 26

2 months ago

(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.

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

Flags: needinfo?(dtownsend)

Comment 28

Last month

(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!

Duplicate of this bug: 1548519

(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

Last month

(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?

(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.

Depends on: 1550157
Attachment #9060442 - Attachment is obsolete: true
Assignee: mconley → mcheang
Mentor: mconley

Mandy Cheang is taking this on as an intern project.

Summary: Stop loading userContent.css in the parent process → Stop loading userContent.css or userChrome.css by default unless a preference is set
Attachment #9065779 - Attachment description: Bug 1541233 - don't load customization style sheets if toolkit.legacyUserProfileCustomizations.stylesheets pref is not set. r?mconley → Bug 1541233 - Don't load customization style sheets if toolkit.legacyUserProfileCustomizations.stylesheets pref is not set. r?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?

Flags: needinfo?(pascalc)

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

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.

Flags: needinfo?(richard.marti)

Mike, thank you for the heads-up.

Flags: needinfo?(richard.marti)

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.

relnote-firefox: --- → ?
Flags: needinfo?(pascalc)

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

(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?)

(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?

Flags: needinfo?(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.

Flags: needinfo?(pascalc)

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!

Flags: needinfo?(mcheang)

ni?ing myself for comment 46.

Flags: needinfo?(mcheang) → needinfo?(mconley)

(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

25 days ago

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

24 days ago
Pushed by mconley@mozilla.com:
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

(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.

Flags: needinfo?(mconley)

Comment 52

24 days ago
bugherder
Status: REOPENED → RESOLVED
Closed: 2 months ago24 days ago
Resolution: --- → FIXED
Target Milestone: mozilla68 → mozilla69

Comment 53

23 days ago

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 !

(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

23 days ago

(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

(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

22 days ago

(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

22 days ago

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.

(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.

(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

22 days ago

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

22 days ago

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

21 days ago

(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?

You need to log in before you can comment on or make changes to this bug.