New chromium window position is off

[tobias-haenel]

Describe the bug
When I open chromium through a custom shortcut the new window position is somehow offset to the bottom right of the screen. I have a winprop for wmclass "*" with prefered width 50% After cycle through my different width presets, the window position is correct.

To Reproduce
Steps to reproduce the behavior:

1. Open chromium through a custom gnome shortcut (Super+w)

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots

System information:
Distribution: Arch Linux
GNOME Shell: 46.3.1
Display server: Wayland
PaperWM version: 46.13.5
Enabled extensions:

• appindicatorsupport@rgcjonas.gmail.com
• blur-my-shell@aunetx
• no-overview@fthx
• launch-new-instance@gnome-shell-extensions.gcampax.github.com
• user-theme@gnome-shell-extensions.gcampax.github.com
• paperwm@paperwm.github.com

[jtaala]

Thanks for reporting. Does this only happen with Chromium? (and does it happen every time?)

I'm also on 46.3.1 with an arch-based distro - will try to reproduce.

Can you please paste a screenshot of your border / margin settings so I try to reproduce your settings?, e.g. paste something like:

Any window size / restore extensions you use on Chromium?

Cheers.

[jtaala]

Haven't been able to reproduce with Chromium 1278.0.6533.57 as yet, but will try a few things there.

Most likely some corner case with border/margin size settings I'm guessing. Anyways, zap me those settings when you can we can attempt to reproduce/isolate.

[tobias-haenel]

I am using Chromium Version 127.0.6533.57 (Official Build) Arch Linux (64-bit).
No window size/restore extensions.

If I mouse click on the window it returns to its supposed size as well.

Thanks for your efforts!

[tobias-haenel]

I am getting this error even when I use your settings for border|margins|gaps. Sometimes this bug occurs only when I open a second/third chromium window through my short cut.

[jtaala]

I am getting this error even when I use your settings for border|margins|gaps. Sometimes this bug occurs only when I open a second/third chromium window through my short cut.

Hmm - must be something else impacting this then. Your extensions looks okay, but just to be sure, can you disable all extensions (except PaperWM), logout / login, and see if you can reproduce?

Long shot, but do you have any styling on the alt-tab popup? Reason being, is that the selected window border shares the styling class with the alt-tab element. Given that picture though, it doesn't seem like it's a styling issue (more a window placement issue).

Finally, what resolution / scaling are you running on your monitor?

[jtaala]

P.S. I also use a shortcut for my browser(s), and haven't been able to reproduce it yet with a custom shortcut with Chromium.

[jtaala]

Actually, your settings window looks strange/different/non-standard (small icons and heavily rounded corners)... is that custom styling or from an extension?

[tobias-haenel]

