Fix connecting to wifi from user menu (RHBZ #1628263)

This commit is contained in:
Adam Williamson 2018-09-18 16:37:04 -07:00
parent f03be9edd3
commit 083ac56809
2 changed files with 75 additions and 1 deletions

View File

@ -0,0 +1,67 @@
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

View File

@ -1,6 +1,6 @@
Name: gnome-shell
Version: 3.30.0
Release: 3%{?dist}
Release: 4%{?dist}
Summary: Window management and application launching for GNOME
Group: User Interface/Desktops
@ -16,6 +16,10 @@ Patch1: gnome-shell-favourite-apps-firefox.patch
# Backport fix for https://gitlab.gnome.org/GNOME/gnome-shell/issues/140
Patch2: 0001-network-Don-t-assume-the-active-connection-has-been-.patch
# Fixes connecting to wifi from user menu
# https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/240
Patch3: 0001-Fix-connection-to-wifi-APs-from-user-menu-RH-1628263.patch
%define libcroco_version 0.6.8
%define eds_version 3.17.2
%define gnome_desktop_version 3.7.90
@ -211,6 +215,9 @@ glib-compile-schemas --allow-any-name %{_datadir}/glib-2.0/schemas &> /dev/null
%{_mandir}/man1/%{name}.1.gz
%changelog
* Tue Sep 18 2018 Adam Williamson <awilliam@redhat.com> - 3.30.0-4
- Fix connecting to wifi from user menu (RHBZ #1628263)
* Sat Sep 15 2018 Adam Williamson <awilliam@redhat.com> - 3.30.0-3
- Backport fix for GGO #140 from upstream master