[aswan]

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.

[zerocrates]

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.

[plopz]

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.