User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:81.0) Gecko/20100101 Firefox/81.0

Steps to reproduce:

Opened Firefox on another machine.

Encountered a news site with a video which, following standard web design practices, won't scroll out of the way.

Switched to reader view to try to avoid the resulting migraine.

Actual results:

But because my user css wasn't synced, the reader view nav buttons wouldn't scroll out of the way either.

Expected results:

If user css were synced with the rest, this wouldn't be a problem.

I don't want the syncing process to write bad user css over better user css though so it may take some tweaks to avoid that.

This is a terrible idea, speaking from the POV of someone who is very active in the Firefox support. People synchronisize data across Firefox versions and while it's not a problem at all for bookmarks, history or passwords it would be a big problem for userChrome.css customizations because there are really a lot of compatibility issues between Firefox versions. In our German Firefox support forum the area for user customizations is the most active area of the whole support forum and a not that small part of that is fixing customizations after Firefox updates. Syncing these customizations would increase the problems and therefore the support effort.

I'm not sure why this would be worse than the other things Firefox syncs. For example, the search bar preferences.

There are almost no limits what you can do with userChrome.css and the customizations can break the user interface of Firefox in unexpected ways if you apply a customization to a wrong Firefox version. Fortunately most times it doesn't means that Firefox is unusable but people customize the user interface because they want to change some things and these changes do often not work at all or work differently when applied to a wrong Firefox version. That's a totally different story than syncing search bar preferences. I don't see how there should be a similar risk or support effort.

If customizations no longer works after an update it's kind of expected. Most people understand (at least after an explanation) that changes in Firefox can cause problems with customizations and that customizations has to be adapted. But syncing customizations would mean that a breaking of customizations happens all the times. That's really bad. It's important not to mix customizations for different Firefox versions because it may work for many customizations, but it won't work for many other customizations.

Sören, it sounds like you're talking about customizable widgets/areas, but user stylesheets can't affect the state of those in any meaningful way. Stylesheets are just a transitory layer, so syncing them wouldn't affect the state of any data except its own. For example, userChrome.css might visually hide a toolbar button, but it can't change its placement on a toolbar. If an update ends up breaking a style rule in some way, then that's going to cause a problem for the user whether the stylesheet is synced or local. And whether the stylesheet is synced or not, removing the stylesheet will eliminate any problems that result. It's not like it runs the risk of breaking the user's profile. In principle, extensions can do much more damage to a user's profile, session store, cache, etc.

I don't think syncing user sheets is a good idea though, in part because there's no theoretical upper limit on the size or complexity of the stylesheet environment. They can import an unlimited number of stylesheets and reference an unlimited number of local files in an arbitrarily deep file hierarchy. Even if firefox didn't limit size as it does with storage.sync quotas, I'm skeptical that it's worth accounting for all these things just to provide a marginal feature for a narrow segment of the user base.

userChrome.css users are taking on additional responsibility for their setup on purpose (same reason the point about incompatibility/updates is irrelevant), so adding the veneer of an official, fully fledged API is unnecessary. Users who really want some semblance of mainstream support can use 1) a webextension with the theme_experiment manifest key instead of userChrome.css; and/or 2) a webextension like Stylus or Greasemonkey instead of userContent.css.

If an update ends up breaking a style rule in some way, then that's going to cause a problem for the user whether the stylesheet is synced or local.

The file is always local even if it gets synced. But that was not what I said. The point was that Sync does not differentiate between Firefox versions. The content of the userChrome.css file for Firefox n can break Firefox n+1 or Firefox n-1 in bad ways. And it's not transparent to users why the design suddenly breaks. It's a totally different story than syncing bookmarks or logins.

userContent.css and userChrome.css changes are common suggestions among safety and accessibility fixes.

Yes, Stylus is another suggestion. But Stylus and other add-ons can't change Firefox's internal layouts, or change Mozilla's web pages. So if you need to be able to read about:preferences, or to read support.mozilla.org, userChrome.css and userContent.css are necessary anyway. And Firefox can sometimes wipe extension settings. Firefox wiped my Style settings a while back, when it still used the same pfofiles for standard and Nightly, and when I tried to test whether a bug occured in Nightly.

