Ticket #573 (closed usability: fixed)

Opened 13 months ago

Last modified 13 months ago

Fullscreen mode leaves blank bar at the bottom of the secondary screen

Reported by: mrsvan@… Owned by: jeremyhu@…
Priority: Not Set Milestone: 2.7.2
Component: quartz-wm Version: dev (master)
Keywords: Cc: mrsvan@…, tgl@…

Description

When I toggle a window into fullscreen mode on the secondary display, a blank bar appears at the bottom of the screen.

This blank bar messes up the available screen space and I have to resort to scaling to remove the resulting scrollbars.

I have attach a screen copy of the secondary display.

This happens whether xQuartz is running in root fullscreen mode or not.

I'm running on OSX Lion:

System Version: Mac OS X 10.7.3 (11D50b) Kernel Version: Darwin 11.3.0

Attachments

Screen Shot 2012-04-27 at 12.12.39.png (89.2 KB) - added by mrsvan@… 13 months ago.
Screenshot of secondary display with fullscreen window showing blank bar at bottom.
Screen Shot 2012-04-27 at 20.37.09.png (103.2 KB) - added by mrsvan@… 13 months ago.
virt-manager VM window not in fullscreen mode

Change History

Changed 13 months ago by mrsvan@…

Screenshot of secondary display with fullscreen window showing blank bar at bottom.

comment:1 Changed 13 months ago by mrsvan@…

  • Cc mrsvan@… added

Cc Me!

comment:2 follow-up: ↓ 3 Changed 13 months ago by jeremyhu@…

  • Version dev (master) deleted
  • Milestone 2.7.3 deleted

You said that this happens when you go into fullscreen mode, but then you said that it happens in both fullscreen and not ... so I'm a bit confused about what it is that you are reporting. Can you please be more descriptive or possibly record a screen capture of the issue using QuickTime?

Also, what version of XQuartz are you using? Can you please try 2.7.2_rc1

comment:3 in reply to: ↑ 2 Changed 13 months ago by mrsvan@…

Hell Jeremy,

I was running 2.7.2_beta5, and now I'm running rc1. The issue is still there.

It seems I was not clear regarding the "fullscreen" issue.

The problem appears when xQuartz is running with the option Preferences | Output | Full-screen mode is checked, and also if it is unchecked. The "root" window does take over the whole screen on both displays in full-screen mode.

The problem appears when I use KVM's "virt-manager" with x-tunneling over an SSH connection. The virt-manager VM window also has a fullscreen option. When I click on this button, the virt-manager VM window leaves a bar at the bottom of the secondary display, but not when it is on the primary display.

This could be a virt-manager issue, but it only appeared after switching from Apple's standard X11 client to xQuartz...

So I guess it could be an xQuartz issue...

I am not aware of any other x-programs with a "fullscreen" mode that I could test.

comment:4 follow-up: ↓ 5 Changed 13 months ago by mrsvan@…

Hello !!

Changed 13 months ago by mrsvan@…

virt-manager VM window not in fullscreen mode

comment:5 in reply to: ↑ 4 Changed 13 months ago by jeremyhu@…

Replying to mrsvan@…:

Hello !!

Hi!!

I don't see the problem. Please take a screen capture video.

Does it occur if you have only one display attached?

comment:6 Changed 13 months ago by mrsvan@…

Dear Jeremy,

It seems that I did not reboot after installing the latest version of xQuartz (I only logged in and out...).

After rebooting with rc1, the problem has gone away!

Thanks for your time in exploring this matter.

comment:7 Changed 13 months ago by tgl@…

