[meta] [gtk] Remove full-native theming for content

REOPENED
Unassigned

Status

()

enhancement
P3
normal
REOPENED
2 years ago
a month ago

People

(Reporter: Paul.Hancock.17041993, Unassigned)

Tracking

(Blocks 6 bugs, {meta})

56 Branch
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fingerprinting][overhead:noted][fp-triaged])

Reporter

Description

2 years ago
+++ This bug was initially created as a clone of Bug #1158076 +++

Due to various various theme issues between platforms and HTML native theming, among other things, native theming should be removed entirely and instead replaced with internal 'native' elements in the browser itself.

Intended objectives;
- Fixes light-and-dark theme issues, HTML elements are kept consistent
- Fixes scaling issues, most particularly the scrollbar
  (removes the need for a override setting in the theme)
- Behaviour and any bugs should be more consistent and easier to resolve
  (project maintenance improvements)
- Overall the GUI and HTML code should then remain identical across all platforms, making it easier for the end-user as well as for future design changes

and a couple mentioned in #1158076#c149 ;
- Removes chances of fingerprinting by toolkit/platform
- Removes dependency on the toolkit of the content process
  (lower complexity and thus lower maintenance)
Reporter

Updated

2 years ago

Comment 1

2 years ago
(In reply to Paul17041993 from comment #0)
> - Removes chances of fingerprinting by toolkit/platform

I highly doubt websites have access to the platform toolkit informations. Only User Agent give away user's OS.

Comment 2

2 years ago
(In reply to Clément Lefèvre from comment #1)
> I highly doubt websites have access to the platform toolkit informations.
> Only User Agent give away user's OS.

Sure, but I think the idea is that you can measure how large e.g. a text widget is and find out which OS/toolkit the user might be using given on how large things are scaled per default. While it's certainly not trivial to do, there is some potentially identifying information to be found out with that approach.

Comment 3

2 years ago
_Please_ for the love of all that is mozilla, make this happen. I rarely login to comment on things, but I am so tired of fighting with GTK on linux with Firefox. Please instead of acquiescing by allowing different themes just get rid of it altogether like chrome. (I hate saying "like chrome" but here it applies)

Comment 4

2 years ago
I, for one, prefer retaining the platform specific widgets. I even use a dark theme and while there are issues with some websites, the look is still far superior. More of an evangelism problem.
Reporter

Comment 5

2 years ago
(In reply to Jan Tojnar from comment #4)
> I, for one, prefer retaining the platform specific widgets. I even use a
> dark theme and while there are issues with some websites, the look is still
> far superior. More of an evangelism problem.

doesn't bug #1158076 remove that though?

Comment 6

2 years ago
(In reply to Paul17041993 from comment #5)
> (In reply to Jan Tojnar from comment #4)
> > I, for one, prefer retaining the platform specific widgets. I even use a
> > dark theme and while there are issues with some websites, the look is still
> > far superior. More of an evangelism problem.
> 
> doesn't bug #1158076 remove that though?

Fortunately, you can still override it with widget.chrome.allow-gtk-dark-theme.
(In reply to Jan Tojnar from comment #4)
> I, for one, prefer retaining the platform specific widgets. I even use a
> dark theme and while there are issues with some websites, the look is still
> far superior. More of an evangelism problem.

I think this bug report should apply to the content process only. The chrome may need to use the native toolkit for file dialogs, print dialogs, context menu and other stuff. Having non-native widgets here would be bad for UX due to missing UI consistency with the OS. Content widgets in websites, on the other hand, rarely are unstyled and thus rarely look like the native toolkit widgets anyway.

@Paul (the reporter): Can you please change the title in case you agree?

Comment 8

2 years ago
(In reply to Christian Stadelmann from comment #7)
> I think this bug report should apply to the content process only. The chrome
> may need to use the native toolkit for file dialogs, print dialogs, context
> menu and other stuff. Having non-native widgets here would be bad for UX due
> to missing UI consistency with the OS. Content widgets in websites, on the
> other hand, rarely are unstyled and thus rarely look like the native toolkit
> widgets anyway.

I actually meant widget.content.allow-gtk-dark-theme. I would not say that unstyled widgets are that rare, it is one of the reasons why using Chrome is an eyesore for me.

Toolkit specific inputs are also required for native-looking web apps.
Reporter

Updated

2 years ago
Summary: Remove full-native theming → Remove full-native theming (for content)
Reporter

Comment 9

2 years ago
(In reply to Christian Stadelmann from comment #7)
> I think this bug report should apply to the content process only. The chrome
> may need to use the native toolkit for file dialogs, print dialogs, context
> menu and other stuff. Having non-native widgets here would be bad for UX due
> to missing UI consistency with the OS. Content widgets in websites, on the
> other hand, rarely are unstyled and thus rarely look like the native toolkit
> widgets anyway.
> 
> @Paul (the reporter): Can you please change the title in case you agree?

I'd actually like the rest of the window stuff to be replaced with Qt as GTK+'s dialogues are pretty horrendous and a pain to use, but that request would go in a separate report.
Changed the title to clarify that we're talking about the content only, though I don't know in that sense which component is the more correct one... (widgets? graphics? other?)

Comment 10

2 years ago
Yeah the main problem here is if you're using KDE, with a dark theme (where you will likely have Breeze-dark) _there is no light variant_. It's *not* like Adwaita:dark,light, they're separate themes. 

So in my case, and I'm sure in many others..  widget.chrome.allow-gtk-dark-theme does absolutely squat. Which is when widget.content.gtk-theme-override comes in and you can specify Breeze (or if you have it named breeze-light, rarer).... and none of this is publicized or documented...


Please just make it stop. I want my scroll bar to match my GTK theme and colors, and I want the content widgets to be FF's own brand of whatever whiteness widget pack they want. Currently the best you can do is set a white GTK theme with widget.content.gtk-theme-override and you also get a white scroll bar.
Whiteboard: [fingerprinting]

Comment 11

a year ago
(In reply to Paul17041993 from comment #9)
> I'd actually like the rest of the window stuff to be replaced with Qt as
> GTK+'s dialogues are pretty horrendous and a pain to use,...
Qt's are worse. I suspect you're thinking of KDE.
Reporter

Comment 12

a year ago
(In reply to x3 from comment #11)
> (In reply to Paul17041993 from comment #9)
> > I'd actually like the rest of the window stuff to be replaced with Qt as
> > GTK+'s dialogues are pretty horrendous and a pain to use,...
> Qt's are worse. I suspect you're thinking of KDE.

You seem confused, QT's default dialogues are very close to native and perfectly usable, they can also be customised. GTK+'s on the other hand are really dumb, backwards and not user friendly...

Comment 13

a year ago
(In reply to Paul17041993 from comment #12)
> You seem confused, QT's default dialogues are very close to native and
> perfectly usable, they can also be customised. GTK+'s on the other hand are
> really dumb, backwards and not user friendly...

I don't know what you by native. I have seen Qt5's open/save window and it is in no way superior to gtk(2 for that matter). The one in kde is. I suspect the one who is confused is you.
Reporter

Comment 14

a year ago
(In reply to x3 from comment #13)
> (In reply to Paul17041993 from comment #12)
> > You seem confused, QT's default dialogues are very close to native and
> > perfectly usable, they can also be customised. GTK+'s on the other hand are
> > really dumb, backwards and not user friendly...
> 
> I don't know what you by native. I have seen Qt5's open/save window and it
> is in no way superior to gtk(2 for that matter). The one in kde is. I
> suspect the one who is confused is you.

OS? because QT's default structure is very much native to windows, and subsequently the standard linux and mac structure (quick list on side, address on top with forward, back and up buttons, file list in the middle, file textbox below and the open/save and cancel buttons in the bottom right.)

GTK+'s discards everything, gives you a wonky file list in the center and a jumplist on the side, with all the buttons scaled up to make for the empty space with the whole window also being twice the size, absolutely horrible and unusable for proficient desktop users...

Comment 15

a year ago
Please *keep* native theming. Native theming is important for UI consistency across the desktop.
Reporter

Comment 16

a year ago
(In reply to Yuri Khan from comment #15)
> Please *keep* native theming. Native theming is important for UI consistency
> across the desktop.

... except native theming *creates* inconsistency between platforms and even across the same platform, hence why it's so problematic and broken...

Comment 17

a year ago
Websites don't adjust to the system theme anyway apart from a few basic UI elements, so what's the point of keeping native themeing for those? I agree that it would be less surprising to just get rid of it, and ignore the system theme completely - as 99% of all other parts of the web content do. It solves all issues with dark themes messing up the font colors on inputs, looks more consistent etc.

Comment 18

a year ago
If every application strives to maintain consistency with itself across platforms and desktop environments, then each individual user’s desktop will become a broken mess. And I do not want a broken mess on my desktop, thank you very much. On my desktop, I would like consistency between Firefox and all other applications.

I can see how native theming is problematic for the browser developers. They have been dealing with it quite well for the last 15 years.

I would also prefer if web site designers became conscious about the users’ preferences and stopped violating them on every occurrence. (I regularly have to write custom CSS to enforce my preferences.)

Comment 19

a year ago
But what you want is already 99% not there. It seems like a nice idea, but in practice it's pretty much dead already. Can you name a single website where the major background and design colors follow your system theme these days?

I get where you're coming from, but in practice I just don't see this as a good reason given most websites ignore all of this already. Giving it up for the input elements as well is just one last step to admit the reality of modern web.

(also, on a more practical note, wouldn't it just need about 2 rules in your custom CSS to style the inputs on all sites per default back to whatever you want? That should be comparatively few effort to styling all the other 99% of a website to whatever colors you like, which is what you need to do for pretty much all websites anyway to get them to adhere to your system theme.)

Comment 20

a year ago
The motto of Firefox is “Take back your web”. It’s supposed to help me in that, not add more things I need to take back.
Reporter

Comment 21

a year ago
(In reply to Yuri Khan from comment #18)
> They have been dealing with it quite well for the last 15 years.

It's been broken for the past 15* years actually, as far as I know. Ironically as well, this bugzilla site itself is one of the sites affected by the broken native theming, of which if you go between different platforms with FF you'll find the site tends to only be working properly on windows. On other platforms you often get a hit-and-miss of UI elements in the wrong colours, shapes, size and position, inoperable or just missing entirely...

Native theming in HTML content breaks the base concepts of web design...

Comment 22

a year ago
As far as I am concerned, the one base concept of web design is that you cannot rely on anything and must be prepared to work reasonably well in any conditions. Black text on white, green text on dark gray, orange text on green, small fonts, large fonts, wide screens, ridiculously narrow screens (320px), reasonably medium-sized but still too narrow for most of the sites out there screens (960px), serif fonts, sans-serif fonts.

If your role model for design is print magazines where everything is under the designer’s control, well, I can’t reason with you.

Comment 23

a year ago
So you want to make it worse by introducing even more variables? Let alone one that is having considerably tiny impact: after all the input boxes make up really few of your screen space and do much less to the overall color appearance than e.g. the site's overall foreground font or background text which don't adapt.

And before you suggest they do, HTML/CSS do come with some design and just because you don't like it, won't suddenly make all sites magically adapt to your preferred color scheme without issues. And all of others with us have to deal with the mess that input color schemes already introduce, making websites _unusable_ because it leads to same text foreground and background color (arguably worse than an unfulfilled desire for nicer colors adopted to the system theme) and make bug ticket over bug ticket because it simply doesn't work, and that's just for the little input styling we have left right now.

Comment 24

a year ago
> So you want to make it worse by introducing even more variables?

In principle, making the problem more acute should make more web site developers aware of the challenges in which they are working.

> same text foreground and background color

That is a web site coding bug, clearly spelled out by the W3C CSS validator. The proper way to deal with it is to demand a fix from the site developer. Failing that, custom CSS.


Okay, forget the colors, that is indeed easily fixable with a few lines of CSS (provided that system colors continue to be supported despite their deprecation in CSS 3).

What I’m worried about is that I will have to reverse-engineer the GTK+3 theme I use and figure out how to style Firefox’s buttons, check boxes, radio buttons, single- and multiple-line inputs, and scroll bars. And then repeat that for every other application out there that wants to have its own widget toolkit and is “nice” enough to make it themeable. And then repeat that every time that I want to try a different theme.

Comment 25

a year ago
> That is a web site coding bug, clearly spelled out by the W3C CSS validator

You're pretty naive if you think the W3C CSS validator can catch Firefox / GTK+ native themeing / complex website CSS color interactions reliably.

> What I’m worried about is that I will have to reverse-engineer the GTK+3 theme I use and figure out how to style Firefox’s buttons, check boxes, radio buttons

I think you might have misunderstood the scope of the suggestion. This ticket suggests only removing the themeing of the website *content* area, not Firefox' regular UI elements. All the dialogs and such outside of the actual website content would continue to adhere to the system theme as usual.

> And then repeat that for every other application out there

That's unfortunate, but not really the firefox developer's fault (as isn't the state of CSS/modern website design). And inconsistent themeing is a smaller problem than actually breaking the websites for people. And if you think those are "web site coding bugs", maybe you're right but that still means people won't be able to use some websites just because you would prefer different colors.

Comment 26

a year ago
> I think you might have misunderstood the scope of the suggestion. This ticket suggests only removing the themeing of the website *content* area, not Firefox' regular UI elements.

I understand this suggestion as a request to kill native-looking inputs and buttons and checkboxes and radiobuttons in web forms and replace them with some generic-looking custom widgets designed by someone at Mozilla, and I object to that.

Especially in the case of input boxes and textareas and scrollbars, the native widget implements a thousand platform- and environment-specific nuances. Reimplementing them from scratch is bound to get about half of them wrong on each platform and environment.

Also, as soon as it uses form controls, it is not “content” any more. It is an application, just one that happens to be using the browser as its UI framework. Ideally, it needs to be consistent with the desktop. At the very least, it needs to *be able to* be consistent with the desktop, so that developers who value that consistency could actually provide it to their users.

Comment 27

a year ago
As a constructive suggestion, if CSS offered a way to access system colors reliably (that is, not without the inherit way which will sometimes inherit system colors and sometimes not in major browsers but in some explicit way) for web apps that want to that would be actually helpful. So you might want to bring this in to the W3C CSS forum since this topic is obviously important to you.

However, native themeing pretty much gives you small dark spots in glaring white for a dark system theme, I really don't see how that helps with fitting in as you want it - or does anything useful at all except break some web applications. However, I suppose now we know each others' opinions and most points have probably been made in this discussion, so I'll refrain from further postings.
(In reply to Paul17041993 from comment #0)
> Due to various various theme issues between platforms and HTML native
> theming, among other things, native theming should be removed entirely and
> instead replaced with internal 'native' elements in the browser itself.

Thanks for filing this bug. This work is actually part of the roadmap for a content isolation feature we want to turn on for Windows users. We'll likely standardize and do this for all platforms.
Status: UNCONFIRMED → NEW
Ever confirmed: true
BTW, you can turn this off now but you'll fall back on our ancient default css down in toolkit, which isn't pretty. The pref that controls this is 'mozilla.widget.disable-native-theme'.

Comment 30

a year ago
This is a serious bug. 
Various websites have white text on white background. 

Current workaround implies willingness to tinker with either:
a) firefox.desktop, to enforce a GTK light theme (which makes firefox totally alien tot the overall dark environment)
or 
b) chrome/userContent.css 

I'm a web developer I don't want anyone to tinker with how the pages I design look, just because they try to avoid a freaking bug. If they hate my site, they can leave feedback or do some css tinkering (maybe for my site only), anyway it's not Firefox's purpose in life to question the quality of my work.

A lot of users are simply not inclined to do the tinkering because they are not tech savvy. They will just use another browser, because for them Firefox is broken.

Please stop the arguing if browser forced content styling is nice to have or not, this is not the issue here. Without applying one of the two inconvenient workarounds you cannot use some websites. Which makes Firefox not fit for its purpose. Bottom-line this is a bug, not a feature. 

My 1.5cents on the debate above: If forced styling is desired, for the really hardened native-ui-white-on-white lovers, there should be a hidden option in config:about. Not the other way around.

Comment 31

a year ago
(In reply to Jim Mathies [:jimm] from comment #29)
> BTW, you can turn this off now but you'll fall back on our ancient default
> css down in toolkit, which isn't pretty. The pref that controls this is
> 'mozilla.widget.disable-native-theme'.

"Isn't pretty" is a bit of an understatement - as I type from a browser with this setting enabled, so far I've noticed that any menu area is completely invisible, and widgets in add-on preferences pages are non-existent. Right click menus, transparent. If you try it and see, you'll understand what I mean, It's not usable.

Comment 32

a year ago
(In reply to Joe Nukkens from comment #30)

> Various websites have white text on white background. 

> I'm a web developer I don't want anyone to tinker with how the pages I
> design look, just because they try to avoid a freaking bug.

As a web developer, it is your responsibility to avoid the bug by always specifying both the foreground and background colors or neither of them. (This also includes background images, gradients, etc.) If you do, make sure they have enough contrast.

Additionally, if you really don’t want us tinkering, you can design both a light and a dark theme for your site, offer your users a choice, and remember it.

Ideally, there would be a convention, such as a @media query, by which sites could adapt to the user’s overall UI theme.

Comment 33

a year ago
(In reply to Yuri Khan from comment #32)
> (In reply to Joe Nukkens from comment #30)
> 
> > Various websites have white text on white background. 
> 
> > I'm a web developer I don't want anyone to tinker with how the pages I
> > design look, just because they try to avoid a freaking bug.
> 
> As a web developer, it is your responsibility to avoid the bug by always
> specifying both the foreground and background colors or neither of them.
> (This also includes background images, gradients, etc.) If you do, make sure
> they have enough contrast.
> 
> Additionally, if you really don’t want us tinkering, you can design both a
> light and a dark theme for your site, offer your users a choice, and
> remember it.
> 
> Ideally, there would be a convention, such as a @media query, by which sites
> could adapt to the user’s overall UI theme.

I'm not talking about my sites here, now that I am aware of the bug, I'm taking care of them, no worries. But what about the other developers not using Firefox on Linux with dark theme, are they aware of the bug?

I'm talking about all sites out there. Since you seem to be on a crusade to better all them developers, until you personally, or someone else, manage to reach out and convince all developers of all affected websites to apply your suggestions your comment is not helpful. We're not talking some ideal case here. 

It's a bug, affecting real people, in the present.

Comment 34

a year ago
> I'm talking about all sites out there. Since you seem to be on a crusade to better all them developers, until you personally, or someone else, manage to reach out and convince all developers of all affected websites to apply your suggestions your comment is not helpful. We're not talking some ideal case here. 

That is evangelism issue. Let us be the change we want to see in the world – I already reported the problem on four sites I visited (including AMO https://github.com/mozilla/addons-server/pull/1168) and they fixed it promptly.

Comment 35

a year ago
This is not feasible. changes need to be paid, who will pick up the bill for all affected sites out of billions out there. and who will reach out to all of them? 

And what does your solution solve? Did you implement different options for light and dark theme users? Or just applied the chrome/userContent.css fix at the other side of the yard? That's kind of nonsense solution if you ask me. It defeats the purpose of having this "feature" in Firefox the first place.
Since this bug aims to change the appearance of HTML form controls in
web content, I request that the overall plan of these changes is
reviewed and approved by someone working on our CSS / Layout code.
In particular, it should be reviewed by someone who understands how
-moz-appearance and CSS cascading works, and has knowledge about how
form controls are typically styled by web authors.

This is very important, because the last time something like this was
tried (bug 418833) we had to spend a lot of time reverting that mess
(bug 1352406, bug 1357169) and eventually *add* native themeing for
Android to solve the problem properly (bug 1352238).

Please beware the dragons...
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1381938
Reporter

Updated

a year ago
Status: RESOLVED → REOPENED
Depends on: 1381938
Resolution: DUPLICATE → ---
Reporter

Comment 38

a year ago
not a duplicate as it affects all platforms, not just win32...
No longer blocks: win32k-lockdown
Priority: P2 → P3
Blocks: 1461538
Blocks: 1470983
Whiteboard: [fingerprinting] → [fingerprinting][overhead:noted]
Blocks: 1373548
Blocks: 1283086

Updated

6 months ago
Whiteboard: [fingerprinting][overhead:noted] → [fingerprinting][overhead:noted][fp-triaged]

Updated

6 months ago
Summary: Remove full-native theming (for content) → Remove full-native theming (for content)(fingerprinting)
Blocks: 70315

Comment 39

4 months ago

you could just add 'env GTK_THEME=Adwaita' to the .desktop which is created when you press the 'Make default' button in settings

Updated

2 months ago
See Also: → 1381938

we'll file

No longer depends on: 1381938
Keywords: meta

Updated

2 months ago
Summary: Remove full-native theming (for content)(fingerprinting) → [gtk] Remove full-native theming for content

Updated

2 months ago
Depends on: 1381938

Updated

2 months ago
No longer depends on: 1381938
Summary: [gtk] Remove full-native theming for content → [meta] [gtk] Remove full-native theming for content
Duplicate of this bug: 1536166
You need to log in before you can comment on or make changes to this bug.