Open Bug 1155739 Opened 5 years ago Updated 7 months ago

nsIScreen or nsIScreenManager needs a way to expose virtual workspace extents

Categories

(Core :: Widget, defect, P3)

defect

Tracking

()

Tracking Status
firefox40 --- affected

People

(Reporter: ted, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: tpi:+)

Attachments

(1 file, 1 obsolete file)

Under Compiz, workspaces are implemented by having "viewports" into a large "desktop", but having a root window with the size of your monitor. On my system with a single 1920x1200 monitor and 2x2 workspaces I have:
$ xprop -root -notype _NET_DESKTOP_GEOMETRY
_NET_DESKTOP_GEOMETRY = 3840, 2400

$ xwininfo -root | grep geometry
  -geometry 1920x1200+0+0

See bug 1155668 comment 0 for more gory details.

Session restore currently won't restore windows outside of the screen area because it has no way of knowing this information:
https://hg.mozilla.org/mozilla-central/annotate/51e3cb11a258/browser/components/sessionstore/SessionStore.jsm#l2829

We'll need to add some sort of API to nsIScreen or nsIScreenManager so that session restore can ask "will a window at this position be visible"?

Alternately, we could change the GTK widget's screenmanager's ScreenForRect to do this calculation and have session restore trust the widget backend's judgement.
Tim, Steven: do either of you have an opinion on the right approach here?
Tried to dig into this months ago but couldn't find any good OS/WM-level APIs back then. Glad you found something!

As you already said, some API to query whether a window at a given position would be visible sounds nice. OTOH we could also pass it coordinates that then would be corrected if a previously available second monitor disappeared. We could also have a special version of window.moveTo() that adjusts given coordinates whenever some part of the window would be off-screen.
Attached file MozReview Request: bz://1155739/ted (obsolete) —
/r/7447 - bug 1155739 - add nsIScreen.WindowWouldBeAccessibleDisplayPix, a base implementation in nsBaseScreen, and a real implementation in nsScreenGtk. r=roc

Pull down this commit:

hg pull -r 35dc636648c588968fcc4a05b0146ec2a98c1e16 https://reviewboard-hg.mozilla.org/gecko/
Attachment #8596120 - Flags: review?(roc)
I implemented nsIScreen.WindowWouldBeAccessibleDisplayPix, which is very verbose but works. I'll push the patches to use this API in session restore to the bug this is blocking. Since mozreview didn't display my full commit message anywhere I'll reproduce it here:

The Compiz window manager (the default in Ubuntu) implements workspaces by
having viewports into a large virtual desktop, as in:
http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#largedesks

In this situation the root window's size is smaller than the desktop size,
and when you switch workspaces Compiz moves all your windows relative to
the root window and sets the _NET_DESKTOP_VIEWPORT property on the root
window to indicate the current viewport's offset into the desktop. This
means that window coordinates outside of the current screen rect can be
valid. I'd like session restore to be able to restore windows to the right
workspace, but I don't want to expose too much detail to the JS code so
I simplified it down to the WindowWouldBeAccessibleDisplayPix method, so
that session restore can simply query the widget backend as to whether
a window restored at a certain position would be accessible by the user.

Also, while I was grovelling around in nsScreenGtk I took the liberty of factoring out some code into a GetLongXProp function since I also needed to get an X property like that.

This could stand some unit tests, but I'm not sure we have anything like that at the moment, so I haven't got around to it yet. I think I could write some GTests to cover it, but I've already spent way too much time working on this.
Assignee: nobody → ted
Attachment #8596120 - Attachment is obsolete: true
Attachment #8620085 - Flags: review+
ted, can this work land?
Priority: -- → P3
Whiteboard: tpi:+
Whiteboard: tpi:+ → tpi:?
Yes, although I don't know if it still builds. I got hung up on the rest of bug 1155668 and never landed this.
Whiteboard: tpi:? → tpi:+
Assignee: ted → nobody
You need to log in before you can comment on or make changes to this bug.