New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 819948 link

Starred by 2 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

Non-Regression : 'Wi-Fi turned off' Icon is seen for few sec at Uber Tray after recovering build

Project Member Reported by mmanchala@chromium.org, Mar 8 2018

Issue description

Chrome Version: 65.0.3325.148/ 10323.52.0 beta channel  Kip,Reks and Daisy
OS: Chrome

What steps will reproduce the problem?
(1)Recover build ->After welcome screen immediately observe 'Wi-Fi' turned off Icon at Uber Tray in OOBE screen
(2)Click on Uber Tray -> Select network and observe 'Wi-Fi is turned off' text 
(Please refer Video and Screenshot)

Note:
1)After few seconds Wi-Fi is turned on automatically 
2)In M-61 after welcome screen in OOBE screen observed 'Wi-Fi' turned on Icon at Uber Tray(Please refer 'Expected_Icon' Video)
3)Issue is seen on M-63,M-64,M-66 and on latest M-67

Expected:  'Wi-Fi turned on' Icon should be seen at Uber Tray immediately after welcome screen even searching for Wi-Fi networks

Actual: Instead 'Wi-Fi turned off' Icon is seen for few seconds and then automatically Wi-Fi is turned on

This is Non-Regression Issue seen from M-62

@tbuckley: Please confirm the Issue
 
Actual_WiFiTurnedOffIcon.mp4
8.5 MB View Download
Actual_WiFiTurnedOffIcon.jpg
174 KB View Download
Expected_WiFiTurnedOnIcon.jpg
290 KB View Download
Expected_WiFiTurnedOnIcon.mp4
8.9 MB View Download
Cc: tbuck...@chromium.org cernekee@chromium.org
Components: -UI>Shell>OOBE -UI>Shell>StatusArea OS>Systems>Network
Labels: -M-65 M-66 Needs-Feedback
Owner: ----
Status: Untriaged (was: Assigned)
This sounds like either Shill is taking longer to start up, or Chrome is taking longer to initiate the DBus conenction to Shill.

Can you login in and file a feedback report so that we can look at the logs?

This doesn't seem urgent enough to fix in 65 which is already in stable, changing the milestone to 66.

Cc: kirtika@chromium.org
I think we had another bug that said: waiting for the udev trigger causes shill to take way too long to start up (a regression).

This sounds different since it isn't caused by our recent changes.  But it may be related.  Perhaps there are a few reasons why shill might take too long to start up.
Labels: -Needs-Feedback
C#1>

I filed a feedback report and can be found at 
https://listnr.corp.google.com/product/208/report/85451050500?dateRange=All

Thanks..!!
Labels: Enterprise-Triaged

Sign in to add a comment