12 ms·

> Firefox no longer loads userChrome.css or userContent.css by default improving start-up performance. Users who wish to customize Firefox by using these files

by plopz 7y ago

> Firefox no longer loads userChrome.css or userContent.css by default improving start-up performance. Users who wish to customize Firefox by using these files can set the toolkit.legacyUserProfileCustomizations.stylesheets preference to true to restore this ability. How much of a performance improvement does this make?

dictum 7y ago
I use userChrome.css and userContent.css, and I get the nagging feeling that the silent end of that sentence is "...when we eventually replace the code that currently enables user customization with faster, less flexible APIs." (I'm paranoid and FUDing because I care: there's some UX low hanging fruit before they could get rid of userChrome.css. For instance, you need userChrome.css to autohide the toolbar in full screen mode on macOS — that's not even a customization, it's a missing feature.)
- StavrosK 7y ago
  I mean, how slow could an "if file_exists()" check have been? This smells like deprecation to me, if the user CSS doesn't exist, don't load anything. Boom, no slowdown.
  - kbenson 7y ago
    Given that the profile setting is under a subsection of "legacyUserProfileCustomizations", perhaps there's a whole legacy subsystem they spin up to handle it that's only needed for that now? I could see a whole subsystem causing significant enough delay and resource usage to be noticeable, if that's the case.
    - rrix2 7y ago
      AFAICT it's Firefox's CSS+HTML engine running the user chrome. You can even open the firefox web inspector on it (open web inspector -> settings -> enable browser chrome and add-on debugging toolboxes) which lets you fiddle with the chrome DOM and modify CSS that way.
  - bzbarsky 7y ago
    The technical answer to the question you asked is "10-20ms, if you're not on an SSD". That's not great, actually, if you're trying to shave tens of milliseconds at a time off startup performance. For what it's worth, this change happened because people were seeing the stat() call involved in startup profiles, taking sufficient time that it seemed worthwhile to avoid it if possible, as far as I can tell.
    - StavrosK 7y ago
      Are many users on HDDs these days? Weird that it would take this long, although I guess it's niche enough that you'd want to save those 20 ms for something used by a tiny fraction of users.
      - dblohm7 7y ago
        > Are many users on HDDs these days? Yes, there are. They are not a niche cohort. EDIT: In fact, we have many more users with magnetic HDDs than who use userChrome.css. That tells you everything you need to know about this decision right there.
      - jahlove 7y ago
        Just under half of desktops use magnetic drives, according to Western Digital. [1] [1] https://www.minitool.com/news/ssd-market-share.html https://www.minitool.com/news/ssd-market-share.html
    - xxs 7y ago
      >The technical answer to the question you asked is "10-20ms, if you're not on an SSD C'mon the directory structure would be cached already, even if it was not - the seek times for HDD are 3-4ms.
      - bzbarsky 7y ago
        The directory structure may or may not be cached already: these files are in a separate directory from everything else Firefox needs at startup. If your HDD has a seek time of 3-4ms on average, that means it needs to rotate completely in at most 6-8ms, which gives you a rotation speed of 7500-10,000 rpm. HDDs in data centers do that, sure. Consumer HDDs just don't do that, last I checked; they're mostly in the 5400-7200 rpm range, with laptops firmly in the 5400 bucket. See https://www.dell.com/en-us/shop/dell-laptops/sc/laptops?appliedRefinements=13242 https://www.dell.com/en-us/shop/dell-laptops/sc/laptops?appl... for example (currently offered Dell laptops "for home" with an HDD: they're all 5400rpm). At 5400 rpm, your average latency from just the rotation is 5.5ms and your worst-case latency from the rotation is 11ms. That doesn't include other latency sources, but let's assume those are somehow scheduled away to happen during the rotation. Keep in mind that what typically sticks in users' minds is worst-case, not average-case, behavior, so you have to bring your worst-case time budget down to whatever your target is.
  - deleted 7y ago
    [deleted]
