[gnome-shell] Fix connection to wifi APs from user menu (RH #1628263)

[Jonas Ådahl <jadahl src gnome org>]

commit 33ffdd60611e8e8d0018680dd97bcbd0e98c6b4b
Author: Adam Williamson <awilliam redhat com>
Date:   Tue Sep 18 16:05:42 2018 -0700

    Fix connection to wifi APs from user menu (RH #1628263)
    
    In recent Fedora 29, connecting to wifi access points from the
    user menu (top-right menu) does not work. Clicking the 'Connect'
    button just animates it but does nothing else. The logs show an
    error "JS ERROR: Error: Expected type utf8 for Argument
    'specific_object' but got type 'undefined'".
    
    Looking into this, it seems the problem is these uses of the
    `path` property of an NMAccessPoint. NMAccessPoint inherits
    from NMObject, and NMObject *does* have a path property:
    
    https://developer.gnome.org/libnm/stable/NMObject.html#NMObject--path
    
    so at first glance this seems fine. But I poked around a bit
    using libnm via Python (which goes via introspection, just like
    this JS code does), and found that indeed AccessPoint objects
    don't seem to have a `path` property there either.
    
    Looking at the libnm code, this actually makes sense, because
    the property is marked "(skip)":
    
    https://github.com/NetworkManager/NetworkManager/blob/master/libnm/nm-object.c#L1291
    
    and the introspection docs suggest that means it should be left
    out of introspected output:
    
    https://wiki.gnome.org/Projects/GObjectIntrospection/Annotations#Symbol_visibility
    
    I'm a bit concerned that this was only found recently - whereas
    the change to use `.path` in gnome-shell dates from October 2017
    (d71af5e5) and the property has been marked (skip) in NM since
    at least 2016 - but this all seems to add up. The obvious fix is
    to replace use of `.path` with `.get_path()`, which returns the
    path and is *not* marked (skip) and so *is* available via
    introspection. I tested that this works in Python and also did
    a test build of gnome-shell with this change and installed it on
    an affected system, it does seem to fix the bug.
    
    Signed-off-by: Adam Williamson <awilliam redhat com>

 js/ui/status/network.js | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
---
diff --git a/js/ui/status/network.js b/js/ui/status/network.js
index b575a726d..d5567dc3c 100644
--- a/js/ui/status/network.js
+++ b/js/ui/status/network.js
@@ -921,10 +921,10 @@ var NMWirelessDialog = new Lang.Class({
                 // 802.1x-enabled APs require further configuration, so they're
                 // handled in gnome-control-center
                 Util.spawn(['gnome-control-center', 'wifi', 'connect-8021x-wifi',
-                            this._device.get_path(), accessPoints[0].path]);
+                            this._device.get_path(), accessPoints[0].get_path()]);
             } else {
                 let connection = new NM.SimpleConnection();
-                this._client.add_and_activate_connection_async(connection, this._device, 
accessPoints[0].path, null, null)
+                this._client.add_and_activate_connection_async(connection, this._device, 
accessPoints[0].get_path(), null, null)
             }
         }