JavaScript dialogs shouldn't be able to make Chrome steal focus from other apps
Reported by
jedwards...@gitlab.com,
May 30 2018
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3443.0 Safari/537.36 Steps to reproduce the problem: 1. Find service that uses notifications aggressively. Surprisingly the most common of these isn't an intentionally malicious site, but Google Calendar. 2. Set up a notification trigger. In google calendar you can do this by creating events and asking to be notified 10mins beforehand and 2mins beforehand. 3. Block notifications, because with notifications blocked an untrusted site should not be able to take focus away from another task 4. Pin this tab and leave it open in Desktop 1 on OSX 5. Do something productive on another desktop 6. Wait for the popup/notification/alert to trigger 7. You will be rudely interrupted, switched to Desktop 1, and a popup like dialog box will appear What is the expected behavior? Either the page is left in the background, with a popup eventually being revealed when you activate that tab, or nothing happens since this has been expressly blocked. This works fine in Firefox, and worked fine before Chrome lost my profile and all settings causing me to abandon it. I can't mark it as a regression, since I'm not certain of the combination of settings required to trigger this behaviour. What went wrong? Chromium/Chrome allows window hijacking Did this work before? N/A Chrome version: 69.0.3443.0 Channel: n/a OS Version: OS X 10.13.4 Flash Version: See https://productforums.google.com/forum/#!topic/calendar/DD9ifGwd4f0;context-place=topicsearchin/calendar/alert for examples of other people reproducing this problem In theory this could be seen as a security flaw, as a site could impersonate something else and if the user doesn't notice the window has been switched might mistakenly trust the page they thought they were on.
,
May 31 2018
,
May 31 2018
Thank you for the report! The calendar popups that you're seeing, are those general alert() ones or notification ones? I suspect the former, given that we can't show notifications when the permission has been revoked. Avi, didn't we change focusing behaviour for those?
,
May 31 2018
alert() doesn't focus windows any more. OP, can you provide more details on step 7? You mention two things: 1. You are switched to the desktop with the page 2. A dialog appears Do both always happen together? Can you post a picture of the dialog that appears?
,
May 31 2018
Trying to reproduce again I'm even less certain of the combination of things needed to trigger this. This time I wasn't able to reproduce with it set to blocked, but was with it set to always ask. When I change Notifications to "Blocked" a bar appears on the original tab encouraging me to refresh the page, so it is possible that I missed that. Google Calendar also has a "Desktop Notifications" vs "Alerts" option I don't understand, but I originally could get neither to work without switching my desktop to Chrome. > Can you post a picture of the dialog that appears? Attached > Do both always happen together? The alert always appears, and when the desktop is switched they happen together. I'd managed to find a combination of settings that didn't switch desktop, but can now only reproduce when notifications for that site are set to "Always Ask".
,
May 31 2018
After trying various things to reliably reproduce this I've somehow stumbled upon the style of notifications I used to have back when I used it as my primary browser, (attached). I'm not sure how Google Calendar got stuck using alerts for both "Desktop Notifications" and "Alerts", and unfortunately am still not sure which Chrome settings are needed for alerts to appear while blocked. If it weren't for dozens of other reports in https://productforums.google.com/forum/#!topic/calendar/DD9ifGwd4f0 I'd now assume an error on my part. It still feels weird that window hijacking takes place when set to "Always Ask". Perhaps window focusing for alerts should follow notification settings when they are set to "Always Ask" or "Blocked"?
,
May 31 2018
Alert dialogs should *never* be allowed to steal focus. I took away that ability months ago so that shouldn't be happening at all. :(
,
May 31 2018
After seeing the "calendar.google.com wants to" dialog (attached) this became much harder to reproduce. Clicking allow would lead to either alerts in the background or desktop notifications through the OS. Clicking block I think led to always having background alerts. Just now I was able to reproduce again after clicking the [x] in that dialog.
,
May 31 2018
> Alert dialogs should *never* be allowed to steal focus. I took away that ability months ago so that shouldn't be happening at all. :(
Ah, that simplifies it!
I tried doing `Notification.requestPermission();` followed by `[x]` followed by `setTimeout(function(){ alert("Focus"); }, 5000);` in a new tab on an unrelated website and was able to reproduce.
Even simpler, I could reproduce again with just the timeout on any new site such as this one, making this likely unrelated to notification settings.
,
May 31 2018
Do you have the devtools window open for this site? Alerts will steal focus if you have devtools open.
,
Jun 1 2018
> Do you have the devtools window open for this site? Alerts will steal focus if you have devtools open. It would have been when testing the alert manually, but never was with Google Calendar. I've just reproduced it again but this time closing devtools after scheduling the alert, screen recording attached.
,
Jun 4 2018
Oooh. I removed the ability for a non-frontmost page to steal focus from other pages. I didn't remove the ability for a frontmost-within-Chrome page to allow Chrome to steal focus from other applications.
,
Jun 5 2018
,
Jun 5 2018
,
Jun 5 2018
https://chromium-review.googlesource.com/c/chromium/src/+/1087417 tries to remove activation, but on Windows it activates because the delegate's CanActivate returns true, and on the Mac it always activates ( bug 849797 ).
,
Jun 5 2018
,
Nov 13
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by mmenke@chromium.org
, May 30 2018