Bug 859036

Guest was W7x64.

The component has been set to spice-client-win, but the report mentions Virt-viewer 0.5.2-9.el6. Moreover, I don't expect the ctrl+alt+del option to work with a windows client, so I assume the component is wrong?
Probably a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=807771

(In reply to comment #2)
> The component has been set to spice-client-win, but the report mentions
> Virt-viewer 0.5.2-9.el6. Moreover, I don't expect the ctrl+alt+del option to
> work with a windows client, so I assume the component is wrong?

actually, this feature was developed specificaly for windows clients (windows xp in workgroup mode mostly)

> Probably a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=807771

well, if it is not implemented, of course it isn't working?

(In reply to comment #3)
> (In reply to comment #2)
> > The component has been set to spice-client-win, but the report mentions
> > Virt-viewer 0.5.2-9.el6. Moreover, I don't expect the ctrl+alt+del option to
> > work with a windows client, so I assume the component is wrong?
> 
> actually, this feature was developed specificaly for windows clients
> (windows xp in workgroup mode mostly)

As far as I know, Windows does not allow applications to intercept the ctrl+alt+del key combination, so this is not possible to implement, for example see http://en.wikipedia.org/wiki/Control-Alt-Delete#Windows_NT_.28and_later_versions.29 :
"[...] a user process is not able to intercept the Control-Alt-Delete sequence."

Fwiw, I'd be interested in a description of what problem and use cases we are trying to solve with this key combination, and about the expected behaviour when "pass ctrl+alt+del" is set/unset (not "the ctrl+alt+del combination is passed through" but "the user wants to do XXX, he can do that by checking the box, and he can achieve YYY by unchecking it")

this worked, it isn't theortical.
on windows xp, in workgroup mode (not part of AD), hitting ctrl-alt-del opened task manager in client.
when this was enabled, the spice client would:
- kill the task manager process so it wouldn't open (used to be another flag, consolidated to the CAD flag)
- detect the CAD and send it to the guest (so yes, windows got it first, but client could still detect it was pressed)

this may not be relevant with windows 7

Ah very interesting, thanks a lot! I couldn't find anyone to explain what we were trying to achieve with this ctrl+alt+del feature last time I worked on it, which made it harder to work on...
This "detect ctrl+alt+del/close window" hack is not implemented either in the client.

(In reply to comment #5)
What is the use case for not sending CAD to the guest, when users press CAD while the client window is in-focus ?

1. This bug was submitted to the user-portal. It is the only justification it is in the RHEVM product. The bug was found on RHEL client machine!!! for clarification: the win-spice-client is for the old spice client (spicec), and we should use mingw-virt-viewer instead;

2. The correct location should be in the rhel spice-gtk - it is rhel client

3. In the virt-viewer implementation we have an option to send CAD to the guest regardless of the OS on client/guest. 

4. On the rhel client the behavior is exactly as it is expected on rhel machine (from in Description "...if VM is in focus CAD is passed to it and out of focus it is sent to the client")

5. On the Win machine CAD brings the Task Manager of the client as it is expected. And for sending the CAD to the VM use option (see 2).

6. And based on the above we can illuminate the option in the user-portal starting from 3.1. 

Are there any missing use-cases?

*** Bug 879321 has been marked as a duplicate of this bug. ***

Since this requires considerable development time and is not a regression apparently, should one treat it as RFE?

My understanding is that this is a Windows-only feature. According to http://stackoverflow.com/a/11658230/1277510, it will require admin right to install a privilege filter or application/agent to tweak the registry dynamically.

(this looks like a limited windows kiosk-mode feature request to me)

Moving to RHEL and removing futurefeature as document clearly states intended behavior or the doc is incorrect.

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

moved it to RFE. This bug contains dependencies, and I suggest using it as the tracker to address the c-a-d issues.

our current proposal is to remove CAD and replace it with optional mapping to Ctrl-Alt-End, regardless the client platform you'd be using CAE as a "send CAD to the guest"

adding rfe for implementing control-alt-end support in the engine.

fixing 1029441 fixes this bug too.

*** This bug has been marked as a duplicate of bug 1029441 ***