Bug 1386351 - Associate .vv file extension with Virt-Viewer rather then as a plain text file that gedit attempts to open.
Summary: Associate .vv file extension with Virt-Viewer rather then as a plain text fil...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: glib2
Version: 7.2
Hardware: All
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Colin Walters
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks: 1420851
TreeView+ depends on / blocked
 
Reported: 2016-10-18 17:57 UTC by Jason
Modified: 2019-12-16 07:09 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-08-06 13:56:08 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Jason 2016-10-18 17:57:26 UTC
Description of problem:

Presently RHEL systems treat .vv (virt-viewer) files as if they are plain text and thus gedit attaches automatically as the default application based on the /usr/share/applications/defaults.list because of this customers have to manually set Virt-Viewer or Remote-Viewer as the default after the system creates a temporary .vv file. This issue is very predominate in environments using RHVM and they right click on a VM and click on "Console." 

Since the .vv file should always be associated with Virt-Viewer at minimum customers would be able to benefit from having to do less steps by having .vv files properly associated with virt-viewer.

Version-Release number of selected component (if applicable):

N/a presently impacts all currently supported versions of RHEL.

How reproducible:

Everytime.

Steps to Reproduce:
1. In RHVM environment open the Manager GUI
2. Go to the VM's tab, right click on a vm and click "Console"
3. System will attempt to open the file and hang as gedit tries to launch the file instead of Virt-Viewer or Remote-Viewer.


Actual results:

You have to go to where the system downloads the .vv file, right click, properties and change the default application in this section.

Expected results:

Client should be able to complete step two above and the console launches without having to manually set the default application prior to use.

Additional info:

Comment 1 Eduardo Lima (Etrunko) 2016-10-18 18:56:51 UTC
Not sure if this is a virt-viewer bug, shouldn't this be handled by the desktop environment, in this case GNOME?

Comment 2 Eduardo Lima (Etrunko) 2016-10-18 19:06:55 UTC
I double checked the virt-viewer.spec file and it does install it's own MIME type and runs update-mime-database in post install stage.

This could also be an issue on the RHEVM side, it would be necessary to check what is the Content-Type the server sends when user clicks "Console". Even though the extension of the file is .vv, if server says its Content-type is "text/plain" I think the browser will follow up on the default application for text files.

Comment 5 Christophe Fergeau 2016-10-24 18:15:48 UTC
(In reply to Jason from comment #0)

> Steps to Reproduce:
> 1. In RHVM environment open the Manager GUI
> 2. Go to the VM's tab, right click on a vm and click "Console"
> 3. System will attempt to open the file and hang as gedit tries to launch
> the file instead of Virt-Viewer or Remote-Viewer.

The expected result is:
3. A dialog open asking me what to open the file with
4. remote-viewer can be chosen from that dialog, with a checkbox to skip the dialog from now on

This works in the (somewhat old) RHEL6 VM I tested with.

Comment 6 Eduardo Lima (Etrunko) 2016-10-26 14:33:30 UTC
I have just tested with a fresh install of RHEL 7.2 and the report is correct. The default application is indeed gedit and remote-viewer is not presented as an option in Firefox.

This has been identified as a bug in glib (https://bugzilla.gnome.org/show_bug.cgi?id=744282), which has already been fixed in recent versions. RHEL 7.2 does not have the fix for the problem, but luckily, RHEL 7.3 does ship it.

Comment 7 Christophe Fergeau 2017-03-09 07:54:25 UTC
Since 7.3 should not have this bug, shall we close this as CURRENTRELEASE?

Comment 8 Jason 2017-08-21 11:38:56 UTC
Any update to this bug?

Comment 9 Christophe Fergeau 2017-08-28 09:41:41 UTC
Just tested with a newly installed rhel7.4, and I'm getting the behaviour described in comment #5, not what is described in comment #0. I don't know if this behaviour is acceptable, or if there is more to improve.


Note You need to log in before you can comment on or make changes to this bug.