Can you apply this patch and see what transpires ?

diff --git a/gtk/gtkplacessidebar.c b/gtk/gtkplacessidebar.c
index f767e14..177e72a 100644
--- a/gtk/gtkplacessidebar.c
+++ b/gtk/gtkplacessidebar.c
@@ -4938,6 +4938,7 @@ gtk_places_sidebar_set_location (GtkPlacesSidebar *sidebar,
                           -1);
       if (iter_uri != NULL)
         {
+          g_print ("set location: comparing %s and %s\n", iter_uri, uri);
           if (strcmp (iter_uri, uri) == 0)
             {
               g_free (iter_uri);

set location: comparing recent:/// and file:///C:/regression/data/gates/recent:
set location: comparing file:///C:/msys2/home/draymond and file:///C:/regression/data/gates/recent:
set location: comparing file:///C:/Users/draymond/Desktop and file:///C:/regression/data/gates/recent:
set location: comparing file:///C:/Users/draymond/Documents and file:///C:/regression/data/gates/recent:
set location: comparing file:///C:/Users/draymond/Downloads and file:///C:/regression/data/gates/recent:
set location: comparing file:///C:/Users/draymond/Music and file:///C:/regression/data/gates/recent:
set location: comparing file:///C:/Users/draymond/Pictures and file:///C:/regression/data/gates/recent:
set location: comparing file:///C:/Users/draymond/Videos and file:///C:/regression/data/gates/recent:
set location: comparing file:/// and file:///C:/regression/data/gates/recent:
set location: comparing file:///Z:/ and file:///C:/regression/data/gates/recent:
set location: comparing file:///H:/ and file:///C:/regression/data/gates/recent:
set location: comparing file:///D:/ and file:///C:/regression/data/gates/recent:
set location: comparing file:///C:/ and file:///C:/regression/data/gates/recent:
set location: comparing file:///C:/regression/data/gates and file:///C:/regression/data/gates/recent:

thanks, this explains it:

set location: comparing recent:/// and file:///C:/regression/data/gates/recent:

So, g_file_new ("recent:///") does not work as expected if gvfs does not support the recent scheme

This bug still exists in 3.22.7.

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

Dear Daniel Boles, please stop marking my tickets as resolved/duplicate.  How can this be a duplicate of a bug report that was filed 9 months after this one?  If the issue is not fixed don't mark the bug report as resolved.

same reason as last time: the other bug describes almost certainly the same problem, but with more info, so the relative points in time at which they were posted doesn't matter.

most people don't feel the need to have their own personal copy of every bug they've ever encountered, but sure, keep it if you really want.

bugzilla is a tool for us, the developers. Your contribution is appreciated, but you don't get any ownership stake in the bugs you report. GTK+ has 2700+ open bugs. It is important for us to not make the pile unnecessarily bigger by keeping duplicates or near-duplicates or wontfixes open.

Matthias we are both developers and I think we both appreciate the purpose of a bug tracking system.  Generally you don't mark a bug as duplicate unless you understand the root cause (and hence have a fix that resolves both bug reports).

Please confirm whether the fix at https://bugzilla.gnome.org/show_bug.cgi?id=763517#c29 addresses this.

As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla.

If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab:

https://gitlab.gnome.org/GNOME/gtk/issues/new