Closed Bug 1726283 Opened 4 years ago Closed 3 years ago

widget.non-native-theme.enabled config option not working as expected

Categories

(Core :: Widget: Gtk, defect)

Product:
Core
Component:
Widget: Gtk
Version:
Firefox 90
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: radu, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:90.0) Gecko/20100101 Firefox/90.0

Steps to reproduce:

Single step: Set widget.non-native-theme.enabled to false.

Context: Using Firefox 90.0.2 on Fedora 33 (64-bit). Can also be reproduced on 93.0a1 (2021-08-17).

Actual results:

Scrollbars are still rendered using the Firefox built-in style instead of using the system theme style. However, all other widget.non-native-theme.gtk.scrollbar.* settings (if configured to anything other than the default) are ignored as expected.

Expected results:

Scrollbars should be rendered using the system theme style.

Notes:

  • This looks like a regression since Firefox 89. The setting worked as expected in that version.
  • I also checked with a local HTML-only (no CSS) page just to rule out any interaction with CSS.
  • The Settings page uses the system theme scrollbars. The bug only affects web page rendering.
  • Also posted this question in the forum https://support.mozilla.org/en-US/questions/1345109 but nobody was able to help. It really looks like a bug.

The Bugbug bot thinks this bug should belong to the 'Core::Widget' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Widget
Product: Firefox → Core

I believe this should be working as expected now. Could you please confirm?

Component: Widget → Widget: Gtk
Flags: needinfo?(radu)

Thank you for the feedback. I tested the latest nightly build: 99.0a1 (2022-02-07) (64-bit). It's still not working as expected but the behavior is slightly different from what I saw on older versions:

  • When I set widget.non-native-theme.enabled to false, scrollbar arrow buttons become visible. But the scrollbar itself still looks like the built-in theme.
  • Scrollbar appearance is now consistent between a regular web page and the Settings page. In older versions, the Settings page would use the system theme.

I forgot to mention in the original bug description. I'm using MATE Desktop with the TraditionalOk theme.

Flags: needinfo?(radu)

(In reply to Radu Rendec from comment #3)

  • When I set widget.non-native-theme.enabled to false, scrollbar arrow buttons become visible. But the scrollbar itself still looks like the built-in theme.

You can get scrollbar arrows without disabling the native theme by using the widget.non-native-theme.gtk.scrollbar.allow-buttons pref.

  • Scrollbar appearance is now consistent between a regular web page and the Settings page. In older versions, the Settings page would use the system theme.

That's expected. We made the default non-system scrollbars in bug 1710324, and removed the system scrollbars code in bug 1749645. If the rest is working as expected I think the remaining few things are WONTFIX, but please reopen if that's not the case.

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX

Wait, what?! This doesn't work and can't possibly work because the code was removed. Fantastic! Congratulations, Firefox UI team, you did it again. Remove stuff that works and replace it with new stuff that nobody asked for. Then be proud about it and call it innovation or modern UI or whatever. And yet I'm not surprised. Sadly, this is the trend in the whole Linux desktop world these days.

As for bug 1749645, it's funny you mention "nobody has complained about the non-native scrollbars". Has it occurred to anyone that people might have complained if they had been asked or otherwise been given a chance to complain? Bug 1749645 was opened about a month ago, while bug 1726283 (this bug) had been opened for 5 months at that time. And yet nobody cared to reply until it was too late and the code had been already removed. By the way, I doubt anybody cared to get any feedback whatsoever from the user community before removing that code. I think no user in their right mind would have said "sure, I want Firefox to look different from all the other apps in my desktop environment".

I'm not going to reopen this bug because clearly it's not a bug. It was intentional. Keep up the great work. Keep giving the finger to your users. And one day you'll have a product that is great but has no users left.

(In reply to Radu Rendec from comment #5)
Hi, I'm just a user as well: Native widgets are not possible anymore for security reasons. If you knew the circumstances, you would very likely come to the same conclusion. The only thing that browsers can do is trying to mimic the style of native widgets. IMHO, the widget.non-native-theme.enabled pref should be removed to avoid confusion.

(In reply to Radu Rendec from comment #5)

As for bug 1749645, it's funny you mention "nobody has complained about the non-native scrollbars". Has it occurred to anyone that people might have complained if they had been asked or otherwise been given a chance to complain? Bug 1749645 was opened about a month ago, while bug 1726283 (this bug) had been opened for 5 months at that time. And yet nobody cared to reply until it was too late and the code had been already removed.

FWIW, as soon as it moved into the GTK component, which I watch, I replied. I can't watch everything that happens in bugzilla. Sorry, there was sort of a process failure here because this bug took too long to move to the right component, but anyways, I digress.

By the way, I doubt anybody cared to get any feedback whatsoever from the user community before removing that code. I think no user in their right mind would have said "sure, I want Firefox to look different from all the other apps in my desktop environment".

Enabling GTK scrollbars on content went away because:

  • As comment 6 mentions, we can't enable system-rendered scrollbars on content because we can't initialize GTK in all processes, because of performance, security, and memory reasons. See bug 1129492, etc. Feel free to ask for more references as for why we had to move to non-native rendering. Moving to non-native widget rendering was an over-all a big win both for performance and for consistency with other platforms.

  • GTK scrollbars don't allow us to support scrollbar-width or scrollbar-color CSS properties from the css-scrollbars spec.

We don't want to enable GTK scrollbars only on the parent process for consistency (it's silly that e.g. about:preferences would have different scrollbars from a regular website). At that point, the GTK scrollbars code was effectively unused. I've kept it on the tree for months, but it blocked some other work, so I cleaned it up.

I know you feel pretty strongly about this, and I'd be happy to review patches if you come up with a way to render GTK scrollbars in websites that doesn't involve starting up GTK. Might not be impossible! I'm doing some other scrollbar theming improvements like D138077 which might or might not be interesting to you.

But anyways, hopefully that explains a bit.

(In reply to Darkspirit from comment #6)

Hi, I'm just a user as well: Native widgets are not possible anymore for security reasons. If you knew the circumstances, you would very likely come to the same conclusion. The only thing that browsers can do is trying to mimic the style of native widgets.

That makes some sense, and at least you took the time to explain the reasons behind it, I appreciate that. I don't know the details, but I do know that browsers use sandboxed environments to protect the host system in case a malicious web page manages to bypass the built-in security features of the browser (which has happened many times in the past and will likely happen again in the future). As with all security features, there is a tradeoff between usability and safety. That being said, I don't see how native widgets are a security risk. If you can please point me to some existing bugs/discussions that explain it, I'm willing to take a look. At least it would make more sense to me but perhaps something can be done about it. The traditional approach in the UNIX world has been to open the resources that require higher privileges first, then drop privileges. But the native widget issue may be something else that has nothing to do with that.

IMHO, the widget.non-native-theme.enabled pref should be removed to avoid confusion.

Frustration aside, that was my first thought as well. But does it control only the scrollbar appearance or does it affect other UI features too? After all, it's called "non-native-theme", not "non-native-scrollbars".

(In reply to Emilio Cobos Álvarez (:emilio) from comment #7)

FWIW, as soon as it moved into the GTK component, which I watch, I replied. I can't watch everything that happens in bugzilla. Sorry, there was sort of a process failure here because this bug took too long to move to the right component, but anyways, I digress.

Fair enough. It would have probably helped if I had assigned it to the right component in the first place. So it's partly my mistake too.

Enabling GTK scrollbars on content went away because:

  • As comment 6 mentions, we can't enable system-rendered scrollbars on content because we can't initialize GTK in all processes, because of performance, security, and memory reasons. See bug 1129492, etc. Feel free to ask for more references as for why we had to move to non-native rendering. Moving to non-native widget rendering was an over-all a big win both for performance and for consistency with other platforms.

  • GTK scrollbars don't allow us to support scrollbar-width or scrollbar-color CSS properties from the css-scrollbars spec.

That's true. I would be nice though if users were given the choice. Personally, I don't care that much about CSS customization of the scrollbars pretty much for the same reasons why I prefer the native scrollbars (desktop environment consistency). But web designers (and not only) could strongly disagree and that's a fair point. And I do understand now the reasons why you did this.

We don't want to enable GTK scrollbars only on the parent process for consistency (it's silly that e.g. about:preferences would have different scrollbars from a regular website). At that point, the GTK scrollbars code was effectively unused. I've kept it on the tree for months, but it blocked some other work, so I cleaned it up.

I know you feel pretty strongly about this, and I'd be happy to review patches if you come up with a way to render GTK scrollbars in websites that doesn't involve starting up GTK. Might not be impossible! I'm doing some other scrollbar theming improvements like D138077 which might or might not be interesting to you.

I took a quick look at bug 1129492, which explains the security part. The performance/memory part is pretty much self-explanatory, mostly because GTK is going downhill in those regards (and not only). So, the security part essentially boils down to not having a direct connection to the X server in child processes, which in turn kills the native widget library's ability to render anything. The only solution that comes to mind is to bundle a trimmed-down/modified version of GTK with Firefox, that renders to whatever the page renderer renders to as opposed to the X server directly. That could also solve some of the performance/memory issues, since only a small fraction of the library would probably be needed. But I admit this is a huge undertaking and likely not justified for the sole purpose of native widgets.

But anyways, hopefully that explains a bit.

It makes a lot more sense now, and thanks for taking the time to explain it, I really appreciate that. I would love to come up with patches because I believe in open-source software and collaborative effort. But realistically, even though I've been a Linux programmer for more than 20 years, I've done mostly low-level stuff and I have exactly zero experience with the Firefox codebase (and desktop/UI code in general). It would probably take me forever to ramp up to a level where I can send a patch.

Oh, I forgot to mention in the previous comment. One other way of doing it would be to make the non-native widgets fully themable. (maybe they already are?) That would allow users to create a theme that imitates their native desktop theme. After all, it doesn't have to be the same code that renders the widgets (as the rest of the desktop environment), they just need to look the same. And that would work not only for GTK but also for all the other platforms where Firefox is supported.

And I realize it's a bit tricky because CSS has a lot of control over the widgets (for example the scrollbar color/width) and it could interfere/overlap with the theme.

We allow customizing non-native gtk scrollbar rendering via prefs (see all the widget.non-native-theme.* prefs, and the ui.themedScrollbar prefs). It's somewhat limited but maybe it's close enough?

(In reply to Emilio Cobos Álvarez (:emilio) from comment #11)

We allow customizing non-native gtk scrollbar rendering via prefs (see all the widget.non-native-theme.* prefs, and the ui.themedScrollbar prefs). It's somewhat limited but maybe it's close enough?

Thank you for the suggestions. You are right, it's limited but close enough. Definitely better than no customization at all. I was aware of the widget.non-native-theme.* prefs, and in fact it's what I've been using since the native scrollbars were removed. However, I can't seem to find the other prefs from nsXPLookAndFeel.cpp in the advanced prefs editor. Do they have to be somehow enabled or am I just looking for the wrong thing in the wrong place?

You need to manually create those using the add button. We use the lack of existence of the pref to mean "use the system value".

(In reply to Emilio Cobos Álvarez (:emilio) from comment #13)

You need to manually create those using the add button. We use the lack of existence of the pref to mean "use the system value".

That makes sense. Thank you! I tested and it works.

You need to log in before you can comment on or make changes to this bug.