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.