chrome.idle fires an active state at the lock screen in Windows 10
Reported by
breitb...@gmail.com,
Aug 7 2017
|
|||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.31 Safari/537.36 Steps to reproduce the problem: 1. Lock the screen in Windows 10 2. Stay in the actual 'lock screen' and don't change to the 'login screen' (where you are able to change users and enter the password) What is the expected behavior? chrome.idle should fire the 'locked' state. What went wrong? chrome.idle does fire the 'locked' state but it also fires immediately an 'active' event. This error doesn't occur everytime you lock the screen but at least every second time. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 60.0.3112.90 Channel: stable OS Version: 10.0 Flash Version: You can use the attached minimal extension which logs the events in the console of the background page. In the error case, you will see something like this in the logs, when you lock the screen: locked at 10:00:12 // User locked the screen active at 10:00:13 // Chrome fires immediately the active event locked at 10:00:42 // User switched to the login screen of Windows 10 active at 10:00:50 // User logged in successfully It should be: locked at 10:00:12 // User locked the screen active at 10:00:50 // User logged in successfully One additional hint: If I disable the lock screen, Windows will show the login screen right away and everything works as expected. So I suppose it is related to the 'new' lock screen.
,
Aug 8 2017
Thanks, for your fast response. I have just recheked it with canary #62.0.3179.0 and the same problem exists. As I mentioned in my report, sometimes the events are fired correctly (like your canary log). But other times not. At my test machines the error occurs approximately every second time I lock the screen.
,
Aug 8 2017
Thank you for providing more feedback. Adding requester "brajkumar@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 4 2017
Do you have any updates on this? With the current Canary #63.0.3231.0 I see a slightly different behavior: 1. The user locks the screen -> nothing at all is fired 2. The user switches to the login screen -> the "locked" event is fired The "locked" event should have been fired right away at step 1.
,
Oct 6 2017
I can confirm the unexpected behaviour. However, I think it doesn’t changed in Canary #63.0.3231.0. The statement "This error doesn't occur everytime" from your first post is a bit ambiguous, because chrome doesn’t fire correctly in any case. Sometimes chrome fires two events in the same behaviour of your last post, sometimes there are four events. To put it plainly, I see: locked at 10:00:42 // User switched to the login screen of Windows 10 active at 10:00:50 // User logged in successfully but sometimes: locked at 10:00:12 // User locked the screen active at 10:00:13 // Chrome fires immediately the active event locked at 10:00:42 // User switched to the login screen of Windows 10 active at 10:00:50 // User logged in successfully Both cases do not match (my) expected behaviour! (I added a beep to your minimal example to hear, when chrome fires an event)
,
Oct 26 2017
Is there any progress about it?
,
Nov 9 2017
This issue is not consistently reproducible on windows 10 with chrome #62.0.3202.89, hence adding TE-NeedsTriagehelp for further triage from Extensions dev team
,
Apr 25 2018
I can still reproduce this issue with latest stable (66.0.3359.117) and latest canary (68.0.3405.0). If the user locks the screen in Windows 10, there is either no event at all or the 'locked' event is immediately followed by an 'active' event. Both cases are wrong. |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by brajkumar@chromium.org
, Aug 8 2017Labels: Needs-Triage-M60 Needs-Feedback