/qubes-issues

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

keyboard focus bug #738

Closed
marmarek opened this Issue Mar 8, 2015 · 9 comments

Comments

Assignees
No one assigned
Labels
Projects
None yet
Milestone
  Release 2.0 updates
2 participants
@marmarek @nrgaway
@marmarek
Member

marmarek commented Mar 8, 2015

Reported by marmarek on 16 Jun 2013 11:56 UTC
On 06/09/13 10:09, ix4...@gmail.com wrote:

This always involves the use of KeePassX, which traps [CTR-V] as "Perform
auto-type". My typical workflow:

  1. start "passwords" AppVM
  2. highlight, copy, SHFT-CTRL-C my "personal" master pw
  3. start "personal" AppVM by firing up Firefox & KeePassX
  4. click on the KeePassX window, hit SHFT-CTRL-V & CTRL-V. The master pw is correctly copied into the dialog box and my personal AppVM pw db is unlocked.
  5. ALT-TAB or click on the FF window to ensure the focus is on the right field (the "username" field of the form I want to autocomplete").
  6. ALT-TAB or click on the KeePassX window, highlight the credentials entry I want to use, hit CTRL-V
  7. Watch in horror as my master pw which was copied earlier from the non-networked password AppVM is pasted into Firefox!
  8. At that point, with the KeePassX window in the foreground, clicking entries in it with the mouse, anything I type is received by the non-active Firefox window, not just CTRL-V.

On 06/12/13 01:22, ix4...@gmail.com wrote:

On 11 June 2013 19:14, Joanna Rutkowska joa...@invisiblethingslab.comwrote:

IIUC the problem only affects switching focus between the two windows
belonging to the same AppVM, correct?

joanna.

Correct.

Ok, perhaps there is a bug there, which is a result of us not being able
to precisely reflect the order of windows within one domain. However, I
don't think I agree this could be classified as "dangerous", or even
security-related. We've been explaining this many time -- there is no
security isolation between apps running within one domain.

Details here: https://groups.google.com/d/msg/qubes-users/2m93GabHx6I/kIuL7ZQ7alIJ

Migrated-From: https://wiki.qubes-os.org/ticket/738
@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Modified by joanna on 1 Aug 2013 11:55 UTC
Member

marmarek commented Mar 8, 2015

Modified by joanna on 1 Aug 2013 11:55 UTC

@marmarek marmarek added bug C: gui-virtualization P: minor labels Mar 8, 2015

@marmarek marmarek added this to the Release 2 Beta 3 milestone Mar 8, 2015

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Modified by joanna on 18 Nov 2013 13:53 UTC
Member

marmarek commented Mar 8, 2015

Modified by joanna on 18 Nov 2013 13:53 UTC

@marmarek marmarek removed this from the Release 2 Beta 3 milestone Mar 8, 2015

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Modified by joanna on 28 Mar 2014 15:19 UTC
Member

marmarek commented Mar 8, 2015

Modified by joanna on 28 Mar 2014 15:19 UTC

@marmarek marmarek added this to the Release 2 milestone Mar 8, 2015

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Modified by joanna on 30 Jun 2014 11:47 UTC
Member

marmarek commented Mar 8, 2015

Modified by joanna on 30 Jun 2014 11:47 UTC

@marmarek marmarek modified the milestones: Release 2.1 (post R2), Release 2 Mar 8, 2015

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by marmarek on 10 Dec 2014 11:44 UTC
More details here:
https://groups.google.com/forum/#!msg/qubes-users/8wH7AXWK_94/06YScIdT_Z0J
Member

marmarek commented Mar 8, 2015

Comment by marmarek on 10 Dec 2014 11:44 UTC
More details here:
https://groups.google.com/forum/#!msg/qubes-users/8wH7AXWK_94/06YScIdT_Z0J

@marmarek marmarek referenced this issue Mar 8, 2015

Closed

Input is sometimes not sent to the focused window #946

@marmarek marmarek referenced this issue Apr 25, 2015

Closed

Security critical bug: input is often directed to a window that is not focused, esp. w/ text editors #964

@marmarek marmarek closed this in marmarek/old-qubes-gui-daemon@0a9dace May 22, 2015

@nrgaway

This comment has been minimized.

Show comment
Hide comment
@nrgaway

nrgaway May 22, 2015

This is really fixed? That's been my top peeve :)

Guess I have some compiling to do...

nrgaway commented May 22, 2015

This is really fixed? That's been my top peeve :)

Guess I have some compiling to do...
@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek May 22, 2015

Member

On Fri, May 22, 2015 at 06:14:24AM -0700, nrgaway wrote:

This is really fixed? That's been my top peeve :)

I hope so :)
Unfortunately it isn't possible close the issue (with commit message)
when the commit is pushed to specific branch, so when I push a fix to
any branch (like testing or so), it automatically closes the issue. So I
can either mark proposed fix to close the issue (and possibly reopen it
later), or close it manually after some confirmation. I'm too lazy for
the later option ;)

