In Xorg sessions, gnome-shell places windows on second screen when started from primary screen

Please remove/disable these extensions:

  '<email address hidden>',
  '<email address hidden>'

Then log out and in again to verify the bug still occurs without extensions.

As a workaround/fix you might want to try:

  gsettings set org.gnome.mutter center-new-windows true

I think this is probably occurring because the primary display is occupied by a window already. So any more new windows go to the next display that has empty space. If that's true then this is not a bug. And hopefully #3 is good enough.

Removing the extensions has the same effect.

Block Caribou 36 is necessary as the Point of Sale system (Open source) already has all the buttons and keyboard that are necessary for the use of the Point of Sale system. Yet it contains text entry fields which pop up the on-screen keyboard. There are more touchscreen applications that tablets, such as Kiosks and Point of Sale systems.

"gsettings set org.gnome.mutter center-new-windows true" is an easter-egg joke, it puts the windows halfway between the two screens, then stacks them on top of each other.

"I think this is probably occurring because the primary display is occupied by a window already. So any more new windows go to the next display that has empty space. If that's true then this is not a bug. And hopefully #3 is good enough."

This is a serious bug as the screens are opposing one another. There are two different people with two different information goals looking at each screen.
Both screens are occupied by full screen windows. One is the point of sale interface for the cashier and the other is the customer display screen showing the products the customer is purchasing.

The expected behavior is to put the window on the same monitor to where the button to open the new window has been pressed.

I'll see if I can muster up some screenshots to make it more visual as to what is going on.

Here is a photo so it's easier to understand what the issue is.

Thanks for have a new look at this

Oh and I forgot to mention this is with the option

Center New Windows turned ON in Gnome Tweak Tool
Which should theoretically do the same as the DCONF edit line, right?

Here is a photo so you can see that the Center New Window option does nothing. At least it stopped doing the Easter Egg of putting things halfway between two monitors that's a plus. :D

Here is an extra treat so you can see why block Caribou is very necessary and the gnome onscreen keyboard implementation makes the system completely unusable.

Some more fun, the onscreen keyboard follows the misplaced dialog box to the non-touchable monitor.

And here is proof that there are no extensions enabled

So you can see what the system looks like when installed

And the cashier side

And before anyone starts anything about freeloading.

I donate several thousand euros per year and a lot of my time to open source projects.

So, let's not go there.

Once again thank you.

I hope that it's much clearer now what is not working as expected in Ubuntu 20.04's iteration of Gnome Desktop.

I fear the answer here might be for you to avoid using gnome-shell and use a more constrained window manager to get the behaviour you want. But in case I'm wrong, please report the issue to the developers at:

  https://gitlab.gnome.org/GNOME/gnome-shell/issues

They might have some more ideas.

@Daniel van Vugt

Thanks for your understanding and advice.

Do you have any recommendations for an alternative window manager that is:
- Officially Supported by Canonical under the support contract
- Touchscreen Friendly
- Secure
- Has a sidebar on the left (the product I sell is designed around the Unity design)

Gnome is supposed to be the de-facto standard Linux desktop for most distributions. I still don't understand why all these regression bugs are entering Gnome, and the Gnome developers are so hostile to listening to the users and use cases of their desktop. See the gitlab board you pointed me to where the dev, on the subject of the on screen keyboard, just says, nope, I designed it this way, not listening to reason of more than 30 people and then locks the ticket.

Even you said "If that's true then this is not a bug." in regards to window placement.
Which is just mind boggling, of course it's a bug when the window manager clearly prevents the end user from using the system.

There also needs to be an easier way to report things upstream. At the moment everything has to be typed over into a new ticket from Launchpad to Github. Can't there just be some kind of export ticket to GitHub markup?

Thanks again for any recommendations on Canonical supported Window Managers.

Wish me luck, fingers crossed. I'm going to create the issue on Gnome's bug tracker now.

This is interesting. When running gnome-shell in Wayland the window placement seems to be correct. I've been testing it a bit.

Unfortunately Wayland doesn't allow for remote desktop access so I can't help my customers when something goes wrong.

Reported this Upstream under

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3011

> This is interesting. When running gnome-shell in Wayland the window placement seems to be correct. I've been testing it a bit.

