RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 734251 - Window manager, metacity, keeping windows on the visible portion of the screen
Summary: Window manager, metacity, keeping windows on the visible portion of the screen
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: metacity
Version: 6.1
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Owen Taylor
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks: 727267 782183
TreeView+ depends on / blocked
 
Reported: 2011-08-29 21:36 UTC by Scott Spurrier
Modified: 2018-11-28 21:39 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-07-15 21:47:40 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Scott Spurrier 2011-08-29 21:36:22 UTC
For dual-monitor configurations with screens of different resolutions, we'd like the windows manager to keep windows on the visible portions of the screens.

The windows manager can/will open new windows in the deadspace (non-visible) parts of the desktop if that is the only area available to it or if the application defaults to that location.
The only way to get the window back onto the visible area is to use the "move" item in the pop-up menu from the applications icon on the gnome panel, which impedes workflow if you're using a cintiq as a secondary display.

Comment 3 RHEL Program Management 2011-08-29 22:08:19 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

Comment 4 Owen Taylor 2011-09-26 17:33:40 UTC
I'm a little unsure what's going on here. Metacity definitely has code that constrains window placement to monitors - it won't spontaneously place windows into "dead space" just because it is otherwise unoccupied.

There may be some combination of application specifics that is causing problems here. Detailed specific reproduction instructions (even if I don't have access to the applications involved) would be useful in understanding this issue further.

I'll do some testing this week to see if I can figure out any circumstances in which windows would be placed into dead space.

Comment 6 Owen Taylor 2011-09-26 19:40:24 UTC
Testing with metacity-2.28.0-20.el6.x86_64 (latest RHEL-6 metacity), two monitors

 +-------------+ +-----------------------+
 |  800x600    | |      1280x1024        |
 |             | |                       |
 +-------------+ |                       |
                 |                       |
   dead space    |                       |
                 +-----------------------+

With a a terminal filling the left monitor and a maximized firefox filling the right monitor.

If I launch a new window without specifying a position:

 $ gnome-terminal --geometry 5x5

It starts on the monitor where the pointer is, and if the pointer is in the dead space, it starts on the right-hand monitor. (I'm testing with an old X server without the changes to pointer behavior.)

If a launch a new window specifying a position:

 # Geometry on the left monitor
 # Starts on the left monitor
 $ gnome-terminal --geometry 5x5+100+100

 # Geometry partly on the left monitor.
 # Starts on the left monitor, pushed into the visible screen
 $ gnome-terminal --geometry 5x5+100+550

 # Geometry in the dead space
 # Starts on the right monitor, with the specified y
 $ gnome-terminal --geometry 5x5+100+650

I see the same behaviors if I swap the two screens horizontally, and have the larger monitor on the left.

So, I was never able to reproduce a problem with a window being placed into dead space, even when the program explicitly requested that position.

Can we get Dreamworks to test if it matters what application is started? Does it happen with a small gnome-terminal window as described above? 

What is the value of the gconf key /apps/metacity/general/disable_workarounds ? Does it matter for the observed behavior? (I would expect not, but it does chnage the placement code a bit.)

Comment 9 RHEL Program Management 2012-07-10 06:28:14 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 10 RHEL Program Management 2012-07-11 00:00:24 UTC
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.


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