[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 288292] New: Focused window for mouse events is not the active
From:       Eduardo Robles Elvira <edulix () gmail ! com>
Date:       2011-12-05 22:45:37
Message-ID: bug-288292-17878 () http ! bugs ! kde ! org/
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=288292

           Summary: Focused window for mouse events is not the active
                    window (but keyboard focus is fine)
           Product: kwin
           Version: 4.7.2
          Platform: openSUSE RPMs
        OS/Version: Linux
            Status: NEW
          Severity: major
          Priority: NOR
         Component: general
        AssignedTo: kwin-bugs-null@kde.org
        ReportedBy: edulix@gmail.com


Version:           4.7.2 (using KDE 4.7.2) 
OS:                Linux

Sometimes the focused window for mouse events stops being the currently
focused/active window and suddently the focused window for mouse purposes is
another opened window - but the keyboard focus remains correct.

Reproducible: Couldn't Reproduce

Steps to Reproduce:
I haven't found any consistent way to reproduce the bug and I *do* have tried,
sorry.

Actual Results:  
Mouse events are psuedo-randomly forwarded to a non focused window.

Expected Results:  
Mouse events are redirected to the active window: the focused window for mouse
events should be the same window that has the focus for keyboard events.

I'm using opengl compositing and OpenSUSE Tumbleweed, Kernel 3.1.0-1.2-default
64 bits, it's an Thinkpad X220 laptop with an Intel HD Graphics 3000 graphic
card and using intel free software i915 driver.

All mouse over, mouse left click, mouse right click events are redirected to
another window, which might even be in another desktop. When the bug is
happening, changing via Alt+Tab (or Ctrl+Tab) to another window does not change
the focused window for mouse events.

This seems to be related to XWindows, because sometimes it's a firefox
flashplayer (which is in another process and uses its own xwindow for
rendering) the window the the mouse focus.

I've found a way to workaround/mitigate the bug: right clicking the active
window by hitting the <Menu> key (the one usually between <AltGr> and <Ctrl>),
which launches the contextual menu of the keyboard focused window (which is the
really focused window for the user). Then close that contextual menu, and now
the mouse's focused window is the correct window. 
This probably happens because when closing the popup menu xwindow, the mouse
focus is given to the parent window of that popup menu, which happens to be the
correct window.

By the way, this bug comes as easily as it vanishes: after a while the bug is
in place and the mouse's focused window is wrong, then all of a sudden the
mouse focus comes back to normal.

I must note that even this bug does NOT cause any crash, it might certainly
cause data loss to the user because the whole operative system becomes totally
unusable depending on what application are you using and the user's ability to
manage the situation. I've been suffering this bug for some weeks since the
last Tumbleweed update and only today I've found the mentioned workaround:
previously, the only solution I had was to restart X via a TTY using
/etc/init.d/xdm restart, losing everything I was doing, and I'm a "poweruser".

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
[prev in list] [next in list] [prev in thread] [next in thread]