Red Hat Bugzilla – Bug 77064
window fixed in position
Last modified: 2015-01-14 18:19:42 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021028 Description of problem: After logging in from gdm some sessions have a problem where windows cannot be moved. In other words their position and size in the workspace cannot be changed. After logging out, sending gdm a SIGUSR1, and logging back in the problem is corrected. This problem happens occasionally on desktop workstations with a single monitor but I have a hard time reproducing it. However, I am able to reproduce the problem every time on a laptop with an external monitor. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Boot laptop 2. Login to gnome2 using gdm 3. Start gnome terminal 4. Move gnome terminal (successfully) 5. Press Fn-F8 to send video signal to external monitor (in addition to LCD) 6. Attempt to move gnome terminal (unsuccessfully) 7. Press Fn-F8 to send send video signal to external monitor (without LCD) 8. Attempt to move gnome terminal (unsuccessfully) 9. Press Fn-F8 to send send video signal to LCD monitor (without external monitor) 10. Attempt to move gnome terminal (unsuccessfully) Actual Results: Window become frozen in position. Expected Results: Windows should be able to be moved by the mouse. Additional info:
This may happen if the system clock goes backward, that's the only case I know of. metacity 2.4.3 fixes the clock issue, you can get a test package at ftp://people.redhat.com/hp/gnomehide/8.0
Thanks for the quick reply! It looks like a time problem. I noticed that when I used Fn-F8 to switch displays the gnome clock would change. For example, if I perform "sudo rdate -s ntp.jhu.edu" between step 2 and step 3 lets say that my clock changes from 8am to 1pm (the correct local time). Then when I change displays in step 5 the gnome clock reads 8am. If I sync the clock again, I am able to move gnome terminal as expected. I installed your new metacity and, unfortunately, it doesn't fix the problem. I even rebooted after installing it. It seems that the inability to move/resize windows is only a symptom of the problem. I think the real problem is that the mouse button is not recognized as being held down. PS. Do you think there is another bug here where shutdown is not correctly setting my bios clock?
It's possible that the X server itself gets confused if you play with the time enough. You can use "xev" to look at mouse button events and see what you're getting. I don't have a lot of ideas if it wasn't the time-set-backward bug that I knew about...
When it works the event for motion with button 3 down is: MotionNotify event, serial 20, synthetic NO, window 0x1e00001, root 0x78, subw 0x0, time 1004178880, (94,146), root:(100,192), state 0x400, is_hint 0, same_screen YES When is doesn't work (when the time is wrong) the event with button 3 down is: MotionNotify event, serial 20, synthetic NO, window 0x1e00001, root 0x78, subw 0x0, time 1004102453, (162,142), root:(168,188), state 0x0, is_hint 0, same_screen YES First, I don't think changing the display from LCD to external should reset the system time. Second, X shouldn't really care what the time is since the relationship between the button down event and the motion event is always the same. Should I submit these as X server bugs? Thanks for your help.
> First, I don't think changing the display from LCD to external should reset the > system time. I would certainly agree with that. ;-) > Second, X shouldn't really care what the time is since the > relationship between the button down event and the motion event is always the > same. The "state" field is mangled in your second example, so it seems X loses track of whether the button is down. This looks like an X server (or hardware/BIOS) problem to me, so moving.
*** This bug has been marked as a duplicate of 63509 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.