I think that's what I was aiming for with:

  gsettings set org.gnome.mutter center-new-windows true

It likely works better in Wayland because that treats each monitor separately. Whereas Xorg likes to render all monitors as one, so the middle might be the border between the monitors.

> Unfortunately Wayland doesn't allow for remote desktop access so I can't help my customers when something goes wrong.

Please subscribe to bug 1696885 about that. It is blocked by bug 1802533.

> https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3011

Excellent, thanks.

> Do you have any recommendations for an alternative window manager

Canonical doesn't support anything other than Gnome Shell now. Though as you have found even that "support" has its limitations.

I suggest any software that wants a window A to reliably appear over window B should make sure window A is a dialog parented by B, or that A is a modal dialog parented by B. So if you can get that small change made to the POS software then it should work correctly with most window managers including gnome-shell.

Thank you for your further input Daniel.

The issue is that the stable version of ChromisPOS that I'm using the source code was destroyed by a commit error.

I'm working together with the developer providing resources to get the unstable version production ready but that is taking more time than I can afford to wait as gnome-shell's and Ubuntu's development is outpacing what the single developer for ChromisPOS can take on.

I'll certainly subscribe to those bugs on remote support. I'll let Zoho also know about these two remote support bugs as they are also working on an internal fix to build into their Zoho Assist SAAS solution, maybe they can assist there too.

> I suggest any software that wants a window A to reliably appear over window B ...

I'd prefer to have no dialog boxes at all popping up and have Window A modify itself. Then there is no reliance on the Window Manager at all. :D

Thanks again for thinking along on this issue.

Also I'm happy to use a workaround. I'm just a bit disappointed that devilspie no longer works.

As recommended by the Gnome-shell developers a bug upstream with Mutter is opened.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1356

Status changed to 'Confirmed' because the bug affects multiple users.

Someone wrote, not to me: "Then log out and in again to verify the bug still occurs without extensions.".

However my ubuntu 20.10 is in default release state, I added *no* extension to it (I disbled a few kbd shortcuts, added two kbd shortcuts, so it is basically in release state).

And I have the same disturbing setting, that

        DVI-0 connected primary 2560x1440+0+0 (in the reality this is my main monitor)

        DVI-1 connected 1680x1050+2560+504 (in the reality this is located as secondary)

and almost everithing arrives to DVI-1, regardless how I started, from wich termial,

Extremly disturbing, since I do not find any possibility to tell a program, to wich monitor to arrive.

In addition to this, the terminal and the firefox arrives maximalised, and the do not know their suggested default size what is larger, thatn the size of the wrong target, ---

--- since I have 2 monitors, I have to adjust all the window sizes by hand, as if it was a Windows.

Since 1995, all my programs are started with suggested locations and sizes, what does not work any longer ...

OK, one thing works, because the main monitor is on the left side: if I tell

        gnome-terminal --geometry=+0+0

but the

        gnome-terminal --geometry=-0+0

it will give a maximalised trash on the wrong monitor, and forgets the default nom-maximalised size as well.

In addition to this, EACH maximalization and non-maximalisation cycle SHRINKS the size of the gnome-erminal by one row and one column: 80 ... 79 ... 78 ...

This is an other bug, but I mention here because it might happen the same problem: the window size and location subsystem has serious problems ...

The problem is still there.

I'm having a very similar issue. With 21.10

I noticed that the issue goes away, when I change the scale to 100% (instead of 200%) on the secondary screen.

Main Screen (USB-C): 3440x1440, 100%
Secondary Screen (Built-In): 3840x2160: 200%

I'm having the issue with or without extensions.

tags: added: impish

I'm having the similar issue on my 20.04 lts desktop. I'm connecting my second Screen (Samsung Syncmaster SBS 23b300) via standard vga cable.

Whether my primary laptop screen empty or not, When I open control panel, it opens at the second screen regardless it opened or not.(I don't use second screen too much).

As a temporary fix, I am using Super+Shift+Left/Right/Up/Down (It depends on your secondary primary screen orientation. In my case, my laptop screen resides on left and secondary monitor resides on right.) keys to move the control panel to the main display.