Hacker News Reader

Comment by plopz | Hacker News Reader

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

View on HN

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

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.

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.

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.

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.

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.

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

Just under half of desktops use magnetic drives, according to Western Digital. [1]

[1] https://www.minitool.com/news/ssd-market-share.html

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

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

I will comment on the paragraph and the way directories are stored in b-trees, being a separate directiry doesn't have a lot if bearing unless talking about FAT.

Unfortunately, I think you're right. Mozilla has been fighting a slow war on all powerful UI customization. See: the recent killing of Tridactyl.

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

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.

This is it, exactly. No browser has ever gotten a dominant market share by convincing user Joe Average that it was better for their needs. That is an approach that is doomed to fail.

Just about every person I know that uses or used to use Firefox does so because I told them to use it or (more likely) I installed it for them. That's how most people start using Firefox.

I know Tridactyl is still installable, but the situation is not exactly reassuring about the viability of the extension in the future. Instead of a future in which Tridactyl asymptotically approaches the smoothness of Pentadactyl/Vimperator, I now have a vision of a future where a moderate-to-high amount of work has to be periodically invested in order to perhaps maintain the same level of functionality.

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

Perhaps, but meanwhile, as we muse about Tridactyl and the abandonment of userChrome and userContent, a thread about the possibility of Firefox removing webRequest in the future rises to #2. It's getting harder to justify Firefox and Mozilla by the moment.

> 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-th...)

If you read through the related bug (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.

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.

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.

There's a very good point here about the limits of using usage telemetry -- given a question of the form "should we invest in improving feature X?", it's a mistake to decide not to simply on the basis of low usage. Low usage could be because users simply aren't interested in the feature (in which case it probably doesn't make sense to invest in improving it), or it could be that they really are interested in it but they don't use it because of limitations (in which case it may well make sense to invest in improving it).

However, I don't believe that's an issue for the specific features discussed here (userChrome.css and userContent.css). These are by their nature features that are only accessible to users with particular knowledge/skills and the Firefox user base is much broader than web developers. But moreover, nobody is proposing to remove this capability and I think its debatable whether it is now harder to access in practice (existing profiles that use this capability were automatically converted, for new profiles you already have to manually add a file to the profile directory, flipping a preference in addition is not a serious barrier).

> 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

It might be reasonable if no other reason was given, but there is a specific and compelling reason (avoiding unneeded main thread I/O during startup for something like 99% of users) here.

I also think this is a pretty reasonable change, since it already requires users to edit files, so about:config is not really a major additional step.

But I also would imagine the usage was quite low already and any incremental hassle will push it lower and it won't be hard to get to an analysis where maintaining a rarely-used non-default codepath is seen as not worth it. Of course it all depends on what's going on with the specific code at issue, but the basic point of my post is that "nobody is proposing to remove this capability" is true, until it isn't.

This isn't a feature I actually use, but I also find the removal of a minuscule startup delay of a program I don't actually start very often to be a pretty marginal improvement, so I don't really have skin in the game in either direction.

I use the feature, but only because an extension I used before, ClassicThemeRestorer, isn't supported in the new extension ecosystem. The only workaround is to use the css files. I would imagine a large percent of people that used to use the extension didn't migrate to the css files when extensions broke. So they wouldn't be counted in metrics. Also the experience is much worse for an end user since extensions auto update, but changes to the css files have to be manually updated.

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…

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

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)

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.

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.

Here's the bug about making it dependent on a pref: 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.

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.

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.

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.

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

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

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.

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.

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.

Yeah, I checked and it was automatically enabled for me, so no regression.

Thank you for doing this!

I can't claim credit for it; I hadn't even realized it had happened until I dug a little bit into the history while reading this thread. All I knew was that my userChrome.css was still working fine... ;)

Reply on news.ycombinator.com