Closed Bug 1411425 (linux-nnt) Opened 7 years ago Closed 3 years ago

[meta] [gtk] [fission] Remove full-native theming for content (Linux NNT)

Categories

(Core :: Widget: Gtk, task, P2)

Product:
Core
Component:
Widget: Gtk
Version:
56 Branch
Platform:
All
Linux
Type:
task

Tracking

()

Status:
RESOLVED FIXED
Project Flags:
Fission Milestone M7a

People

(Reporter: Paul.Hancock.17041993, Unassigned)

References

(Blocks 2 open bugs)

Details

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

+++ 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)
Blocks: uplift_tor_fingerprinting
(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.
(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.
_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)
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.
(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?
(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?
(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.
Summary: Remove full-native theming → Remove full-native theming (for content)
(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?)
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]
(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.
(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...
(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.
(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...
Please *keep* native theming. Native theming is important for UI consistency across the desktop.
(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...
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.
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.)
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.)
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.
(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...
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.
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.
> 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.
> 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.
> 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.
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.
Blocks: win32k-lockdown
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'.
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.
(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.
(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.
(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.
> 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.
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
Closed: 6 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → REOPENED
Depends on: 1381938
Resolution: DUPLICATE → ---
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
Whiteboard: [fingerprinting][overhead:noted] → [fingerprinting][overhead:noted][fp-triaged]
Summary: Remove full-native theming (for content) → Remove full-native theming (for content)(fingerprinting)
Blocks: 70315

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

we'll file

No longer depends on: 1381938
Keywords: meta
Blocks: remove-native-theming
No longer blocks: uplift_tor_fingerprinting
Summary: Remove full-native theming (for content)(fingerprinting) → [gtk] Remove full-native theming for content
Depends on: 1381938
No longer depends on: 1381938
Summary: [gtk] Remove full-native theming for content → [meta] [gtk] Remove full-native theming for content

Why isn't "widget.content.gtk-theme-override" set to "Adwaita:light" by default? this would fix this issue.

Setting the override is not enough. I have that set and the Find (Ctrl-F) text entry is white on white for example.

Idk why this is such a big issue. There is the GTK_THEME= variable and the various AMO themes.

So if you use a dark theme, start FF with it's bright variant via the variable and pick a dark theme from AMO you like.

(In reply to x3 from comment #44)

Idk why this is such a big issue. There is the GTK_THEME= variable and the various AMO themes.

So if you use a dark theme, start FF with it's bright variant via the variable and pick a dark theme from AMO you like.

It is not just that we want to use a dark theme, we also want Firefox to match our system’s dark theme. The Dark theme bundled with Firefox or any theme on AMO just will not do – they might be dark but the shades of grey are slightly off, which is pretty irksome. The AMO theme will either be slightly darker than the system theme and then, when you switch to a different window, you will be blinded, or it will be slightly lighter and you will be blinded when switching back to Firefox. Only the Default theme supports basing its colours on operating system’s theme.

(In reply to Jan Tojnar from comment #45)

(In reply to x3 from comment #44)

I haven't looked into it but I assume anyone can edit and submit themes to AMO
so just edit one replacing some of it's colors with the ones used in your GTK theme
then Firefox's "header" will match it but the page will be "normal" with GTK_THEME=Arc (for e.g.)

(In reply to john from comment #46)

I haven't looked into it but I assume anyone can edit and submit themes to AMO
so just edit one replacing some of it's colors with the ones used in your GTK theme
then Firefox's "header" will match it but the page will be "normal" with GTK_THEME=Arc (for e.g.)

Unless there is an API themes can use to query the system GTK theme for colours of various elements, it would require to create a Firefox theme for every different GTK theme. And after that the themes would have to be forever kept in sync:

Adwaita changes colour tone? Update the Firefox theme. Wait, Bob is using Ubuntu LTS where the Adwaita change did not yet arrive. Now he must roll back to an older version of Firefox theme. And not forget to update the theme manually on next Ubuntu upgrade.

This is simply too much effort for something so natural as a consistent system look. I can still remember the pain when every multimedia application decided to draw its own GUI and you had to crawl their theme portals, trying to find a single theme up to date and matching your system look. Thankfully those days are mostly over for regular apps.

(In reply to Jan Tojnar from comment #47)
i doubt it is much effort to change a few color hexes and gtk themes (that aren't abandoned) aren't really that many

(In reply to john from comment #48)

(In reply to Jan Tojnar from comment #47)
i doubt it is much effort to change a few color hexes and gtk themes (that aren't abandoned) aren't really that many

It's not much effort for web designers to actually specify both background and foreground colors for elements like buttons and other input elements, but in reality they just don't do that.

Availability of workarounds is really not the point of this bug. The point of this bug is that out of the box Firefox doesn't work the way some users (and apparently, many web designers) expect it to.

(In reply to Rimas Kudelis from comment #49)

Availability of workarounds is really not the point of this bug. The point of this bug is that out of the box Firefox doesn't work the way some users (and apparently, many web designers) expect it to.

what way is that

(In reply to mike from comment #3)

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)

just use the GTK_THEME= variable
simple as

(In reply to Paul17041993 from comment #14)

(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

yep you've never seen the Qt open/save as window, you're thinking of kdialog

Component: Widget → Widget: Gtk

FWIW these days you can just use widget.disable-native-theme-for-content=true to disable the native theme.

That also doesn't fix the white text on white background I get in the Find (Ctrl-F) text entry.

Can you file a separate bug for that and needinfo me with your GTK setup / theme? That's not affected by that pref because it's Firefox UI (not content).

From a quick look, it seems that field is doing the right thing (it's setting the color to be -moz-FieldText, and the background to be -moz-Field, which are the right GTK background colors).

I'm happy to poke at it but that specific bit seems unrelated to this bug.

Sure, submitted as Bug 1634449. It was my mistake. I subscribed to this bug as well as 70315 and replied here instead of there.

Tracking Linux NNT as a Fission Nightly blocker. Removing native theming from the content process will help alleviate Fission's problems with X connection exhaustion (bug 1129492).

Alias: linux-nnt
Blocks: 1129492
Severity: normal → N/A
Type: enhancement → task
Fission Milestone: --- → M6b
Priority: P3 → P2
Summary: [meta] [gtk] Remove full-native theming for content → [meta] [gtk] Remove full-native theming for content (Linux NNT)

Tentatively assigning to heycam for 2020 H2.

Assignee: nobody → cam
Depends on: 1640195
Blocks: fission
Fission Milestone: M6b → M7
Summary: [meta] [gtk] Remove full-native theming for content (Linux NNT) → [meta] [gtk] [fission] Remove full-native theming for content (Linux NNT)
Depends on: 1658549
No longer depends on: 1658549
Depends on: 1669131
Depends on: 1669135
Depends on: 1669173
Depends on: 1669368
Depends on: 1670145
Depends on: 1670853
Depends on: 1670859
Depends on: 1671304
Depends on: 1672097
Depends on: 1672098
Blocks: 1673188
Regressions: 1674431
Depends on: 1676056
Depends on: 1676057
No longer depends on: 1672097
See Also: → 1672097

Tracking non-native theming bugs for Fission Beta milestone (M7).

Depends on: 1687853
No longer depends on: 1687853
Depends on: 1687866
OS: All → Linux
Depends on: 1689603
Assignee: cam → nobody
Depends on: 1691132

Linux bugs don't block our Fission Beta experiment (on Windows and macOS), so I am moving Linux Fission bugs from Fission milestone M7 to M7a.

Fission Milestone: M7 → M7a
No longer blocks: 1683819
Depends on: 1683819
Regressions: 1699930

I think with bug 1697053 we can call this fixed.

Status: REOPENED → RESOLVED
Closed: 6 years ago → 3 years ago
Resolution: --- → FIXED
Regressions: 1708285
You need to log in before you can comment on or make changes to this bug.