Screen resolution is 2560 x 1440. Scale is 100%. I am using the Orchis GTK4-Theme (https://github.com/vinceliuice/Orchis-theme) that results in a different look for the settings window. The bug occurs with all extensions disabled except for PaperWM and also if I use the standard GTK4 Theme.

[jtaala]

Hmm - haven't seen this and haven't been able to reproduce as yet. Let's see if anyone else has seen this ever.

@Lythenas @valpackett @Thesola10 - anyone seen this?

Any chance you can take a video / screen video capture? - maybe that would help in seeing how it offsets.

[jtaala]

Here's me creating chromium windows (lots of them) with the Gnome custom shortcut super+w. Let me know if I'm doing anything wrong / different from you in trying to reproduce.

Screencast.from.2024-07-23.23-30-42.webm

I have a very similar setup as you (EndeavourOS, 2560x1440 monitor, same gnome version and same PaperWM version).

[tobias-haenel]

No problem.

Screencast.from.2024-07-23.15-44-08.webm

[Lythenas]

I'm also not able to reproduce unfortunately. But I've seen something kind of similar back in Gnome 44 when adding some programs in the autostart. The offset was different (to the side instead of making the window smaller) and it was firefox and not chromium. Although I didn't try chomium. So I'm unsure if this is even related.

[jtaala]

I'm also not able to reproduce unfortunately. But I've seen something kind of similar back in Gnome 44 when adding some programs in the autostart. The offset was different (to the side instead of making the window smaller) and it was firefox and not chromium. Although I didn't try chomium. So I'm unsure if this is even related.

Thanks @Lythenas - that was the autostart issue (window starting before PaperWM does) - not sure if that's related (it could be though).

[jtaala]

@tobias-haenel, I've removed the tile-preview css class from paperwm-selection in this branch: https://github.com/paperwm/PaperWM/tree/debug-905-chromium-position-selection-offset.

Just want to rule the styling out here, given that when that issue occurrs, the selection border is very larger.

When you've got some time, can you checkout this branch and logout/login and test?

Uninstall current PaperWM extension (you won't lose your settings or anything), and then do a:

git clone https://github.com/paperwm/PaperWM.git
cd PaperWM
git checkout debug-905-chromium-position-selection-offset
./install.sh

Logout / login (this is important) and then re-test.

Also, can you paste your ~/.config/paperwm/user.css file here (if you've changed / edited PaperWM css styles)?

Cheers.

[tobias-haenel]

The change did not fix the issue and the background styling is missing (due to the title-preview missing css class?)

Screencast.from.2024-07-24.12-07-47.webm

I didn't change my user.css:

/*
Users may override the default PaperWM styles to suit their preferences.
Added custom styling in this `user.css` file.

`Disable` and then `enable` PaperWM extension to apply these styles 
(users do NOT need to logout / login).

DEFAULT STYLES ARE PROVIDED BELOW FOR REFERENCE:
/*

/*
.background-clear {
    background-color: rgba(0, 0, 0, 0);
}

.topbar-transparent-background {
    background-color: rgba(0, 0, 0, 0.35);
    box-shadow: none;
}

.space-workspace-indicator {
    padding: 0 10px 0 0;
    background-color: transparent;
    border-image: none;
    background-image: none;
    border: none;
}

.space-focus-mode-icon {
    icon-size: 16px;
    padding: 0 18px 0 18px;
    margin-left: 3px;
    background-color: transparent;
}

.focus-button-tooltip {
    background-color: rgba(0, 0, 0, 0.8);
    padding: 8px;
    border-radius: 8px;
    font-weight: 600;
}

.workspace-icon-button {
    -st-icon-style: symbolic;
    border: none;
    border-radius: 8px;
    padding: 8px;
}

.workspace-icon-button StIcon {
    icon-size: 16px;
}

.paperwm-selection {
    border-radius: 12px 12px 0px 0px;
}

.paperwm-minimap-selection {
    border-radius: 8px;
}

.paperwm-window-position-bar-backdrop {
    background-color: rgba(0, 0, 0, 0.35);
}

.paperwm-window-position-bar {
    border: 0;
    border-radius: 1px;
}

*/

[tobias-haenel]

I also tried v46.13.0 and v46.12.0 the issue persists even with those earlier versions.

[jtaala]

The change did not fix the issue and the background styling is missing (due to the title-preview missing css class?)

Thanks for testing - I was checking that specifically - so there's definitely something up with the styles (and in particular the tile-preview class, and maybe other standard gnome styling) on your setup. When I run this branch the selection is still there fine (and it should be). Nope! you're right (I was running my user.css styles to add border color).

I notice you are running user-theme@gnome-shell-extensions.gcampax.github.com extension - what user styles are you using?

In any case, this seems very to be as styling clash with some things you are running - which is specific to your setup/env. Haven't seen/heard of this before (even after all some years on PaperWM).

Are you able to create a clean / new user and just install PaperWM and retest?

[tobias-haenel]

The issue doesn't occur with Chromium 126.0.6478.182-1 only with 127.0.6533.72-1

[jtaala]

The issue doesn't occur with Chromium 126.0.6478.182-1 only with 127.0.6533.72-1

oh...

[jtaala]

Okay, I looked - I'm running 127.0.6533.57

[tobias-haenel]

are you using Xorg or Wayland?

[jtaala]

Wayland.

How did you install 127.0.6533.72-1, on Endeavour (which I though used arch repos), it looks like 127.0.6533.57-1 is the current version. Are you on Arch test repos?

[jtaala]

actually, you're right https://archlinux.org/packages/extra/x86_64/chromium/

[jtaala]

Thanks for testing - I was checking that specifically - so there's definitely something up with the styles (and in particular the tile-preview class, and maybe other standard gnome styling) on your setup. When I run this branch the selection is still there fine (and it should be).

And... scrap that! You're right (I was running my custom border stuff). Indeed that branch does hide the styling border...

Apologies for the confusion there.

[tobias-haenel]

Where does paperwm store its configuration? I would like to try reset my config to default.

[jtaala]

dconf

https://github.com/paperwm/PaperWM?tab=readme-ov-file#user-configuration--development

Install dconf-editor and then run

GSETTINGS_SCHEMA_DIR=::$HOME/.local/share/gnome-shell/extensions/paperwm@paperwm.github.com/schemas dconf-editor /org/gnome/shell/extensions/paperwm/ &>/dev/null

I doubt that will change / fix it though. If you create a new user account (then can delete it afterwards) and login with Gnome, then install PaperWM etc. - that would let us know (since you have a clean env and all clean paperwm settings/styles etc.).

[jtaala]

also, I reverted that change (removing tile-preview class) - it really only sets the colour anyway:

https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/main/data/theme/gnome-shell-sass/widgets/_misc.scss#L50

On the branch you're currently on - just do a git pull (which will get you back to release state).

[tobias-haenel]

I tried to create a new user and everything worked correctly. I am trying to figure out the difference between my user account and the test user

[jtaala]

I tried to create a new user and everything worked correctly. I am trying to figure out the difference between my user account and the test user

Gotcha. My money is still on styling or themes (but am just guessing from gut feel). In dconf-editor, you can reset-recursively which will reset all PaperWM settings to default (you'll def need to logout/login or disable/enable PaperWM after doing that):

[tobias-haenel]

The issue occurs even with a new user, no styling (gnome defaults) and only paperwm. I forgot to add the winprop wmclass "*" 50% width rule. The issue doesn't occur if I don't have that rule. I am using the following ~/config/chromium-flags.conf

--enable-features=TouchpadOverscrollHistoryNavigation
--ozone-platform=wayland

[jtaala]

nice find. So, I also have always had a default 50% rule:

I'll try your flags. Tell me, does it also occur if you don't have those flags (e.g. no chromium-flags.conf ?).

[jtaala]

Dang, with those flags my chromium doesn't even start up

[jtaala]

Nvidia user? (if so, running hybrid or discrete?)

[tobias-haenel]

Nvidia Hybrid (GeForce RTX 4070 Max-Q / Mobile and Iris Xe Graphics)

[tobias-haenel]

It seems to work without the flags. The first window is created slower than its overlay. But then chromium will use XWayland.

[jtaala]

ah.. nice laptop. Somewhat similar to mine. I'm running nvidia 555.58.02 drivers.

You on Nvidia drivers or nouveau?

Okay, well, definitely made some progress here. With the ozone setting my chromium doesn't even start.

[jtaala]

Well, we're definitely narrowing it down for sure. Thanks for sticking around to try isolate this one.

[tobias-haenel]

You could try --ozone-platform-hint=auto instead you can check with xeyes wheter an application is running under Wayland or XWayland. See https://wiki.archlinux.org/title/Chromium#Native_Wayland_support for details.

[jtaala]

huzzah! I can finally reproduce. Had to run in full discrete mode but then the ozone flag worked.

Yes, chromium seems to be resizing itself (weirdly) on startup (and after PaperWM has run it's tiling layout).

[jtaala]

Got a reproducible case now at least. I'll play around a bit more with this one tomorrow.

[tobias-haenel]

Nice, thanks for sticking around!

[jtaala]

Just putting some notes / resources here for reference:

• Invalid window geometry for xdg_surface alacritty/alacritty#7058
• startup_mode: Maximized stopped working recent GNOME Wayland alacritty/alacritty#6184
• Preferred width does not work with some applications #642

[jtaala]

Under wayland (not xwayland), chromium throws the Invalid window geometry for xdg_surface@38. Ignoring for now, but this will result in client termination in the future. warning.

[tobias-haenel]

This error messages seems to be thrown, when the initial window width or height is 0. https://gitlab.gnome.org/GNOME/mutter/-/blob/main/src/wayland/meta-wayland-xdg-shell.c#L1867
Adding --window-size="300,500" to .config/chromium-flags.conf is a workaround. The message dissappears and PaperWM doesn't have the offset issue. So the issue seems to occur for windows with an invalid initial size?

[jtaala]

Yes, unfortunately the issue occurs in mutter (which is not something we control) and before paperwm receives and can do much about that particular issue (unless of course we modify and compile our own version of mutter to do something like change those geometries? etc).

Definitely an upstream Chromium issue that looks like it was intro'd in the last few versions. That exception for mutter suggests that sometime in the future mutter will be terminating such misbehaved applications. Suggest submitting this issue upstream to chromium (can reference this issue here).

For us though, workarounds will likely be the best bet here (using xwayland, or modifying window-size property).

[jtaala]

That exception for mutter suggests that sometime in the future mutter will be terminating such misbehaved applications

Note that running as default (xwayland) the windows behave well (or as expected) and the window sizes are stable (that is, they don't change when paperwm receives them).

With ozone, they sometimes come in different and then change and act strangely once their actors show (and when PaperWM tries to control/modify chromium window sizes). I'm assuming due to a mismatch in surface geometries and meta.window frame.

[jtaala]

Anyway, I'll experiment with seeing if we can find some way to modify that surface geometry at Meta.Window level.

[tobias-haenel]

The bug is different with the new chromium version 127.0.6533.88

Screencast.from.2024-08-03.12-49-31.webm

[tobias-haenel]

But specifying a window size is still a valid workaround.