(In reply to Sören Hentzschel from comment #5)

The content of the userChrome.css file for Firefox n can break Firefox n+1 or Firefox n-1 in bad ways. And it's not transparent to users why the design suddenly breaks. It's a totally different story than syncing bookmarks or logins.

It definitely can't. That was the whole point of my post. It's 100% visual, nothing bad is going to happen if your style rules are outdated. You're right it's a different story from places — syncing from a bad database actually can mess up your profile, unlike stylesheets. Unless user is embedding some kind of malicious code in their stylesheet I don't see how it can cause any harm whatsoever. But there are several other things I would rather sync before stylesheets, I think this one is pretty low on the priority list.

(In reply to MarjaE from comment #6)

userContent.css and userChrome.css changes are common suggestions among safety and accessibility fixes.

Yes, Stylus is another suggestion. But Stylus and other add-ons can't change Firefox's internal layouts, or change Mozilla's web pages. So if you need to be able to read about:preferences, or to read support.mozilla.org, userChrome.css and userContent.css are necessary anyway. And Firefox can sometimes wipe extension settings. Firefox wiped my Style settings a while back, when it still used the same pfofiles for standard and Nightly, and when I tried to test whether a bug occured in Nightly.

Yeah I'm aware of the limitations of webextensions, that was what I was trying to get at. User stylesheets aren't officially supported so it would be quite a massive shift to start syncing them. For that to happen they would probably need to be validated and restricted in ways they currently aren't, which would negatively impact most of their users. And I don't think that's worthwhile because we already have officially supported, synced, validated, restricted systems for injecting CSS: webextensions' theme_experiment key and content stylesheets. They aren't as powerful as user stylesheets, but that was my point — the freedom comes at the cost of signing and addons integration. I use userChrome.css and userContent.css and don't want them being validated or restricted in any way. I don't worry at all about losing them because my profile's chrome folder is a git repository. I'd recommend doing the same with yours. I haven't configured mine to push automatically but you could, in principle.

It definitely can't. That was the whole point of my post. It's 100% visual, nothing bad is going to happen if your style rules are outdated.

This is just not true. I operate the largest Firefox forum in the German speaking regions where we help users with individual customizations every day. So I know what I am talking about. Just a few days ago when Firefox 96 was released some customization didn't work as before and the tabs suddenly looked differently for affected users. And much worse things can happen because there is no limit to what you can do with userChrome.css.

Something temporarily looking differently for a user until they deign to update or remove their custom stylesheet is not equivalent to "firefox breaking."

It can be breaking for some users.

With my eyesight, and without userChrome.css, Firefox preferences and about:config are almost unreadable. They use tiny gray or black text in a difficult font, on a gray background. They ignore the Firefox font and font size preferences, presumably because users who break those prefs need some way to unbreak them.

With my eyesight, and without userContent.css, but with the font preferences, most other pages are still pretty hard to read.

Now I haven't found adequate css to block all the standard migraine triggers, such as non-scrolling sidebars, such as on about:preferences. I end up having to either reduce frame rates to 1/second or switch to Page Down where that works or switch to search bar navigation... But I rely on css to kill a lot of transformation effects on a lot of sites.

(In reply to MarjaE from comment #10)

With my eyesight, and without userChrome.css, Firefox preferences and about:config are almost unreadable. They use tiny gray or black text in a difficult font, on a gray background. They ignore the Firefox font and font size preferences, presumably because users who break those prefs need some way to unbreak them.

What version of Firefox and what theme are you using? With the default theme, the background on about:preferences and about:config is #ffffff and the text color is rgb(21, 20, 26)

User color preferences don't affect about:preferences. But I was testing with the default settings. (And getting sick from them, as always.)

User color preferences do affect about:preferences, as they affect all non-native themed elements. You can switch between light mode and dark mode and of course you can also switch the accent color. Anyway, that wasn't my point. You said "They use tiny gray or black text in a difficult font, on a gray background." But the background of about:preferences and about:config is white, #ffffff, not gray. So you must be mistaken or using some other version of Firefox or some modified theme.

User color preferences do affect about:preferences,

It's a bit completely counter-intuitive, but there are some explanations in bug 1740850.

If users don't set color preferences override page preferences, then Firefox will apply operating system colors in about:preferences.

If users set Firefox to "Never" have our color preferences override page preferences, then Firefox will apply users' color preferences in about:preferences.

If users set Firefox to "Always" have our color preferences override page preferences, then Firefox will apply operating system colors. On MacOS, that results in a definite gray background, unless users go into System Preferences and set Increase Contrast there, which will break other apps.

So you must be mistaken or using some other version of Firefox or some modified theme.

Firefox for Mac, 95.0.2 when I reported this, and whichever Nightly when I checked the default behavior in Mozregression.

Sorry. screwed up my 2nd line:

If users don't set color preferences, then Firefox will apply operating system colors in about:preferences.

(In reply to MarjaE from comment #14)

Firefox for Mac, 95.0.2 when I reported this, and whichever Nightly when I checked the default behavior in Mozregression.

So wait, what is your browser.display.use_system_colors set to? That's the checkbox in the color settings in about:preferences that says "Use system colors" (in English, that is). I tried to reproduce the gray color you mentioned with the "Always" setting, but for me, it's still #ffffff on 95. Pretty sure that gray color is not defined in fx source code so maybe it differs by macOS version.

Anyway, I think you might be misunderstanding me. I said that userChrome.css is not going to break someone's Firefox installation or profile. I didn't say that users don't need userChrome.css, or that not having it would cause accessibility issues. Just the opposite really. If you had read my comments, you would know that I use it myself. I have over 10,000 lines of CSS in my profile and publish an enormous userChrome.css theme for public consumption. I am an extensive user of the system, you don't need to convince me that it's worthwhile.

I wasn't addressing you in my previous comments at all. Rather, my comments were directed to Sören, who argued that stylesheets should not be synced because if they get downloaded when we log in on another computer, and that computer has an older or newer version (or different release channel) of Firefox installed, it could break something. My point is that it might make something look ugly, it might not appear as intended without further user modifications, but 1) that's not breaking Firefox, and 2) that has nothing to do with syncing the stylesheet. The same thing would happen if we manually installed the stylesheet.

It's unchecked.

P.S. For me, the background color for about:preferences is #ebebeb. That's the same as the edges of System Preferences.