Bug 104262
| Summary: | no click and drag window movement | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 3 | Reporter: | Peter Lannigan <peter.lannigan> |
| Component: | metacity | Assignee: | Havoc Pennington <hp> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.0 | CC: | braden, djuran, dm, jbwyatt4, kreg, redhat-bugzilla, robatino |
| Target Milestone: | --- | Keywords: | Triaged |
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-05-25 19:50:55 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 100643 | ||
I can't reproduce this at all. Hmm. OK furthur testing on my part shows that it is not all applications. It does happen consistently with Netscape 7.1 OpenOffice-1.0.2-4 Intermitantly with Evolution Never with gnome-terminal hardware-browser With Openoffice I click once to select the window, click again and it starts following my mouse around until I click once more. Hope this helps... Are the windows maximized when you click? Does it matter whether you click-release slowly or quickly? (Perhaps it's a bug in double-click handling?) I'm seeing this with metacity-2.6.2-1 on fedora-core (severn2). Clicking on the title bar of an obscurred windows puts metacity into move window mode. (Cursor changes to arrow with a plus sign, window moves with mouse). It happens almost all the time for me but I can't say it happens 100% of the time. Windows are generally not maximized. Because it's fedora and not rhel, should I open a separate bug? I am 90% convinced this is XFree86 or kernel or something rather than metacity. The fact that it happens in RHEL (2.4.55) and also Fedora (2.6.2) reinforces that view, since 2.4.55 has few changes from RHL9. Also, I can't reproduce this problem running any metacity version with the older kernel/X on my system. If you back down to the RHL9 metacity, does this still happen? It would be useful to try fooling with X/kernel versions and see if it matters. Perhaps it depends on the particular hardware even? One bug for all OS's is fine, no need to create a new one. *** Bug 104373 has been marked as a duplicate of this bug. *** *** Bug 106250 has been marked as a duplicate of this bug. *** While 104373 seems fixed with the latest RawHide metacity (2.6.2-1), 106250 is still there (rare, hard to reproduce). I am not entirely convinded that this is a kernel/XFree issue, since I have not seen anything like this running fluxbox on the very same RawHide, or replacing metacity with sawfish as the windowmanager under Gnome2. Just metacity behaves weird. *** Bug 105872 has been marked as a duplicate of this bug. *** *** Bug 105724 has been marked as a duplicate of this bug. *** I seem to have this happen with gnome-terminal and Mozilla or Firebird. I do web development and often switch between them. Like posted above, not always, but often. (I haven't tried new metacity). No probs in KDE either. I think this is fixed as of 2.6.3. From NEWS file: - detect case where we fail to get a pointer grab when the mouse is clicked, to avoid "this window is stuck to my mouse!" I still see this on metacity-2.6.3-1 from RawHide/Fedora. I'm still see this bug on released taroon, so it might be apropriate to change the prduct. Also I tested this on RHL 9 and severn yesterday and did not see this behaviour. I am still seeing this with the latest Fedora Devel metacity. It is more bound to happen if the machine is under I/O load (installation of large RPM packages, anacron run). I am using gnome on Red Hat Enterprise Linux WS release 3 (Taroon Update 1) I see this issue as well. It is very annoying. As is stated elsewhere, it seems to happen more when the computer is loaded. It is difficult to reproduce, but I have had it happen to me using virtually every program, so it is either a window manager thing or something else, not program related. Should be fixed in Fedora Core 2, and a backport of the fix is scheduled for the next RHEL 3 update. Comment received from Kurt Kimber via email: ********** Your last comment in bugzilla for Bug 104262 was: > Should be fixed in Fedora Core 2, and a backport of the fix is > scheduled for the next RHEL 3 update. I'm still seeing this bug. We're running RHEL 3 with gnome. % uname -a Linux xenon 2.4.21-27.0.2.ELsmp #1 SMP Wed Jan 12 23:35:44 EST 2005 i686 i686 i3 86 GNU/Linux Here's a potential workaround: I disabled Preferences -> "Keyboard Shortcuts" for "Move a Window" <alt-F7> (don't know if this step is necessary or not). Then I right click the titlebar of a misbehaving window and select the "Move" option; window moves, I place it. After doing this, all windows seem to behave properly for a time. If problem reappears, I re-execute same workaround. ********** (In reply to comment #21) > Comment received from Kurt Kimber via email: > > ********** > > Your last comment in bugzilla for Bug 104262 was: > > > Should be fixed in Fedora Core 2, and a backport of the fix is > > scheduled for the next RHEL 3 update. > > I'm still seeing this bug. We're running RHEL 3 with gnome. > > % uname -a > Linux xenon 2.4.21-27.0.2.ELsmp #1 SMP Wed Jan 12 23:35:44 EST 2005 i686 i686 i3 > 86 GNU/Linux > > Here's a potential workaround: I disabled Preferences -> "Keyboard Shortcuts" > for "Move a Window" <alt-F7> (don't know if this step is necessary or not). > Then I right click the titlebar of a misbehaving window and select the "Move" > option; window moves, I place it. After doing this, all windows seem to behave > properly for a time. If problem reappears, I re-execute same workaround. > > ********** > I'm running this version of RHEL 3 with gnome: % uname -a Linux xenon 2.4.21-27.0.2.ELsmp #1 SMP Wed Jan 12 23:35:44 EST 2005 i686 i686 i386 GNU/Linux Symptoms: when I click on window's title bar, this action is intrepretted by metacity as a "move window" command when it should be interpretted as a "raise window above other windows" command. What usually initiates this misbehavior is starting a second session on a machine (i.e., logging in username/password using the gui login screen). The gnome session manager gives a warning about doing this since the other session already has ownership of session configuration files. Once I log in to this second session, then the misbehaving windows usually starts. I'm guessing some configuration file gets corrupted. I'm a newbie to this process, but seems to me like this bug should be reopened. |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 Description of problem: The default behaviour for moving a window seems to have changed and I can't figure out a way to change it back. It used to be (for many versions of RedHat) that under Gnome you could click and drag with the left mouse button on a window bar (the top), move the window where you want, and then let go of the window. Now when you left click nothing happens at first. When you let go the window starts moving and follows your mouse. When you click again it sets the window. It makes window placement difficult because it takes a while for all this to happen; even on my P4 2.4 GHz Dell Optiplex. This seems like a minor issue, but its driving me nuts and I KNOW my users will freak out. Version-Release number of selected component (if applicable): metacity-2.4.55-6 How reproducible: Always Steps to Reproduce: 1.Login with Gnome 2.Click on a window bar and move the mouse 3.Click again to set the window Additional info: My Dell box has an ATi video card in it. My .<files> have been carried forward for a while from RH 7.3 to RH 8.0 to RH Ent 3 (beta 1). The current RH Ent 3 (beta 1) install was a full install - everything on the CD.