After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 680214 - Spurious window resize of new windows to another window's size.
Spurious window resize of new windows to another window's size.
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: general
3.4.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2012-07-19 00:12 UTC by Eric Anholt
Modified: 2021-07-05 14:04 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
0001-util-Warn-and-report-SKIP-when-we-get-a-window-resiz.patch (1.16 KB, patch)
2012-07-19 00:12 UTC, Eric Anholt
needs-work Details | Review

Description Eric Anholt 2012-07-19 00:12:14 UTC
Created attachment 219174 [details] [review]
0001-util-Warn-and-report-SKIP-when-we-get-a-window-resiz.patch

Environment: debian unstable.
ii  gnome-shell                           3.4.1-8 amd64
ii  freeglut3:amd64                       2.6.0-4

The GL regression testing suite, piglit, is unfortunately somewhat reliant on getting its windows at the size it requested, or some tests will report failure.  This is not a problem on most wms (such as metacity), but gnome-shell sometimes produces a resize event from freeglut, and the size happens to be that of another piglit window that was created.  Steps to reproduce:

git clone git://anongit.freedesktop.org:/git/piglit
cd piglit
# flail around to get dependencies
# I'm so sorry about the cmake here.
cmake .
git am 0001-util-Warn-and-report-SKIP-when-we-get-a-window-resiz.patch
make
while ./bin/scissor-stencil-clear -auto | grep "pass"; do; done
# the 100x100 test above will happily run until you get bored.  now, open a new tab and start this:
while ./bin/copy-pixels -auto | grep "pass"; do; done
# this one is 32x32.  eventually, one of the two fails, and the size was the other one's size.  I've seen failure when I'm not interacting with the system, but failure rate may be correlated with moving the mouse or alt-tabbing.

Note that while I'm running these loops, tail -f ~/.xsession-errors is sometimes reporting:

Window manager warning: Log level 16: STACK_OP_ADD: window 0x2e00002 already in stack
Comment 1 Eric Anholt 2012-07-19 00:14:54 UTC
Full disclosure: I'm running the alternatetab, frippery panel favorites, remove accessibility, and remove user name extensions.  However, given that QA has been reporting these spurious failures under gnome-shell, I don't expect them to be part of the problem.
Comment 2 Jasper St. Pierre (not reading bugmail) 2013-03-03 21:54:53 UTC
Do these issues happen under mutter or metacity, which have the same constraints code? Are you marking your window as override-redirect to prevent resizes? Otherwise, it's fully within the ICCCM to allow WMs to deny client resize requests.
Comment 3 Eric Anholt 2013-09-04 18:34:58 UTC
Regardless of whether it's ICCCM-allowed, do you think it's reasonable to assign a brand new window the size of somebody else's brand new window, just because somebody else happened to be making a window?

This problem hasn't been seen under metacity.
Comment 4 André Klapper 2015-01-17 03:03:04 UTC
Comment on attachment 219174 [details] [review]
0001-util-Warn-and-report-SKIP-when-we-get-a-window-resiz.patch

tests/util/piglit-framework-glut.c does not exist anymore in git master of gnome-shell.

Hence setting 'needs-rework' as patch does not apply cleanly against git master.
Comment 5 GNOME Infrastructure Team 2021-07-05 14:04:03 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of  gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/

Thank you for your understanding and your help.