System tray network icon and network feature pod icon should indicate the current default network even if another network is connecting |
|||||
Issue descriptionCurrently, default network icons in system tray and quick settings will show connecting icon if a network is being connected after user requested connection, or when a network is being reconnected. The connecting icon will be shown even if there is currently a connected network - the goal being to give the user an indication that a network is being connected (especially after they requested it) Though, showing a connecting icon in these cases does not give the user correct view of the current networking state. The device has network connectivity, though, over different network interface - showing a connecting icon might give impression that this is not the case. Also, depending on which of the available networks is default in connected state, we might observe the following confusing situations: * non-default network starts reconnecting (or user requests the connection) - a connecting icon is shown for that network until the network actually gets connected, at which point the default network icon is shown again (or no network icon if the default network is Ethernet) * default network start reconnecting - connecting icon is shown, even though the other connected network is considered default by shill at that point. When the network gets connected, but is not yet online, the other network icon flashes (as that's still the default icon according to shill). When the reconnecting network state changes to online, and the network becomes default, the icon changes again. It might be better to simplify the logic of selecting the network icon to show to the user, and always show current default network. (if a network is connecting, we'd still show a connecting icon if no other network is connected).
,
Dec 20
+sgbariel@ also. Historically we intentionally prioritize connecting networks in the tray to show that we are connecting to a WiFi network, even when connected to Ethernet or Cellular.
,
Dec 22
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2ea3698e58931720975793ca370a29ff6336bb25 commit 2ea3698e58931720975793ca370a29ff6336bb25 Author: Steven Bennetts <stevenjb@chromium.org> Date: Sat Dec 22 01:22:42 2018 Improve fake Shill clients This CL: * Fixes the sorting algorithim in FakeShillManagerClient to (mostly) match the Shill sorting. * Fixes the service client to set 'Connectable' and 'PassphraseRequired' properties appropriately. * Clang formats the fake client code. Bug: 917097 Change-Id: Ib3e834939168406a37b48af978dea041dae928aa Reviewed-on: https://chromium-review.googlesource.com/c/1388917 Reviewed-by: Toni Baržić <tbarzic@chromium.org> Commit-Queue: Steven Bennetts <stevenjb@chromium.org> Cr-Commit-Position: refs/heads/master@{#618703} [modify] https://crrev.com/2ea3698e58931720975793ca370a29ff6336bb25/chrome/test/data/extensions/api_test/networking_private/chromeos/test.js [modify] https://crrev.com/2ea3698e58931720975793ca370a29ff6336bb25/chromeos/dbus/fake_shill_manager_client.cc [modify] https://crrev.com/2ea3698e58931720975793ca370a29ff6336bb25/chromeos/dbus/fake_shill_service_client.cc [modify] https://crrev.com/2ea3698e58931720975793ca370a29ff6336bb25/chromeos/network/managed_network_configuration_handler_unittest.cc [modify] https://crrev.com/2ea3698e58931720975793ca370a29ff6336bb25/chromeos/network/shill_property_handler_unittest.cc [modify] https://crrev.com/2ea3698e58931720975793ca370a29ff6336bb25/chromeos/test/data/network/policy/shill_managed_wifi1.json [modify] https://crrev.com/2ea3698e58931720975793ca370a29ff6336bb25/chromeos/test/data/network/policy/shill_policy_autoconnect_on_unconfigured_wifi1.json [modify] https://crrev.com/2ea3698e58931720975793ca370a29ff6336bb25/chromeos/test/data/network/policy/shill_policy_on_unconfigured_wifi1.json [modify] https://crrev.com/2ea3698e58931720975793ca370a29ff6336bb25/chromeos/test/data/network/policy/shill_policy_on_unmanaged_wifi1.json [modify] https://crrev.com/2ea3698e58931720975793ca370a29ff6336bb25/chromeos/test/data/network/policy/shill_unmanaged_wifi1.json [modify] https://crrev.com/2ea3698e58931720975793ca370a29ff6336bb25/chromeos/test/data/network/policy/shill_unmanaged_wifi2.json
,
Dec 22
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/fcaaa38870a8c7bcd47aa0bd8aa0a02c73cf33b7 commit fcaaa38870a8c7bcd47aa0bd8aa0a02c73cf33b7 Author: Steven Bennetts <stevenjb@chromium.org> Date: Sat Dec 22 20:49:31 2018 Fix NetworkStateHandler logic for ordering mobile networks Currently Cellular networks are always listed between active networks and non active networks. The desired behavior is to preserve ordering for active networks, since a Cellular network may be prioritized over a portaled wifi network, and list inactive mobile networks before inactive wifi networks (since there will usually only be 1-2). This also updates the logic to ensure a default cellular network. Bug: 917097 Change-Id: I9d82e1d418853080b5c46014577228f1af5c86c8 Reviewed-on: https://chromium-review.googlesource.com/c/1388922 Commit-Queue: Steven Bennetts <stevenjb@chromium.org> Reviewed-by: Toni Baržić <tbarzic@chromium.org> Cr-Commit-Position: refs/heads/master@{#618764} [modify] https://crrev.com/fcaaa38870a8c7bcd47aa0bd8aa0a02c73cf33b7/chromeos/network/network_state_handler.cc [modify] https://crrev.com/fcaaa38870a8c7bcd47aa0bd8aa0a02c73cf33b7/chromeos/network/network_state_handler.h
,
Jan 15
,
Jan 15
Is this bug fixed, and will this fix https://bugs.chromium.org/p/chromium/issues/detail?id=873852?
,
Jan 15
not really - we still show connecting wifi icon over default network (lte) icon if a wifi connection was request with LTE connected. Though, these cls should fix UI issues where a connected wifi icon is always shown over cellular icon, regardless of whether the wifi icon is online or not. (so, with a connected LTE and a wifi in captive portal, UI will now show cellular icon as default)
,
Jan 15
Gotcha, thanks.
,
Jan 15
FWIW, I think that the reasoning behind showing a connecting icon over a connected icon is still valid (it gives the user a warning that the state may change), and that we should wait for the more thorough redesign (with multiple icons) to consider changing that logic. i.e. I would close this since the obvious bug has been fixed and open another issue associated with the redesign feature work.
,
Jan 15
well, I did open this bug to figure out whether we should change the current logic of showing connecting network over connected one :) (and the cls linked to this issue should have probably been linked to issue 916669 , sorry for not catching that in the review)
,
Jan 15
Ah, that's fair. We should maybe change this from a bug to a feature then :)
,
Today
(6 hours ago)
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by tbarzic@chromium.org
, Dec 20