Bug 77064 - window fixed in position
window fixed in position
Status: CLOSED DUPLICATE of bug 63509
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
8.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-10-31 12:32 EST by jmccann
Modified: 2015-01-14 18:19 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 13:50:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description jmccann 2002-10-31 12:32:56 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:
Comment 1 Havoc Pennington 2002-10-31 12:42:44 EST
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
Comment 2 jmccann 2002-10-31 13:19:00 EST
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?
Comment 3 Havoc Pennington 2002-10-31 13:34:11 EST
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...
Comment 4 jmccann 2002-10-31 14:16:27 EST
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.
Comment 5 Havoc Pennington 2002-10-31 14:48:54 EST
> 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.
Comment 6 Mike A. Harris 2002-12-19 06:16:59 EST

*** This bug has been marked as a duplicate of 63509 ***
Comment 7 Red Hat Bugzilla 2006-02-21 13:50:04 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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