Guess I have some compiling to do...

Package is already in current-testing

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
Member

marmarek commented May 22, 2015

On Fri, May 22, 2015 at 06:14:24AM -0700, nrgaway wrote:

This is really fixed? That's been my top peeve :)

I hope so :)
Unfortunately it isn't possible close the issue (with commit message)
when the commit is pushed to specific branch, so when I push a fix to
any branch (like testing or so), it automatically closes the issue. So I
can either mark proposed fix to close the issue (and possibly reopen it
later), or close it manually after some confirmation. I'm too lazy for
the later option ;)

Guess I have some compiling to do...

Package is already in current-testing

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
@nrgaway

This comment has been minimized.

Show comment
Hide comment
@nrgaway

nrgaway May 22, 2015

Did you push to fc20 testing repo too? Only my fc21 updated

nrgaway commented May 22, 2015

Did you push to fc20 testing repo too? Only my fc21 updated
@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek May 22, 2015

Member

On Fri, May 22, 2015 at 06:43:31AM -0700, nrgaway wrote:

Did you push to fc20 testing repo too? Only my fc21 updated

It is update for dom0, qubes-gui-dom0-3.0.4.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
Member

marmarek commented May 22, 2015

On Fri, May 22, 2015 at 06:43:31AM -0700, nrgaway wrote:

Did you push to fc20 testing repo too? Only my fc21 updated

It is update for dom0, qubes-gui-dom0-3.0.4.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

marmarek added a commit to marmarek/old-qubes-gui-daemon that referenced this issue Jun 2, 2015

@marmarek
Do not sent excessive focus events (#738) 
During task switching some window managers (at least KDE) uses input
grab. This in turn generates some additional focus in/out events, which
if processed out of order, could lead to wrong VM window having focus. For
example this sequence is happening on Alt-Tab on KDE (switching from
window A to B):
type     w mode          detail
FocusOut A NotifyGrab    NotifyAncestor
FocusOut A NotifyUngrab  NotifyPointer
FocusIn  A NotifyUngrab  NotifyAncestor
FocusOut A NotifyGrab    NotifyAncestor
FocusOut A NotifyUngrab  NotifyPointer
FocusIn  A NotifyUngrab  NotifyAncestor
FocusOut A NotifyNormal  NotifyNonlinear
FocusIn  B NotifyNormal  NotifyNonlinear

Now, when processing one of those "FocusIn A" is delayed(*), the A
window in VM can retake focus after window B already received it.

Switching using "present windows" feature is even more complicated:
type     w mode                detail
FocusOut A NotifyGrab          NotifyAncestor
FocusOut A NotifyUngrab        NotifyPointer
FocusIn  A NotifyUngrab        NotifyAncestor
FocusOut A NotifyGrab          NotifyAncestor
FocusOut A NotifyWhileGrabbed  NotifyNonlinear
FocusIn  B NotifyWhileGrabbed  NotifyNonlinear
FocusOut B NotifyUngrab        NotifyPointer
FocusIn  B NotifyUngrab        NotifyAncestor

(*) In Linux GUI agent it may be implemented as asynchronously sending
WM_TAKE_FOCUS message to the application (depending on advertised
features) - the application can process this message with unpredictable
delay.

VM have no way to grab focus (which is intended feature), so it
shouldn't care about all those NotifyGrab/NotifyUngrab events. When
filtered out, the only events left are simple FocusOut for previous
windows and FocusIn for the new one.

Fixes QubesOS/qubes-issues#738

(cherry picked from commit 0a9dace)
4d0a493

@andrewdavidwong andrewdavidwong referenced this issue Apr 24, 2016

Closed

Windows 7 HVM cannot capture keystrokes during login #1933

@andrewdavidwong andrewdavidwong referenced this issue Nov 1, 2017

Open

window focus issue #3267

@andrewdavidwong andrewdavidwong referenced this issue Jul 14, 2018

Open

Dom0 to DomU window GUI pixel precision issues (i.e. some drag and drop scenarios, or some dynamically changing content scenarios) #4079

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment