Windows that span screen width or height cannot be resized in that dimension

[Joachim Noreiko]

I sometimes find that a firefox window that touches opposite edges of the screen can't be moved or resized in that direction.
For example, a browser window that touches both top and bottom panels can't be moved up or down or reduced in height. The DOM inspector set to full width can't be moved left or right.
With the mouse on the window border, nothing happens -- the pointer moves but the window edge doesn't follow. With the window menu's resize command, the mouse pointer seems to jump to far, going into the panel.

This seems to apply to windows that are created this size, not to windows that are enlarged to this size.

I'm able to reproduce this by opening the DOM inspector, resizing it to full width, closing it, then opening it again. The window remembers its previous size and now can't be reduced in width.

[libertyernie (libertyernie)]

Should this bug be filed in metacity?

[Joachim Noreiko (jnoreiko)]

I can't reproduce it with other applications.

[John Vivirito (gnomefreak)]

Is firefox the only app you see this in? it works properly for all other browsers? since browsers are really the only app that gets full screen automaticly most other apps run in mid screen like nautilus.

[Joachim Noreiko (jnoreiko)]

I tried maximizing gedit and nautilus and both were normal.
My Firefox normally launches a window that is full-height but not maximized (ie not full width).

[Joachim Noreiko (jnoreiko)]

Ok... had more of a play around with this. I can reproduce with both Epiphany and Gedit.

To reproduce with gedit:
1. Launch gedit.
2. Size the window so it's full height but not full width.
3. quite gedit
4. relaunch gedit. It should have remembered the last window size.
5. try to change the height. You can't.

This also happens with window that is full width and partial height.

The workaround is to maximise and then restore.

[Albert Damen (albrt)]

I can only reproduce this when compiz is active. With desktop-effects switched off, the problem does not occur.
As metacity is not active when desktop-effects are on, I think this would actually be a bug in either compiz or gtk-window-decorator.
Joachim, can you please try what happens for you if you switch off desktop-effects?

[Joachim Noreiko (jnoreiko)]

I'm not running compiz, and desktop-effects are not enabled.

[Albert Damen (albrt)]

Contact on #ubuntu-bugs showed Joachim is using Feisty, with Metacity 2.18.2
I am using Gutsy, with Metacity version 2.20.0. I did a second test in a virtual machine with Gutsy, which also did not show the problem. As this problem is solved in the development version, I will mark this as fix released for Metacity.
I added Compiz as I do see this problem with desktop-effects enabled.
Joachim, thanks for reporting this bug.

[Rouben (rouben)]

I can't reproduce this issue with latest Compiz + Emerald on Gutsy.

[Travis Watkins (amaranth)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with latest Ubuntu release? Thanks in advance.

[Albert Damen (albrt)]

Yes it is still happening in both Gutsy and Hardy. While testing I found the possible cause of the problem. When I resize the window it is very well possible to push the active part of the window border (where you can grab it with the mouse) to the next workspace on the cube. Rotating the cube makes the active part of the border visible again, so you can push it back to the original workspace.
Maximizing the size of the window helps in Gutsy, because it brings all borders completely on the correct workspace. In Hardy a maximized window does not seem to have active borders at all, so the trick to maximize the window and then resize does not work.
In my opinion it should not be possible to push the border of a window to the next workspace.
In case it may be relevant, I am using the Human theme and gtk-window-decorator on both my Gutsy and my Hardy system.

[Joachim Noreiko (jnoreiko)]

I can no longer reproduce this in 7.10 with visual effects set to 'none'.

Albert, I'm not sure how your theory explains the problem when the window is tall and narrow...

[Basilio Kublik (sourcercito)]

Hi there
Can you reproduce this in Hardy with the latest upgrades?

Thanks in advance.

[Albert Damen (albrt)]

Yes I can. However, feel free to close this bug as I seem to be the only one who notices this and I can live with it.

[Hew (hew)]

Albert: I can't reproduce this with compiz in Intrepid. Is this still an issue for you with compiz 0.7.7? Thanks in advance.

[Albert Damen (albrt)]

Yes, I can still reproduce on my up-to-date Intrepid system.
To make sure it is not a problem with old settings, I also reproduced it with an Alpha6 live-cd:

- boot Alpha 6 live-cd
- enable universe repository
- install compizconfig-settings-manager
- in ccsm, disable "desktop wall", enable "desktop cube" and "rotate cube"
- in ccsm, "general", "desktop size" set "Horizontal Virtual Size" to 4 (so we have a real cube)
- in viewport 1 open gedit
- grab the left window edge and push it all the way left
- notice you cannot grab the left edge any more, so you cannot reduce the window size
- go to viewport 4 and notice you will see the edge of the gedit window on the right side

The live cd has compiz: 1:0.7.7+git20080807-0ubuntu10

[Hew (hew)]

You're right. With your instructions, I can now reproduce this issue, so I'm setting the status to Triaged.

This bug applies with both desktop wall and desktop cube, but it is only with the cube that you cannot grab the edge anymore after resizing.

[Travis Watkins (amaranth)]

Fixed in git: http://cgit.compiz.org/compiz/core/commit/?id=6c12e5a60297143a72c4e4bb104b0c35102ff3f4

[Launchpad Janitor (janitor)]

This bug was fixed in the package compiz - 1:0.8.3+git20091005-0ubuntu5

---------------
compiz (1:0.8.3+git20091005-0ubuntu5) karmic; urgency=low

  * New snapshot from upstream stable git:
     - compiz.real crashed with SIGSEGV in blurDrawWindow()
       (LP: #353236)
     - Windows disappear if resolution is changed to something smaller
       than window size (LP: #414134)
     - compiz.real crashed with SIGSEGV in handleEvent() (LP: #430518)
     - Windows that span screen width or height cannot be resized
       in that dimension (LP: #137134)
     - Reducing number of workspaces leaves windows inaccessible
       (LP: #189259)
     - "Snap Inverted" in Wobbly Windows compiz plugin broken
       (LP: #366822)
     - Problem when resizing and the Panels
       (LP: #408030)
  * debian/control:
    - make compiz package depend on compiz-gnome | compiz-kde (LP: #172385)
  * debian/patches/015_draw_dock_shadows_on_desktop.patch:
    - fix clock/calendar shadow not going away (LP: #428783)
      thanks to Erkin Bahceci
  * debian/patches/029_default_options:
    - add a focus prevention match to allow polkit windows to steal focus
      otherwise they never get focus (LP: #436852)
  * debian/compiz-gnome.gconf-defaults:
    - change /apps/gwd/blur_type to all since it only does anything if blur
      is enabled and is usually what is wanted (LP: #158376)
    - turn constrain_y back on (LP: #82654)
  * debian/rules:
    - add commands plugin to default active_plugins (LP: #355018)

 -- Travis Watkins <email address hidden> Mon, 05 Oct 2009 15:42:00 +0200