68 lines
3.0 KiB
Diff
68 lines
3.0 KiB
Diff
From 33ffdd60611e8e8d0018680dd97bcbd0e98c6b4b Mon Sep 17 00:00:00 2001
|
|
From: Adam Williamson <awilliam@redhat.com>
|
|
Date: Tue, 18 Sep 2018 16:05:42 -0700
|
|
Subject: [PATCH] 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)
|
|
}
|
|
}
|
|
|
|
--
|
|
2.19.0
|
|
|