- feanaro 7y ago
  Unfortunately, I think you're right. Mozilla has been fighting a slow war on all powerful UI customization. See: the recent killing of Tridactyl.
  - bovine3dom 7y ago
    Reports of our death have been greatly exaggerated :) You can still install Tridactyl in a normal installation of Firefox by following the instructions on our readme [1]. Admittedly, that may cease to be the case if Mozilla ever tire of us; people in locked-down corporate environments would then find it hard or impossible to install Tridactyl but we'd make it as easy as possible for everyone else. On topic, I'd argue that Mozilla are just desperately trying to cling on to ordinary users; the "war" against power users is a war of (totally understandable) neglect rather than spite. [1]: https://github.com/tridactyl/tridactyl/blob/master/readme.md https://github.com/tridactyl/tridactyl/blob/master/readme.md
    - Amezarak 7y ago
      Firefox gained the marketshare it did because power users relentlessly evangelized it to non-power users. There was some of the same phenomenon with Google, but the real difference is that Google pushed Chrome very strongly on the biggest web properties in the world, had it packaged in some other software installers, and advertised it. That's why Chrome has the market-share it does today. Mozilla appears to now be courting the ordinary user market without having either the passion of power users driving it, or the world's biggest web properties shilling it. To this day, visiting google.com (#1 website) in my default browser pops up a large notification informing me I need to switch to Chrome to 'hide annoying ads and protect against malware on the web.' Visting YouTube.com (#2 website) pops up a slightly less annoying notification on the bottom that says "Google recommends using Chrome, a fast and secure browser." I haven't been able to figure out for years now how they think this is going to work. Ordinary users are going to do what their IT administrator/IT friend says, use the OS default, or use products recommended by massive marketing campaigns.
      - bscphil 7y ago
xxs 7y ago
Virtually they removed it in 68 with setting the flag when any of the files was present. Unfortunately they also changed the css model, so even with the flag on - userChrome.css has become useless (to me)... I guess 66 will not be seeing an upgrade for the time being. As for the question - should be less than 1ms (depends on the OS/filesystem obviously but still negligible)
solarkraft 7y ago
Holy shit, just why? It makes virtually no difference. Neither applying CSS (they already use a lot) nor loading a file take any time.
- megous 7y ago
  Yeah, sounds like a non-reason, my user CSS was like 5 lines. I'll have to run an extension that will be injecting JS/CSS into every page, to get the same effect. That will likely be slower. Not a speed improvement exactly. At least it's more powerful. I can replace any rule inside already loaded CSS. Useful to escape this braindead age of "font-size < 16px && font-weight < 400".
  - bzbarsky 7y ago
    If you have a user CSS, the "keep it working" pref has already been set for you, as of Firefox 68. So everything will keep working as it has.
- kevingadd 7y ago
  It has to have been showing up in profiles for them to bother, nobody would go out of their way to disable it otherwise. They added a pref to turn it back on and then disabled it instead of the easy thing (just removing it) which is some engineering effort plus testing effort to make sure the pref works right. Silly to do that for nothing. Antivirus software does add a measurable delay to file operations sometimes, and each file is gonna be in its own sector so I could see them losing at least a few milliseconds there. Applying CSS does add overhead but the average user can't have that many rules in there so I suspect it's purely on the file i/o level.
  - bzbarsky 7y ago
    Not just that, but in an earlier release code was shipped to set the pref for users who already had the file, so that anyone who already had one of these files would not observe any behavior regressions. And yes, file I/O was the issue.
Sharlin 7y ago
Last time I tried, I just couldn’t get userContent.css to work at all. Maybe a user error, but I’d really like an easy way to set some default styles to override the inane Web 0.5 era defaults such as zero margins and unlimited-width paragraphs. Reading Good Old HTML (tm) pages sucks, and although there’s the reading mode, it tends to simply drop vital content it doesn’t happen to support…
- plopz 7y ago
  I've used https://github.com/Aris-t2/CustomCSSforFx https://github.com/Aris-t2/CustomCSSforFx ever since ClassicThemeRestorer broke when they killed the old extensions. It seems to work fine for me.
silverwind 7y ago
It's just a lame excuse really, such a change not improve performance in any noticeable way. I fear the change is just to take away this important customization option in the future and I don't like it.
- bwat49 7y ago
  by itself it won't, but they've been working on various optimizations to shorten startup time. A few ms isn't much by itself, but when you add up a bunch of small optimizations like this one, it can add up to be a significant improvement.
aswan 7y ago
> How much of a performance improvement does this make? For a user with an SSD, perhaps not much. But there are still a lot of users out there with magnetic hard drives. Firefox has to do a decent amount of I/O at startup, and unneeded disk seeks add up for these users. In addition, Firefox formerly checked for these files on the main thread, which is especially bad for performance. (Firefox engineer Mike Conley wrote about this at length at https://mikeconley.ca/blog/2019/05/16/a-few-words-on-main-thread-disk-access-for-general-audiences/ https://mikeconley.ca/blog/2019/05/16/a-few-words-on-main-th...) If you read through the related bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1541233 https://bugzilla.mozilla.org/show_bug.cgi?id=1541233), you can see that folks went to some trouble to keep anything from breaking for people using these files today. The claims that this is a step toward removing the files completely is FUD.
- zerocrates 7y ago
  My unscientific feeling as an outside observer is that there's a pretty common pattern in the browsers of making a feature harder to access, leading to less use of the feature, and then removing the feature when the telemetry data shows there are few users. I don't know if it's a purposeful process or not, but I'd say it's perfectly reasonable for users to think that pref-gating is the first step toward removal. The long road to RSS being completely removed from the browsers started with "just" taking it away from the defaults.
  - byuu 7y ago
    I mean that's exactly how Firefox operates. They divide the opposition to feature removals by continually allowing the most vocal critics a workaround, until finally when it's removed completely most people have already learned to live without them. They moved the option to keep browsing history but not keep download history to a user-pref, and then later removed it. They moved the option for tabs-on-bottom to a user-pref, and then later removed it. They moved the disable-automatic-updates to a user-pref, and then later buried it in an external policy JSON, which I guess it's okay to see if that file exists at startup but not the user*.css files. And on and on.
  - 7y ago
muizelaar 7y ago
Here's the bug about making it dependent on a pref: https://bugzilla.mozilla.org/show_bug.cgi?id=1541233 https://bugzilla.mozilla.org/show_bug.cgi?id=1541233 Even just checking for the existence of a file can take a really long time depending on the disk speed and other on going IO.
- joveian 7y ago
  Checking for the existence of the files could take time since they are in a different directory, but checking for the existence of the chrome directory (which doesn't seem to be used for anything else) should not require disk access since the directory contents are already cached due to accessing other files in that directory. One person mentioned checking for the directory in the bug report but the answer made it sound like they actually checked the speed of testing for the existence of the files in an empty directory rather than checking for the existence of the directory.
robocat 7y ago
Weird... Why wouldn't they just load them asynchronously? I read that custom CSS files are often used by disabled users, which makes it doubly odd that they would just disable it by default.
lkbm 7y ago
Oh man, I thought I was going crazy when Nightly refused to load my userContent.css a while back. I really need a better way to find these changes, and the settings to undo them. I almost left Firefox when they experimented with changing the tab switcher a while back -- I would have left had I not found the flag to turn it off.

by plopz 7y ago

dictum 7y ago

I use userChrome.css and userContent.css, and I get the nagging feeling that the silent end of that sentence is "...when we eventually replace the code that currently enables user customization with faster, less flexible APIs." (I'm paranoid and FUDing because I care: there's some UX low hanging fruit before they could get rid of userChrome.css. For instance, you need userChrome.css to autohide the toolbar in full screen mode on macOS — that's not even a customization, it's a missing feature.)

StavrosK 7y ago
I mean, how slow could an "if file_exists()" check have been? This smells like deprecation to me, if the user CSS doesn't exist, don't load anything. Boom, no slowdown.
- kbenson 7y ago
  Given that the profile setting is under a subsection of "legacyUserProfileCustomizations", perhaps there's a whole legacy subsystem they spin up to handle it that's only needed for that now? I could see a whole subsystem causing significant enough delay and resource usage to be noticeable, if that's the case.
  - rrix2 7y ago
    AFAICT it's Firefox's CSS+HTML engine running the user chrome. You can even open the firefox web inspector on it (open web inspector -> settings -> enable browser chrome and add-on debugging toolboxes) which lets you fiddle with the chrome DOM and modify CSS that way.
- bzbarsky 7y ago
  The technical answer to the question you asked is "10-20ms, if you're not on an SSD". That's not great, actually, if you're trying to shave tens of milliseconds at a time off startup performance. For what it's worth, this change happened because people were seeing the stat() call involved in startup profiles, taking sufficient time that it seemed worthwhile to avoid it if possible, as far as I can tell.
  - StavrosK 7y ago
    Are many users on HDDs these days? Weird that it would take this long, although I guess it's niche enough that you'd want to save those 20 ms for something used by a tiny fraction of users.
    - dblohm7 7y ago
      > Are many users on HDDs these days? Yes, there are. They are not a niche cohort. EDIT: In fact, we have many more users with magnetic HDDs than who use userChrome.css. That tells you everything you need to know about this decision right there.
    - jahlove 7y ago
      Just under half of desktops use magnetic drives, according to Western Digital. [1] [1] https://www.minitool.com/news/ssd-market-share.html https://www.minitool.com/news/ssd-market-share.html
  - xxs 7y ago
    >The technical answer to the question you asked is "10-20ms, if you're not on an SSD C'mon the directory structure would be cached already, even if it was not - the seek times for HDD are 3-4ms.
    - bzbarsky 7y ago
      The directory structure may or may not be cached already: these files are in a separate directory from everything else Firefox needs at startup. If your HDD has a seek time of 3-4ms on average, that means it needs to rotate completely in at most 6-8ms, which gives you a rotation speed of 7500-10,000 rpm. HDDs in data centers do that, sure. Consumer HDDs just don't do that, last I checked; they're mostly in the 5400-7200 rpm range, with laptops firmly in the 5400 bucket. See https://www.dell.com/en-us/shop/dell-laptops/sc/laptops?appliedRefinements=13242 https://www.dell.com/en-us/shop/dell-laptops/sc/laptops?appl... for example (currently offered Dell laptops "for home" with an HDD: they're all 5400rpm). At 5400 rpm, your average latency from just the rotation is 5.5ms and your worst-case latency from the rotation is 11ms. That doesn't include other latency sources, but let's assume those are somehow scheduled away to happen during the rotation. Keep in mind that what typically sticks in users' minds is worst-case, not average-case, behavior, so you have to bring your worst-case time budget down to whatever your target is.
- deleted 7y ago
  [deleted]
feanaro 7y ago
Unfortunately, I think you're right. Mozilla has been fighting a slow war on all powerful UI customization. See: the recent killing of Tridactyl.
- bovine3dom 7y ago
  Reports of our death have been greatly exaggerated :) You can still install Tridactyl in a normal installation of Firefox by following the instructions on our readme [1]. Admittedly, that may cease to be the case if Mozilla ever tire of us; people in locked-down corporate environments would then find it hard or impossible to install Tridactyl but we'd make it as easy as possible for everyone else. On topic, I'd argue that Mozilla are just desperately trying to cling on to ordinary users; the "war" against power users is a war of (totally understandable) neglect rather than spite. [1]: https://github.com/tridactyl/tridactyl/blob/master/readme.md https://github.com/tridactyl/tridactyl/blob/master/readme.md
  - Amezarak 7y ago
    Firefox gained the marketshare it did because power users relentlessly evangelized it to non-power users. There was some of the same phenomenon with Google, but the real difference is that Google pushed Chrome very strongly on the biggest web properties in the world, had it packaged in some other software installers, and advertised it. That's why Chrome has the market-share it does today. Mozilla appears to now be courting the ordinary user market without having either the passion of power users driving it, or the world's biggest web properties shilling it. To this day, visiting google.com (#1 website) in my default browser pops up a large notification informing me I need to switch to Chrome to 'hide annoying ads and protect against malware on the web.' Visting YouTube.com (#2 website) pops up a slightly less annoying notification on the bottom that says "Google recommends using Chrome, a fast and secure browser." I haven't been able to figure out for years now how they think this is going to work. Ordinary users are going to do what their IT administrator/IT friend says, use the OS default, or use products recommended by massive marketing campaigns.
    - bscphil 7y ago

xxs 7y ago

Virtually they removed it in 68 with setting the flag when any of the files was present. Unfortunately they also changed the css model, so even with the flag on - userChrome.css has become useless (to me)... I guess 66 will not be seeing an upgrade for the time being. As for the question - should be less than 1ms (depends on the OS/filesystem obviously but still negligible)

solarkraft 7y ago

Holy shit, just why? It makes virtually no difference. Neither applying CSS (they already use a lot) nor loading a file take any time.

megous 7y ago
Yeah, sounds like a non-reason, my user CSS was like 5 lines. I'll have to run an extension that will be injecting JS/CSS into every page, to get the same effect. That will likely be slower. Not a speed improvement exactly. At least it's more powerful. I can replace any rule inside already loaded CSS. Useful to escape this braindead age of "font-size < 16px && font-weight < 400".
- bzbarsky 7y ago
  If you have a user CSS, the "keep it working" pref has already been set for you, as of Firefox 68. So everything will keep working as it has.
kevingadd 7y ago
It has to have been showing up in profiles for them to bother, nobody would go out of their way to disable it otherwise. They added a pref to turn it back on and then disabled it instead of the easy thing (just removing it) which is some engineering effort plus testing effort to make sure the pref works right. Silly to do that for nothing. Antivirus software does add a measurable delay to file operations sometimes, and each file is gonna be in its own sector so I could see them losing at least a few milliseconds there. Applying CSS does add overhead but the average user can't have that many rules in there so I suspect it's purely on the file i/o level.
- bzbarsky 7y ago
  Not just that, but in an earlier release code was shipped to set the pref for users who already had the file, so that anyone who already had one of these files would not observe any behavior regressions. And yes, file I/O was the issue.

Sharlin 7y ago

Last time I tried, I just couldn’t get userContent.css to work at all. Maybe a user error, but I’d really like an easy way to set some default styles to override the inane Web 0.5 era defaults such as zero margins and unlimited-width paragraphs. Reading Good Old HTML (tm) pages sucks, and although there’s the reading mode, it tends to simply drop vital content it doesn’t happen to support…

plopz 7y ago
I've used https://github.com/Aris-t2/CustomCSSforFx https://github.com/Aris-t2/CustomCSSforFx ever since ClassicThemeRestorer broke when they killed the old extensions. It seems to work fine for me.

silverwind 7y ago

It's just a lame excuse really, such a change not improve performance in any noticeable way. I fear the change is just to take away this important customization option in the future and I don't like it.

bwat49 7y ago
by itself it won't, but they've been working on various optimizations to shorten startup time. A few ms isn't much by itself, but when you add up a bunch of small optimizations like this one, it can add up to be a significant improvement.

aswan 7y ago

> How much of a performance improvement does this make? For a user with an SSD, perhaps not much. But there are still a lot of users out there with magnetic hard drives. Firefox has to do a decent amount of I/O at startup, and unneeded disk seeks add up for these users. In addition, Firefox formerly checked for these files on the main thread, which is especially bad for performance. (Firefox engineer Mike Conley wrote about this at length at https://mikeconley.ca/blog/2019/05/16/a-few-words-on-main-thread-disk-access-for-general-audiences/ https://mikeconley.ca/blog/2019/05/16/a-few-words-on-main-th...) If you read through the related bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1541233 https://bugzilla.mozilla.org/show_bug.cgi?id=1541233), you can see that folks went to some trouble to keep anything from breaking for people using these files today. The claims that this is a step toward removing the files completely is FUD.

zerocrates 7y ago
My unscientific feeling as an outside observer is that there's a pretty common pattern in the browsers of making a feature harder to access, leading to less use of the feature, and then removing the feature when the telemetry data shows there are few users. I don't know if it's a purposeful process or not, but I'd say it's perfectly reasonable for users to think that pref-gating is the first step toward removal. The long road to RSS being completely removed from the browsers started with "just" taking it away from the defaults.
- byuu 7y ago
  I mean that's exactly how Firefox operates. They divide the opposition to feature removals by continually allowing the most vocal critics a workaround, until finally when it's removed completely most people have already learned to live without them. They moved the option to keep browsing history but not keep download history to a user-pref, and then later removed it. They moved the option for tabs-on-bottom to a user-pref, and then later removed it. They moved the disable-automatic-updates to a user-pref, and then later buried it in an external policy JSON, which I guess it's okay to see if that file exists at startup but not the user*.css files. And on and on.
- 7y ago

muizelaar 7y ago

Here's the bug about making it dependent on a pref: https://bugzilla.mozilla.org/show_bug.cgi?id=1541233 https://bugzilla.mozilla.org/show_bug.cgi?id=1541233 Even just checking for the existence of a file can take a really long time depending on the disk speed and other on going IO.

joveian 7y ago
Checking for the existence of the files could take time since they are in a different directory, but checking for the existence of the chrome directory (which doesn't seem to be used for anything else) should not require disk access since the directory contents are already cached due to accessing other files in that directory. One person mentioned checking for the directory in the bug report but the answer made it sound like they actually checked the speed of testing for the existence of the files in an empty directory rather than checking for the existence of the directory.

robocat 7y ago

Weird... Why wouldn't they just load them asynchronously? I read that custom CSS files are often used by disabled users, which makes it doubly odd that they would just disable it by default.

lkbm 7y ago

Oh man, I thought I was going crazy when Nightly refused to load my userContent.css a while back. I really need a better way to find these changes, and the settings to undo them. I almost left Firefox when they experimented with changing the tab switcher a while back -- I would have left had I not found the flag to turn it off.