Correction to the comment #0:

Running the command "xdg-open console.vv", seems to do something different depending whether you have run it before.  On the first run, it does nothing.  On the second run, it invokes gedit.  On odd-numbered runs, it does nothing.  On even-numbered runs, it invokes gedit.

This is caused by changes in glib between 2.40 and 2.42. 2.40 launches remote-viewer as expected. I believe this is a consequence of https://bugzilla.redhat.com/show_bug.cgi?id=1175719.
xdg-open when run in a GNOME DE will end up starting gvfs-open file:///...

What happens is the following:
- application/x-virt-viewer is a subclass of text/plain
- remote-viewer.desktop has MimeType=application/x-virt-viewer

After installing the virt-viewer package, update-mime-database is run which causes /usr/share/applications/mimeinfo.cache to contain:

application/x-virt-viewer=remote-viewer.desktop;

remote-viewer.desktop is not listed in /usr/share/applications/defaults.list nor any file defining the default mime type handlers.


When running 
"xdg-mime query default application/x-virt-viewer"
xdg-mime ends up doing
grep application/x-virt-viewer= /usr/share/applications/defaults.list /usr/share/applications/mimeinfo.cache

so it returns remote-viewer.desktop.


gvfs-info 2.42 on the other hand looks for application/x-virt-viewer in the files containing default file associations (/usr/share/applications/mimeinfo.cache is not such a file). Since it can't find application/x-virt-viewer there, it then tries to look for text/plain in one of the default file lists, and finds gedit. This logic in implemented in g_desktop_app_info_get_defaults_for_content_type().

If application/x-virt-viewer is not defined as being a subtype of text/plain, then g_desktop_app_info_get_defaults_for_content_type() will not find any match for application/x-virt-viewer, and g_app_info_get_default_for_type() will properly fallback to looking in /usr/share/applications/mimeinfo.cache.

(In reply to Christophe Fergeau from comment #2)
> This is caused by changes in glib between 2.40 and 2.42. 2.40 launches
> remote-viewer as expected. I believe this is a consequence of
> https://bugzilla.redhat.com/show_bug.cgi?id=1175719.

Correct URL is https://bugzilla.gnome.org/show_bug.cgi?id=728040

(In reply to Aram Agajanian from comment #0)
> Running the command "xdg-open console.vv", seems to do something different
> depending whether you have run it before.  On the first run, it does
> nothing.  On the second run, it invokes gedit.  On odd-numbered runs, it
> does nothing.  On even-numbered runs, it invokes remote-viewer.
> 

This behaviour is also happening with text files, and does not happen with other applications (evince, eog). First run seems to start gedit --gapplication-service without opening a window showing the document, second attempt opens the document.

(In reply to Christophe Fergeau from comment #4)
> This behaviour is also happening with text files, and does not happen with
> other applications (evince, eog). First run seems to start gedit
> --gapplication-service without opening a window showing the document, second
> attempt opens the document.

Actually, seems to be a gio issue.
In the non-working case, running
G_DBUS_DEBUG=message gvfs-open /home/teuf/redhat/console.vv
shows
========================================================================
GDBus-debug:Message:
  >>>> SENT D-Bus message (192 bytes)
  Type:    method-call
  Flags:   no-reply-expected
  Version: 0
  Serial:  9
  Headers:
    path -> objectpath '/org/gnome/gedit'
    interface -> 'org.freedesktop.Application'
    member -> 'Open'
    destination -> 'org.gnome.gedit'
    signature -> signature 'asa{sv}'
  Body: (['file:///home/teuf/redhat/console.vv'], @a{sv} {})
  UNIX File Descriptors:
    (none)

but a
dbus-monitor "interface='org.freedesktop.Application'"
running in parallel will not match any 'Open' call.

In the working case, dbus-monitor will show:

method call sender=:1.1045 -> dest=org.gnome.gedit serial=9 path=/org/gnome/gedit; interface=org.freedesktop.Application; member=Open
   array [
      string "file:///home/teuf/redhat/console.vv"
   ]
   array [
   ]

Adding a g_usleep(2*G_USEC_PER_SEC); in g_desktop_app_info_launch_uris_internal after the calls to g_desktop_app_info_launch_uris_* makes it work every time, so it would seem we exit too quickly or something like that?

I've got similar issues when trying to open log file:
xdg-open wb.log
The wb.log file is just plain text file

You'd have to be more specific about what is "a similar issue" here as I'd expect wb.log to open in gedit.
This bug is still filed against virt-viewer, the upstream bug ( https://bugzilla.gnome.org/show_bug.cgi?id=744282 ) would probably be a better place to track this.

I created a bug upstream that I felt actually described the breadth of the issue which appears to relate to relate to all calls to gvfs-open and by extension xdg-open in gnome al long as the target application is not running. 

https://bugzilla.gnome.org/show_bug.cgi?id=746534

(In reply to Christophe Fergeau from comment #5)
> (In reply to Christophe Fergeau from comment #4)
> > This behaviour is also happening with text files, and does not happen with
> > other applications (evince, eog). First run seems to start gedit
> > --gapplication-service without opening a window showing the document, second
> > attempt opens the document.
> 
> Actually, seems to be a gio issue.

This is https://bugzilla.redhat.com/show_bug.cgi?id=1175719#c5

https://bugzilla.gnome.org/show_bug.cgi?id=744282 is now fixed and should make it to fedora 22.

This was fixed in glib 2.44.1 which is available in fedora-updates. https://bugzilla.gnome.org/show_bug.cgi?id=746534 has also been fixed upstream, but will most likely only make it to glib 2.46 (ie f23)