Open Bug 1870955 (wayland-window-position) Opened 1 year ago Updated 4 months ago

[wayland] Window placement is not controllable (session restore / pip / popups are affected)

Categories

(Core :: Widget: Gtk, defect, P3)

Product:
Core
Component:
Widget: Gtk
Type:
defect

Tracking

()

People

(Reporter: glandium, Unassigned)

References

(Blocks 1 open bug)

Details

STR:

  • Open preferences. Under General - Startup, select "Open previous windows and tabs"
  • Open a new window, move it around.
  • Quit Firefox (Ctrl+Q)
  • Start Firefox again

Expected result:

  • Two windows placed where they were before Firefox was quit.

Actual result:

  • Two windows placed one close to the other.

This is a regression from the switch to Wayland. The expected result is what was happening in X11 (gnome shell, in case it's relevant).

Actually, you don't even need multiple windows. Reopening a single window doesn't place it back where it was either.

Yes, it's one of two major Wayland regression. Window placement and missing PIP 'always on top'.

Blocks: wayland

we should add this into the release notes. AFAIK, we don't have workaround for this one.

Flags: needinfo?(ryanvm)

I added this to the existing Wayland release note:

It is also a known issue that windows are not correctly placed when restoring a previous session on launch.

Flags: needinfo?(ryanvm)

Note this also impacts turning on/off the title bar (via https://support.mozilla.org/en-US/questions/1002559)

Duplicate of this bug: 1871773

If the apps cannot position themselves under wayland due to 'security', what's the general workaround?

Should we now use DEs to position the apps? Do they have the power to do so? If no, what are we (the users), going to do?
PiP also doesn't work, even with workaround someone posted for KDE - it works when FF is opened then it doesn't.

This is a major, yet another, regression in usability under Wayland (as well as not having a color profile). Why did FF go W native?

(In reply to ivan.planinar from comment #7)

This is a major, yet another, regression in usability under Wayland (as well as not having a color profile). Why did FF go W native?

Mainly because it solves a lot of X11 issues. It's still a trade-off and there are still regressions for some use-cases - but the general consensus of developers is that advantages by now out-weight the disadvantages.

If the apps cannot position themselves under wayland due to 'security', what's the general workaround?

Should we now use DEs to position the apps? Do they have the power to do so? If no, what are we (the users), going to do?
PiP also doesn't work, even with workaround someone posted for KDE - it works when FF is opened then it doesn't.

If window positioning is very important to you, the short term workaround is to just disable native Wayland again and stick to Xwayland (MOZ_ENABLE_WAYLAND=0).

The medium term solution will likely be the session restore protocol, allowing to request previous window positions from the compositor. But that's not final yet (there is active work on it).

(In reply to Robert Mader [:rmader] from comment #8)

(In reply to ivan.planinar from comment #7)

This is a major, yet another, regression in usability under Wayland (as well as not having a color profile). Why did FF go W native?

Mainly because it solves a lot of X11 issues. It's still a trade-off and there are still regressions for some use-cases - but the general consensus of developers is that advantages by now out-weight the disadvantages.

If the apps cannot position themselves under wayland due to 'security', what's the general workaround?

Should we now use DEs to position the apps? Do they have the power to do so? If no, what are we (the users), going to do?
PiP also doesn't work, even with workaround someone posted for KDE - it works when FF is opened then it doesn't.

If window positioning is very important to you, the short term workaround is to just disable native Wayland again and stick to Xwayland (MOZ_ENABLE_WAYLAND=0).

The medium term solution will likely be the session restore protocol, allowing to request previous window positions from the compositor. But that's not final yet (there is active work on it).

Thank you, my understanding now is a bit better and solutions are good.

I've also tried with Window Rules in KDE, but as I noted above, they only work when FF is opened for the first time. Both for Window Position and PIP (using the workaround posted in What's new post). I'm not sure what changes during FF use and why Window Rules do not apply afterwards. But I wasn't alone in this (see https://www.reddit.com/r/kde/comments/osjt3p/comment/kej67kr/?context=3).

If we managed Window Rules to work, they could be a nice workaround for both of these Wayland issues.

Wait, if wayland doesn't allow positioning, how does Xwayland do it?

(In reply to Mike Hommey [:glandium] [OOO Dec 30-Jan 8] from comment #10)

Wait, if wayland doesn't allow positioning, how does Xwayland do it?

It doesn't generally do it, but the fact that in case of Gnome/KDE the X11 window manager is the same thing as the Wayland compositor means that it can do it. You could think about this as "privileged" Xwayland for better compatibility.

This is different on e.g. ChromeOS where the Wayland compositor does not have any X11 support and Xwayland is a normal, non-privileged client (and part of the container/wm that Linux apps ship in). Here Xwayland has the same limitations as any other Wayland client and thus doesn't support positioning.

I'd expect XDG desktops to move into that direction as well over time, moving Xwayland out of the "system" layer and potentially making it part of Flatpak/Snap runtimes. But that's likely still a few years out.

See Also: → 1872949
Alias: wayland-window-position
Summary: Window placement is not restored with wayland → Window placement is not controllable with wayland (session restore / pip / popups are affected)

(Rejiggering a bit to cover all the similar issues)

Duplicate of this bug: 1767414
Summary: Window placement is not controllable with wayland (session restore / pip / popups are affected) → [wayland] Window placement is not controllable (session restore / pip / popups are affected)
Duplicate of this bug: 1872949

(In reply to ivan.planinar from comment #9)

I've also tried with Window Rules in KDE, but as I noted above, they only work when FF is opened for the first time. Both for Window Position and PIP (using the workaround posted in What's new post). I'm not sure what changes during FF use and why Window Rules do not apply afterwards. But I wasn't alone in this (see https://www.reddit.com/r/kde/comments/osjt3p/comment/kej67kr/?context=3).

If we managed Window Rules to work, they could be a nice workaround for both of these Wayland issues.

Yes, that was me on that post you linked. And I agree, window rules would nicely work around the issue.
This KDE specific issue is being tracked here: https://bugzilla.mozilla.org/show_bug.cgi?id=1874766

(In reply to nf.pereira from comment #15)

Yes, that was me on that post you linked. And I agree, window rules would nicely work around the issue.
This KDE specific issue is being tracked here: https://bugzilla.mozilla.org/show_bug.cgi?id=1874766

For some reason KDE Window rules always work now for me.
I don't know if KDE fixed some bugs in the mean time, but I didn't change anything except normal updates of the Arch Linux.

So now whenever I login, Firefox automatically fires to my right monitor. The downside is this Window Rule is "forced", so wherever I want to move FF to another monitor, it's a bit tricky, as KDE wants to position it back to the right.

Still, I think this is the best workaround we have until KDE makes global placement settings built-in for Wayland. It's in the works for Plasma 6.

(In reply to ivan.planinar from comment #16)

The downside is this Window Rule is "forced", so wherever I want to move FF to another monitor, it's a bit tricky, as KDE wants to position it back to the right.

Forced rules always work. That was never an issue. The problem is the "Apply Initially" rules stop working after the 1st time you open the PiP.
We would just use the "Forced" rules, but that doesn't allow us to move the window around.

Try with the "Apply Initially" rules and you'll see they will probably be ignored.

Desktop QA has been highlighting this defect as a known issue for several release cycles now, following regression testing. Martin, it would really help us if you set a priority on this bug — it will give us clarity on whether this issue is still worth mentioning in future test reports.

Flags: needinfo?(stransky)

This is basically working as intended (somewhat unfortunately for PiP at least).

Severity: -- → S3
Flags: needinfo?(stransky)
Priority: -- → P3

Yeah, the proposed solution for this, the session restore protocol, unfortunately still doesn't exist, however there's active work on it: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18

Duplicate of this bug: 1910979

My bug, 1910979, was closed, thinking it was a duplicate of this (1870955) bug.

Does this bug address restarting an application with multiple windows (e.g., Firefox), and having them re-appear on their original desktop/workspace? If not, then this bug is not a duplicate of 1910979.

(In reply to Steve Kelem from comment #22)

My bug, 1910979, was closed, thinking it was a duplicate of this (1870955) bug.

Does this bug address restarting an application with multiple windows (e.g., Firefox), and having them re-appear on their original desktop/workspace? If not, then this bug is not a duplicate of 1910979.

Look at https://bugzilla.mozilla.org/show_bug.cgi?id=1870955#c20 for details about recent work.

The impact of this bug is increased when PiP Auto-trigger feature is enabled since the PiP windows always pop in the main view area.

You need to log in before you can comment on or make changes to this bug.