FWIW, I saw something probably related with Lion and 2.7.2_rc1. When using an external monitor with my MBP, I configure the external display to be "above" the internal, with system menu bar at top (on the external screen) and Dock at bottom (on the internal). I observed that clicking the green button to resize an xterm window on the external screen to full-screen would not make it occupy the whole external screen; it would leave a strip at the bottom unused. This strip looked about the right height for the Dock. On the other hand, maximizing an xterm that was on the internal screen made it use the whole internal screen, such that the bottom part of the xterm window was obscured by the Dock. This was repeatable, ie you could de-maximize and re-maximize either window and it would do the same wrong thing. So clearly, the resizer had the wrong idea about where the Dock was. I don't recall having seen any similar behavior with prior XQuartz versions (and this sort of resizing is something I do a lot, so I think I would've noticed).

I was about to file a bug when I found this report, and decided to try rebooting since that made mrsvan's issue go away. Darn if it didn't make my issue go away, too. Curious thing is that I thought I'd already rebooted since installing rc1. I wonder whether it has anything to do with whether you have the external monitor connected at the time you reboot. No time to experiment further right now, though.

comment:8 Changed 13 months ago by tgl@…

  • Cc tgl@… added

Cc Me!

comment:9 follow-up: ↓ 10 Changed 13 months ago by tgl@…

Hah, I can reproduce this without any external monitor:

  • Start X11, open a terminal window, maximize and de-maximize it a couple of times with the green button. Observe that the maximized window doesn't overlap the Dock.
  • Move the Dock to another screen edge, using Dock preferences or the handy items in the Apple menu.
  • Re-maximize the xterm window. Observe that it goes to the same dimensions it had before, so that now it's overlapping the Dock.

Once you are in this state, it persists until you quit and restart X11 (a full reboot doesn't seem to be necessary to fix it).

Hence, an accurate characterization of the bug seems to be: maximization leaves room for the Dock according to where the Dock was when X11 started, not according to where the Dock is now. This is unlike the behavior of previous versions of X11, so I feel safe in calling it a bug and not just an unimplemented feature.

comment:10 in reply to: ↑ 9 ; follow-up: ↓ 11 Changed 13 months ago by jeremyhu@…

  • Component changed from xserver to quartz-wm

Replying to tgl@…:

  • Start X11, open a terminal window, maximize and de-maximize it a couple of times with the green button. Observe that the maximized window doesn't overlap the Dock.

That is intentional (correct) behavior.

  • Move the Dock to another screen edge, using Dock preferences or the handy items in the Apple menu.
  • Re-maximize the xterm window. Observe that it goes to the same dimensions it had before, so that now it's overlapping the Dock.

It sounds like quartz-wm doesn't re-query the dock rect. It should be. Are you sure you're using the correct quartz-wm? Older versions of quartz-wm didn't do this right. What is the output of:

ps x | grep quartz-wm

Once you are in this state, it persists until you quit and restart X11 (a full reboot doesn't seem to be necessary to fix it).

Yeah. Although you just need to restart quartz-wm

Hence, an accurate characterization of the bug seems to be: maximization leaves room for the Dock according to where the Dock was when X11 started, not according to where the Dock is now. This is unlike the behavior of previous versions of X11, so I feel safe in calling it a bug and not just an unimplemented feature.

Do you know what version introduced this change?

comment:11 in reply to: ↑ 10 Changed 13 months ago by tgl@…

Replying to jeremyhu@…:

It sounds like quartz-wm doesn't re-query the dock rect. It should be. Are you sure you're using the correct quartz-wm? Older versions of quartz-wm didn't do this right. What is the output of:

ps x | grep quartz-wm

I see

 1459   ??  S      0:00.11 /opt/X11/bin/quartz-wm
 1566 s001  R+     0:00.00 grep quartz-wm

Do you know what version introduced this change?

Not with precision. It's there in rc1, it wasn't there in 2.7.1. I plead guilty to not having tried any of the 2.7.2 betas.

comment:12 Changed 13 months ago by jeremyhu@…

  • Status changed from new to closed
  • Version set to dev (master)
  • Resolution set to fixed
  • Milestone set to 2.7.2

Ok, I have a fix. It will be in rc2. Thanks.

Note: See TracTickets for help on using tickets.