New issue
Advanced search Search tips

Issue 639307 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Feature



Sign in to add a comment

[FR] When connected to a VPN over ethernet, show icon in status area

Reported by mtreac...@gmail.com, Aug 19 2016

Issue description

UserAgent: Mozilla/5.0 (X11; CrOS x86_64 8530.49.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.55 Safari/537.36
Platform: 8530.49.0 (Official Build) beta-channel samus

Steps to reproduce the problem:
1. Connect Chrome device to internet via ethernet
2. Connect to VPN over ethernet connection
3. "Connected to ..." can only be seen when opening status area (Alt + Shift + S)

What is the expected behavior?
This is currently the expected behavior.

What went wrong?
When connected to a VPN over a wifi connection, you'll see the dots under the wifi connection at a glance. When connected to a VPN over ethernet, there is no glanceable icon. 

For this FR, an ethernet icon w/ the VPN dots would appear in the status area (bottom right). This would allow you to know/confirm you're connected to your VPN at a glance (like you can with a wifi connection).

Did this work before? N/A 

Chrome version: 53.0.2785.55  Channel: n/a
OS Version: 8530.49.0
Flash Version: Shockwave Flash 22.0 r0
 
Cc: varkha@chromium.org
Owner: tbuck...@chromium.org
Status: Assigned (was: Unconfirmed)
Cc: tbuck...@chromium.org
Owner: tdander...@chromium.org
@tdanderson with the newly component-ized MD icons, could we overlay the VPN indicator on top of the ethernet icon?
Cc: est...@chromium.org sgabr...@chromium.org steve...@chromium.org
Components: -UI UI>Shell>Networking UI>Shell>StatusArea Internals>Network>VPN
Labels: -Type-Bug Proj-MaterialDesign-CrOS Needs-Feedback Type-Feature
Yes, this should be possible - I'd imagine we would just use the VPN 'key' as the bottom-right badge on the ethernet icon.

Note however that we currently never show the ethernet icon in the system tray; it's only ever shown in the system menu. If we start showing an icon for ethernet+vpn in the tray, this may introduce a user expectation of seeing an ethernet icon in the tray even when a VPN connection is not active.

We show an icon in the status tray for all other scenarios:

(1) Connected to a WiFi network, icon possibly badged
(2) Connected to a cellular network, icon possibly badged
(3) Connecting to a WiFi network (animated icon)
(4) Cellular network being activated or initialized (animated icon)
(5) Disconnected (a 'disconnected WiFi' icon is used here)

But "connected to ethernet" is implied by the lack of an icon, which I find to be a bit counter-intuitive after thinking about it. I would be in favour of showing ethernet connectivity in the status tray (after which this feature request would be a natural follow-on) unless there are good reasons to keep things the way they are.
We used to do this, once upon a time. Specifically, we would show an icon in the status area for "Connected to Ethernet + VPN" (but not just Connected to Ethernet).

In our discussion today, we didn't feel like showing ethernet alone in the system menu is desirable since it's obvious to users (cable plugged in) and there isn't any range/strength info like with wifi or cellular.

Quickly telling whether VPN is active seems to be the goal of this bug, so I'd prefer to only show the badged ethernet icon in the status area when also using VPN.
FWIW having a cable plugged in does not always imply that you are actually connected to ethernet; the router or modem could be turned off, for instance.

Personally I still like the idea of showing the ethernet icon, but I don't feel strongly enough about it to keep the debate open if Tom and Sebastien are both on board with the proposal in #5. That approach would also be fine by me.
Owner: sgabr...@chromium.org
If the router is turned off, we won't detect an Ethernet connection and the "no network" icon will be shown.

In theory we should also detect a lack of internet connection as part of Captive Portal detection, although in practice we don't currently do a good job of that, see issue 692103.

In the past the consensus has been in agreement with the summary in comment #5.

Labels: Hotlist-Poachable

Sign in to add a comment