Problem description: In a GNOME Wayland environment, the Brave browser (and other Chromium-based browsers) uses its own client-side decorations (CSDs) by default, which do not respect or visually adapt to the native dark theme or accent colors of the GNOME desktop. The result is a title bar that does not visually contrast with the rest of the system environment, as clearly shown in the provided image: the title bar remains blue in a dark user interface. Clarification of specific points: The browserâs internal option fails: The âUse system title bar and bordersâ option in chrome://settings/appearance does not resolve the issue. Even after enabling it and restarting the browser, it still displays its own CSD or a title bar that does not visually integrate. The problem is unique to Wayland: This rendering and adaptation issue does not exist when using a GNOME session with the traditional X11 (Xorg) window manager. In X11, the title bar adapts correctly to the system theme. The Wayland project has indicated that there are no issues with the Wayland windowing system.
Reproduction Steps
Test the reproduction with a clean browser profile to isolate the error from the existing user configuration.
Start a GNOME session using the Wayland protocol.
Enable the system dark theme in the GNOME appearance settings. Note that the issue also exists with the default theme.
Open the Brave/Chromium browser (Chromium-based).
Go to the browserâs profile management settings (e.g., chrome://settings/people).
Create and switch to a new, clean user profile.
Observe the title bar of the popup window in the user selection.
Reference Material: As shown in the reference image, the blue title bar doesnât match the systemâs appearance. This issue occurs in distributions that use GNOME and Wayland, such as Ubuntu, Arch, Manjaro, Debian, and Fedora. You can reproduce the problem by following these steps. This issue is present in all Chromium-based browsers, such as Brave and Google Chrome.
Reference material: as we can see in the following images the problem does not exist when we are in Gnome with x11 (xorg) the steps to reproduce the problem can be performed but on this occasion with a Gnome session with x11, you will see that the problem does not occur.
At first, I thought this problem was just a problem with my system or that I had made a change I shouldnât have, but this also happened on clean installations I performed on the aforementioned distributions.
Consider the problem or not, since you can also simply ignore it and go on with your lives.
I am aware of all that, but it is not a problem with my system itself. This problem persists in most of the distributions I have tested with clean installations of Ubuntu, Arch Linux, Manjaro, and Fedora. They all have one thing in common: Gnome and Wayland, from Gnome 48 to Gnome 49 with the Wayland window system. I reported this issue to Wayland in their Git lab, where, as I mentioned before, I ruled out it being a Wayland issue. I also contacted the Chromium team, who confirmed the issue and are working on a solution, if there is one, I believe. At the moment, I donât know what the main problem is, and I understand that Gnome is a volunteer-based project and, as such, the community and people in general will always try to help notify these volunteers of any problems or bugs that may be occurring, regardless of whether the problem is in the Gnome desktop environment. Itâs always good to rule out or confirm whether the problem is in the desktop environment or not.
I assume the screenshots are also generated by AI, since as a viewer you suggest that the information is fabricated or created by AI. I guess I do this to generate speculation or to make the Gnome desktop environment look bad, and I understand that some people donât have the intelligence to understand a simple informative text for the sole purpose of investigating whether or not the problem lies with Gnome. This problem has three factors: Wayland, which ruled out that the problem was theirs; Gnome and Chromium, which are already working on a possible solution. I guess the Chromium team will be in charge of communicating with the respective team related to this problem.
I regret that this report is being published today, as it should have been published two days ago, but I believe it is a problem to be a responsible citizen who tries to help the volunteer community by making their work easier. I think that, in these times, actions like this are not well received and are simply considered offensive. And, as I said, perhaps it was a mistake on my part not to know that, after creating an account on https://discourse.gnome.org/, you have to wait, I donât know, maybe five hours or a day to be able to write freely without being detected as a spammer. I could be a spammer; I donât know how everyone classifies it at the end of the day. Maybe Iâm just a troublemaker or simply a person with bad intentions.
It might be true that Iâm not the smartest person on this planet, or this forum, or even in this discussion.
Doesnât change the fact that you still havenât really described what the actual issue is.
I mean, screenshots can be great and all. But what for one person is obvious isnât necessarily for another.
So it helps to be clear about what is considered the issue, instead of expecting guesswork by other persons.
And, well, what youâve wrote isnât clear. Its just âThere is a difference, Wayland says itâs not their issue and Chromium hasnât said anything yetâ. Which isnât really clear and leaves a lot open to interpretation.
And about the AI:
Since your text hasnât much of detailed information about the actual issue you have, but a lot of text that sounds âprofessionalâ, but doesnât add anything, this just opens up the question if this was just âenhancedâ by an AI.
Being short, but precise is often better.
I didnât question that the screenshots were genuine. I also dont want to rule out you meant well. I just canât read out of your original comment what the actual issue you have is, because it has a lot of text, but very few details on what actually troubles you.
I am a package holder of a Chromium-based browser in the Arch User Repository. Additionally, both my work and personal systems run on GNOME, and I havenât encountered any issues with Chromium-based browsers.
Again, I really canât see what the problem is?
Care to explain?
Also, your screenshots that are apparently supposed to show the problem are from 2 different GNOME versions and 2 vastly apart kernel versions.
Serious question: did you asked AI to write this for you? Thatâs way too much text for the âproblemâ you have. Iâm gonna go ahead and assume (because you didnât really said what the issue was) is that the window pop-up have different decorations. Thatâs on Chromium, because this is how their CSD (Client-Side Decoration, meaning app decorates itself) looks like on wayland. Wayland is CSD-only, and so GNOME doesnât implement SSDs (Server-Side Decorations, compositor decorates apps).
Also, I recommend you to use a better browser than Brave.
To put it with other words: Apps are in charge of drawing their window decorations; it is no longer up to the compositor. The window decoration you are seeing in Chromium-based browsers is not something that GNOME has (at least I never heard that GNOME has this style to be used by apps). Even if GNOME has this window style in the system to be used by apps, apps certainly have to specify which style to use.
This could be a bad implementation of the Wayland protocol from GNOME, but is there even a protocol that is specifying window decorations?
I meant if, in the protocol, there is something that is responsible for loading the same CSDs (or window âconfigâ) of a specific window to a new one. If there is, then we can imagine that there is something that mutter did not correctly implemented.
Iâm not sure Iâm able to read some protocols of Wayland, but the easier way for someone that donât know is to test if it is reproducible in another Wayland-enabled desktop environment.
So @yass, I have seen you have updated your original post.
Compared to when I first commented, your post is now much better. Now its easier to understand the issue at hand. So thanks for updating this.
That being said, I have to agree with what others have said:
Under GNOME Wayland, all window decorations are responsibility of the application. That Chromiums titlebar does not follow GTKâs design is therefore an decision by Chromium itself.
Wayland canât exactly control windows (more precisely, window decorations) in GNOME; that would be the responsibility of the compositor, which is Mutter.
Mutter decides how things look and where they go. Clients donât get to paint borders or titlebars unless they use a specific protocol.
Protocols such as
Client-Side Decorations (CSD).
GTK draws the whole top bar itself inside the app window. Wayland supports this via the xdg-decoration protocol.
Server-Side Decorations (SSD)
In this case, Mutter draws the titlebar, buttons, shadows, rounded cornersâeverything. Apps just draw their contents.
Because Mutter is in charge, here, titlebars and button styling come from GNOMEâs theme (libadwaita / GTK theme). Furthermore, shadows and corners are handled directly by the Mutterâs compositor code.
So whatever is happening to Brave is on their own side.
P.S. Brave is one of the worst browsers out there to use (completely personal opinion)
No, Mutter doesnât support SSDs. Xdg-decorations protocol is for implementing SSD support. Things like titlebar, shadows, corners etc are fully controlled by clients (apps).
And just in case, Chromium isnât doing anything wrong. Wayland requires them to implement CSD and so they did. Itâs just that those decorations look like crapâŚ
