Created attachment 494633 [details] Screenshot of gnome-shell NM UI directly after boot Hi, I noticed in NetworkManager update in yesterdays new packages with the following changelog: NetworkManager-0.8.998-3.git20110419.fc15 ----------------------------------------- * Tue Apr 19 2011 Dan Williams <dcbw> - 0.8.998-3.git20110419 - core: systemd and startup enhancements for NFS mounts - core: more efficient startup process - core: fix handling of multiple logins when one is inactive - core: fix handling of S390/Hercules CTC network interfaces (rh #641986) - core: support Easytether interfaces for Android phones - core: fix handling of WWAN enable/disable states - ifcfg-rh: harmonize handling if IPADDR/PREFIX/NETMASK with initscripts (rh #658907) - applet: fix connection to WPA Enterprise networks (rh #694765) The "core: fix handling of WWAN enable/disable states" triggered me to do some testing with the integrated wwan card in my laptop, since I was not completely happy with how this worked before. Below are my findings of this testing, which show some things which are IMHO ui inconsistencies / weirdness-es leading to a less then perfect experience :) When I boot up the laptop the wwan on/off toggle in the shell NM UI is set to off, and a single entry gets shown titled "T-Mobile default" which is the wwan connection which I created in the gnome-2 days, this is Screenshot.png When I press the on/off toggle, unlike before it now actually moves to the on position, and a second entry appears "T-Mobile NL" which has a signal strength indicator. Having 2 entries here is a bit weird, as T-Mobile is my provider, and only connection, see Screenshot-2.png In order to try and keep some order in this bug report, I'm going to title and number the issues which I believe are present in the current UI. This is issue 1 "2 entries for one and the same wwan connection" Clicking on the "T-Mobile NL" entry does nothing: issue 2 "Clicking on the "T-mobile NL" entry does nothing" Clicking on the "T-Mobile default" entry results in a wwan connection activating, once it is activated the "T-Mobile NL" entry is gone and I no longer have a signal strength indicator inside the drop down menu, see Screenshot-3.png. Issue 3: "T-Mobile NL entry disappears after connecting to T-mobile default" Issue 4: "No signal strength indicator in drop down when connected" Switching the on/off toggle for wwan back to off results in the UI returning back to the original Screenshot.png . When in this state one can directly click on "T-mobile default" at which point a connection can be made, but the on/off toggle does not turn on. To disconnect one now needs to click the on/off toggle twice, once to get it to on, and once to actually turn it off. Screenshot-3.png. Issue 5: "When connecting to wwan without first turning it on, the on/off toggle stays at off and needs to be clicked twice to disconnect / actually get it off" While running some more tests I also hit a case where the on/off toggle was off, the wwan was connected (bullet next to "T-Mobile default") and the "T-Mobile NL" entry with signal strength was also present. I don't have a screenshot of this. At this point it clearly was confused, trying to toggle the on/off to on (to actually turn it off) resulted in the on/off toggle changing to connecting even though it already was connected.,. Screenshot-4.png
Created attachment 494634 [details] Screenshot of gnome-shell NM UI after turning on/off toggle to on
Created attachment 494635 [details] Screenshot of gnome-shell NM UI after connecting to wwan
Created attachment 494636 [details] Screenshot of gnome-shell NM UI after connecting to wwan with on/off toggle in off position
Created attachment 494638 [details] Screenshot of gnome-shell NM UI in confused state (connecting while already connected)
(In reply to comment #0) > The "core: fix handling of WWAN enable/disable states" triggered me to do some > testing with the integrated wwan card in my laptop, since I was not completely > happy with how this worked before. Note that the majority of the WWAN-handling bugs were on the gnome-shell side, so it's not expected that they'd be fixed with just the NM update and no gnome-shell 3.0.1 (which doesn't exist yet). > When I press the on/off toggle, unlike before it now actually moves to the on > position, and a second entry appears "T-Mobile NL" which has a signal strength > indicator. Having 2 entries here is a bit weird, as T-Mobile is my provider, > and only connection, see Screenshot-2.png The double entries are fixed with current gnome-shell > Issue 4: "No signal strength indicator in drop down when connected" Yeah... not sure where that went. I wonder if something else changed in NM. > Issue 5: "When connecting to wwan without first turning it on, the on/off > toggle stays at off and needs to be clicked twice to disconnect / actually get > it off" and > While running some more tests I also hit a case where the on/off toggle was > off, the wwan was connected are both caused by the shell doing things to deal with the fact that the WWAN switch used to be broken at the NM level.
I just updated to gnome-shell-3.0.1 but not much has changed, the only difference is that when wwan is in the on state (or in the connected but the on/off toggle still showing off bug state) I now always get 2 wwan entries in the applet: 1) Network operator name + signal strength indicator 2) Connection name as created / shown in nm-connection-editor I'm not sure if this counts as a bug, but it sure feels weird, esp. since the " Network operator name + signal strength indicator" item is never clickable. When the on/off toggle is off, only 2) gets shown, and clicking it activates the link, but does not change the toggle (as before).
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping