Windows file associations are part of the solution, but the browser still prompts about opening the .vv file by default. 

Even if we have the ability to change browser behavior, I don't like getting rid of the prompt because it breaks browser security best practice.  When a user right-clicks in the RHEV admin portal to open a console, he launches virt-viewer with instructions to open the associated .vv file.  From the browser point of view, it's no different than opening a document with, say, MS Word, or opening a .zip file, and the best security practice is to always prompt the user about opening files associated with any app.  

The deeper issue, and something we should fix is, making it easy to install virt-viewer on the client system.  Virt-viewer is the name of the SPICE client.  Right now, to install virt-viewer, the user must right-click on the VM, select "Console Options," and then go to "Console Client Resources" at the bottom of the popup window, and from that browser window, make a decision and select an appropriate choice.  

We can make this navigation simpler - right-click on the virtual machine and one of the menu choices should be to install the SPICE console client.  That could lead to a popup with an explanation about the browser will prompt to run the .vv file when launching a console, with a continue button to install virt-viewer.

Can we do something simple like this during the 3.6 livecycle?

- Greg

1. Why we are talking about windows only? It is the same problem on Fedora (or other OS probably) as well. Recently, we had a case when the package installed, but it was not automatically associated with the vv file and required manual association in the browser.

2. So, the question is how to make the browser to be aware of .vv file and provide the association. Not exactly my expertise on how to make it done. What sounds reasonable to me: RHV should perform the action once we click on the console button on the portal. It should check whether the vv file has associated with remote-viewer yet or not. And if not - associate it. At the same time, it might be possible that the viewer is not installed and we should prompt the user to install it right there. 
The biggest problem right now is that it just opens a vv file and the end user has zero knowledge what to do next. This is wrong. We should ideally install and associate, or provide direct instruction. Right there.

I hope this helps.

(In reply to Marina from comment #12)
> 1. Why we are talking about windows only? It is the same problem on Fedora
> (or other OS probably) as well. Recently, we had a case when the package
> installed, but it was not automatically associated with the vv file and
> required manual association in the browser.
> 

That will always be the case, as every browser handles this differently. So either the ones delivering the software within the company need to ship the "desired" configuration, or it needs to be done manually the first time the browser is used for this purpose.

> 2. So, the question is how to make the browser to be aware of .vv file and
> provide the association. Not exactly my expertise on how to make it done.
> What sounds reasonable to me: RHV should perform the action once we click on
> the console button on the portal. It should check whether the vv file has
> associated with remote-viewer yet or not. And if not - associate it. At the
> same time, it might be possible that the viewer is not installed and we
> should prompt the user to install it right there. 
> The biggest problem right now is that it just opens a vv file and the end
> user has zero knowledge what to do next. This is wrong. We should ideally
> install and associate, or provide direct instruction. Right there.

If there would just be one browser out there, I believe this would be possible. Unfortunately there are tons out there and there is no central approach to associate the downloaded files with a software.
Unfortunately this has to be done by the user or the admin who is responsible for the Browser configuration.

Let's assume we do it for Firefox. The next user is using Chrome, or Safari will still not have that association.
Handling all possible browesers is not feasible here as well.

The only "help" I can think of is providing some text that the .vv file needs to be associated with the appropriate program (even there are more than one, but typically this will be remote-viewer).


> 
> I hope this helps.

(In reply to Marina from comment #12)
> 1. Why we are talking about windows only? It is the same problem on Fedora
> (or other OS probably) as well. Recently, we had a case when the package
> installed, but it was not automatically associated with the vv file and
> required manual association in the browser.
> 
> 2. So, the question is how to make the browser to be aware of .vv file and
> provide the association. Not exactly my expertise on how to make it done.
> What sounds reasonable to me: RHV should perform the action once we click on
> the console button on the portal. It should check whether the vv file has
> associated with remote-viewer yet or not. And if not - associate it. At the
> same time, it might be possible that the viewer is not installed and we
> should prompt the user to install it right there. 
> The biggest problem right now is that it just opens a vv file and the end
> user has zero knowledge what to do next. This is wrong. We should ideally
> install and associate, or provide direct instruction. Right there.

Marina, it's not fully clear to me what you mean exactly by "association". Do you mean that the browser should automatically open .vv files with remote-viewer without any prompts? Or is it enough to have the browser show a prompt to save the file, or open it with remote-viewer? (which you say was not working in 1.)

As of today, remote-viewer should be "associated" with .vv file both on Linux and Windows in the sense that the web browser prompt will suggest to either save the file, or open it with remote-viewer. If this is not working, this is a bug that we should fix.

Getting rid of that prompt altogether might not be easy as others have already said in the bug, and maybe not even desirable from a security point of view.

Then I've seen mentions in that bug of UI/doc improvements which could be made on the RHV side of things, if that's needed too, I'd suggest opening separate bugs rather than talking about multiple different things at once in that bug.

(In reply to Christophe Fergeau from comment #14)
> (In reply to Marina from comment #12)
> > 1. Why we are talking about windows only? It is the same problem on Fedora
> > (or other OS probably) as well. Recently, we had a case when the package
> > installed, but it was not automatically associated with the vv file and
> > required manual association in the browser.
> > 
> > 2. So, the question is how to make the browser to be aware of .vv file and
> > provide the association. Not exactly my expertise on how to make it done.
> > What sounds reasonable to me: RHV should perform the action once we click on
> > the console button on the portal. It should check whether the vv file has
> > associated with remote-viewer yet or not. And if not - associate it. At the
> > same time, it might be possible that the viewer is not installed and we
> > should prompt the user to install it right there. 
> > The biggest problem right now is that it just opens a vv file and the end
> > user has zero knowledge what to do next. This is wrong. We should ideally
> > install and associate, or provide direct instruction. Right there.
> 
> Marina, it's not fully clear to me what you mean exactly by "association".
> Do you mean that the browser should automatically open .vv files with
> remote-viewer without any prompts? Or is it enough to have the browser show
> a prompt to save the file, or open it with remote-viewer? (which you say was
> not working in 1.)
Yes. This.
The browser(or whatever else) should detect the software installed and associate the vv file with it. If the relevant software is not yet installed, we need to inform the user what should be their next step.
> 
> As of today, remote-viewer should be "associated" with .vv file both on
> Linux and Windows in the sense that the web browser prompt will suggest to
> either save the file, or open it with remote-viewer. If this is not working,
> this is a bug that we should fix.
> 
> Getting rid of that prompt altogether might not be easy as others have
> already said in the bug, and maybe not even desirable from a security point
> of view.
> 
> Then I've seen mentions in that bug of UI/doc improvements which could be
> made on the RHV side of things, if that's needed too, I'd suggest opening
> separate bugs rather than talking about multiple different things at once in
> that bug.