Also a problem in M63: 63.0.3239.11, 10032.7.0, Eve

+Dominic, any chance you could look into this? 

 Issue 678313  has been merged into this issue.

Google Chrome 63.0.3239.26 (Official Build) beta (64-bit)
Firmware Version Google_Samus.6300.174.0

I also experience this when the network fluctuates between weak, medium, and strong signals.
ChromeVox indicates that the message can be dismissed, but I do not get an indication of how I can reach the notification to close it. I thought perhaps this would stop the messages about wireless.

When these notifications occur alongside the online-offline notifications from G-Suite, it is impossible for me to use my Chromebook effectively. 

Workaround:
Use an ethernet connection and turn wi-fi off.

Does anyone have a sense of whether the announcement is a bug, or just stealing focus is a bug?

Is wireless connecting/disconnecting in a particular version more than before? Or is it always flaky and the only bug is ChromeVox focus?

I'd guess the stealing focus is the bug. If the wifi connection status is changing (ie. signal is weak or bouncing between APs) notifications make sense, but it seems really broken for them to steal focus.

If your signal strength is changing frequently (but still connected; you haven't lost internet) it's very frustrating to use a chromebook that tells you about the signal change a few times a minute.  Even if it stops stealing focus, the announcement interval should be less frequent.

Network a11y alert is fired in NetworkTrayView::UpdateConnectionStatus [1]. Maybe we should throttle it instead of on every network state change.

[1] https://cs.chromium.org/chromium/src/ash/system/network/tray_network.cc?rcl=62a209c44d63af015bfd7b2bccb3ec37b08686e3&l=158

So, it sounds like there are multiple issues here:

1. WiFi shouldn't be disconnecting and reconnecting that frequently. That may be a Shill issue.
2. Chrome should probably be resiliant to brief reconnect gliches and not show a notification in this case (or, it should automatially dismiss the notification once a connection is re-established).
3. Notifications should not steal focus.

If someone can reproduce this and file a feedback report (and provide a link or reference this issue so we can find it), that would be super helpful.

This behavior should not be new to 63, so it would also be helpful to know wheter or not it's a recent regression.

Any updates? M63 goes stable in < 2 weeks and this is marked as a blocker.

This is still reproducing in Chrome OS Canary. It is very disruptive to the screen reader experience. 


ChromeOS Version 64.0.3274.0 (Official Build) canary (64-bit)
Firmware Version Google_Samus.6300.174.0

@c11 and c12, the issue is that every signal change for the *same* network gets reported; so, on a network where you are on the edge between medium and strong, you'll hear the alert every single time it slips.

The fix is probably to just announce initial connection and actual disconnection.

Correcting title (not related to focus).

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/64e122871702a6009286680a7af88031ffce7517

commit 64e122871702a6009286680a7af88031ffce7517
Author: David Tseng <dtseng@chromium.org>
Date: Wed Nov 29 04:20:12 2017

Only notify accessibility about important network changes

observer methods, but only accessibility notification for default network
changes. Verify no accessibility notification for signal strength changes.

Test: connect to wifi. Verify (through logging) trigger of network change
Bug:  775566 
Change-Id: I5ebd4e0b05e0623df1735e8df2fbfde07bd79b25
Reviewed-on: https://chromium-review.googlesource.com/794305
Commit-Queue: David Tseng <dtseng@chromium.org>
Reviewed-by: Steven Bennetts <stevenjb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#519999}
[modify] https://crrev.com/64e122871702a6009286680a7af88031ffce7517/ash/system/network/tray_network.cc
[modify] https://crrev.com/64e122871702a6009286680a7af88031ffce7517/ash/system/network/tray_network.h
[modify] https://crrev.com/64e122871702a6009286680a7af88031ffce7517/ash/system/network/tray_network_state_observer.cc
[modify] https://crrev.com/64e122871702a6009286680a7af88031ffce7517/ash/system/network/tray_network_state_observer.h
[modify] https://crrev.com/64e122871702a6009286680a7af88031ffce7517/ash/system/network/tray_vpn.cc
[modify] https://crrev.com/64e122871702a6009286680a7af88031ffce7517/ash/system/network/tray_vpn.h

Are more cl's expected to land or can we mark this as fixed?

David, could you please verify? Thanks!

[Auto-generated comment by a script] We noticed that this issue is targeted for M-63; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-63 label, otherwise remove Merge-TBD label. Thanks.

Version 65.0.3286.0 (Official Build) canary (64-bit)(
Firmware Version Google_Samus.6300.174.0

Alerts are not produced for signal changes, but are irregular for connection and disconnection.

Steps to repro:
# Turn WIFI off
# Turn WIFI on
# Notice there is no alert about connection state
# Connect to a different network
# Reconnect to the same network
# Connect via ethernet
# Disconnect ethernet
# Notice there is always an alert when switching to and from ethernet

Expected: Connect and disconnect due to wireless on/off should always alert. Connect due to user choosing a network should alert
Disconnect due to user disconnect should alert
Connect due to system start/wake should alert

Actual: Connect and disconnect alerts are fired 50% of the time

Now that the alerts are no longer interfeering with daily use, I am lowering the priority of this bug.

Removing merge labels already merged) and original issue fixed. Keeping around for minor issues remaining.