Notifications API Focus does not work on Google Chrome in some scenarios.
Reported by
pgane...@salesforce.com,
Apr 3 2017
|
||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Steps to reproduce the problem: 1. Generate Desktop Notification 2. Click Desktop Notification 3. Does not switch / focus you to active window. What is the expected behavior? Clicking Focus actually takes you to the active tab that generated the notification. What went wrong? We use Notifications API to generate a desktop notification whenever an event occurs. When the user clicks on the notification, focus has to move to the active tab that triggered the notification, this works correctly in Safari and Firefox, However in Google Chrome, clicking the notification has no effect, and focus doesn't move to the active tab. We did some debugging to identify the root cause. The issue is that we have an internal service that uses an iframe on the page to attach an eval function which operates in the context of the iframe. This way anyone who tries to eval code, does so in a context they can't access anything. But this causes a bug in this notification code in Google Chrome. Chrome is getting confused when the parent.focus() is being called. Its probably having issues with the iframe being the window. Though if you break in the function you clearly see the parent object is the window you expect it to be. Here are the sample JSFiddles that demonstrate the issue. The former uses an iframed eval function where focus does not work whereas the latter uses the regular eval function in which the focus works. Does not work: https://jsfiddle.net/o39apyr8/2/ Works: https://jsfiddle.net/o39apyr8/3/ Please let us know if you need any more information. We are happy to help in order to resolve this investigation. Did this work before? No Chrome version: 57.0.2987.133 Channel: stable OS Version: OS X 10.10.5 Flash Version:
,
Apr 4 2017
,
Apr 4 2017
The works fiddle is obviously not updated. This one you should work https://jsfiddle.net/o39apyr8/5/ which is simply toggling the boolean doYouWantItToWork from false to true.
,
Apr 10 2017
Thanks for filing the issue. Able to reproduce the issue on Mac-10.12.4,Windows 7 & Ubuntu 14.04 using Chrome reported version ( stable)-57.0.2987.133 version- and canary-59.0.3066.0 with the fiddle given in comment#0 & comment#3.Observed focus is not returning to active tab upon clicking the popup notification. This is Non-regression issue, Observed from M45 .Hence marking it as 'Untriaged' and confirming this issue to get more inputs from Dev team. Please find the attached screencast for reference. Note: From M30 to M40 ,no popup generated for the fiddle in chrome
,
Apr 13 2017
,
Apr 13 2017
Thank you for the bug report! +bokan and dcheng for frame/ OWNERS. The one difference for values for |doYouWantItToWork| is that when set to TRUE, the actual Window's eval() is used, otherwise iframe's eval() is used. When we fire the `onclick` event, an interaction token is issued to the context the notification was created in. This token can be consumed to focus the |window| only when it's a main frame. My guess is that with |doYouWantItToWork| set to FALSE, the interaction token ends up being issued to the iframe's context, which means the parent frame isn't allowed to focus. I don't know enough about how contexts work in order to triage down from there I'm afraid. Would it be reasonable to allow the Focus() call to happen when there's same-origin parent frames too? https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/frame/DOMWindow.cpp?type=cs&l=415 At a higher level, please be aware that we've deprecated the ability to request notification permission from iframes. (But you'll continue to be able to create them from an iframe.) Notifications have been deprecated in their entirety from insecure contexts, but I don't know whether that applies to you. https://goo.gl/rStTGz https://www.chromestatus.com/feature/6451284559265792
,
Apr 14 2017
Hello Peter, Thanks for the reasoning, I think we should allow the focus() call to happen when there are same origin parent frames. I believe that might fix this issue. Also, the request permissions part works well for our case, So I believe the main issue is the interaction token ending up to the iframe's context and not the parent's context.
,
Apr 18 2017
The broken examples appear to work correctly in Firefox and this seems like a reasonable request to me. Though, I don't have any context here. +mlamouri@ who appears to have written some of the responsible code in https://crrev.com/dc54845 and https://crrev.com/2c60f08 may have more insight.
,
Apr 24 2017
Any updates on this issue? Thanks a lot!
,
Apr 25 2017
mlamouri, mind further triaging this?
,
May 8 2017
Changing the status from Untriaged to Assigned.
,
Jun 2 2017
I don't have much cycles for this. I've implemented this feature more than 2 years ago. Feel free to reassign if there is no one else who would know how the feature works.
,
Sep 8 2017
,
Sep 10
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 21
*** UI Mass Triage*** Tested on latest Canary #72.0.3617.0 on Windows 10 and was not able to reproduce the issue by performing testing on www,facebook.com When tried to test on the jsfiffle URL’s provided, notifications are not received. pganesan@ -- Please feel free to file a new issue or reopen this issue if the issue is reproduced on latest Canary versions. Thanks! |
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by ranjitkan@chromium.org
, Apr 4 2017