-
-
Notifications
You must be signed in to change notification settings - Fork 127
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New chromium window position is off #905
Comments
Thanks for reporting. Does this only happen with Chromium? (and does it happen every time?) I'm also on 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. |
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. |
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? |
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. |
Actually, your settings window looks strange/different/non-standard (small icons and heavily rounded corners)... is that custom styling or from an extension? |
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. |
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. |
Here's me creating chromium windows (lots of them) with the Gnome custom shortcut Screencast.from.2024-07-23.23-30-42.webmI have a very similar setup as you (EndeavourOS, 2560x1440 monitor, same gnome version and same PaperWM version). |
No problem. Screencast.from.2024-07-23.15-44-08.webm |
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). |
@tobias-haenel, I've removed the 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:
Logout / login (this is important) and then re-test. Also, can you paste your Cheers. |
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.webmI didn't change my user.css:
|
I also tried v46.13.0 and v46.12.0 the issue persists even with those earlier versions. |
Thanks for testing - I was checking that specifically - so there's definitely something up with the styles (and in particular the 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? |
The issue doesn't occur with Chromium 126.0.6478.182-1 only with 127.0.6533.72-1 |
oh... |
Okay, I looked - I'm running |
are you using Xorg or Wayland? |
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? |
actually, you're right https://archlinux.org/packages/extra/x86_64/chromium/ |
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. |
Where does paperwm store its configuration? I would like to try reset my config to default. |
dconf https://github.com/paperwm/PaperWM?tab=readme-ov-file#user-configuration--development Install
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.). |
also, I reverted that change (removing On the branch you're currently on - just do a |
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 |
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
|
Dang, with those flags my chromium doesn't even start up |
Nvidia user? (if so, running hybrid or discrete?) |
Nvidia Hybrid (GeForce RTX 4070 Max-Q / Mobile and Iris Xe Graphics) |
It seems to work without the flags. The first window is created slower than its overlay. But then chromium will use XWayland. |
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. |
Well, we're definitely narrowing it down for sure. Thanks for sticking around to try isolate this one. |
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. |
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). |
Got a reproducible case now at least. I'll play around a bit more with this one tomorrow. |
Nice, thanks for sticking around! |
Just putting some notes / resources here for reference: |
Under wayland (not xwayland), chromium throws the |
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 |
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). |
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. |
Anyway, I'll experiment with seeing if we can find some way to modify that surface geometry at Meta.Window level. |
The bug is different with the new chromium version 127.0.6533.88 Screencast.from.2024-08-03.12-49-31.webm |
But specifying a window size is still a valid workaround. |
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:
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:
The text was updated successfully, but these errors were encountered: