Issue metadata
Sign in to add a comment
|
parent communicating with child popup after redirect away from the original domain
Reported by
alvernac...@gmail.com,
Dec 21 2017
|
||||||||||||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.108 Safari/537.36
Steps to reproduce the problem:
1. open a popup with
2. redirect to google adwords authentication page
3. user logs in and is redirect to our redirectUrl with a code
4. try to get the popups location.href
Our pseudo code looks like below:
popup = window.open()
popup.location.href = 'google adwords auth page'
setInterval(() => {
// wait for user to login and get redirect to the redirect URL with the code designating successful auth
var urlWithCode = popup.location.url // this is where we get the error mentioned above
}, 100)
What is the expected behavior?
we are expected to get the popup.location.href from the parent window
What went wrong?
got the following error: [Exception: DOMException: Blocked a frame with origin "https://localhost:5000" from accessing a cross-origin frame. at checkPopup (https://localhost:5000/2.audiences.js:3018:16)]
origins are the same so no cross-origin security should kick in
Did this work before? Yes 63.0.3239.84
Chrome version: 63.0.3239.108 Channel: stable
OS Version: OS X 10.12.6
Flash Version:
,
Dec 23 2017
One workaround until issue 796912 is fixed might be for the page at the redirect URL to send a postMessage to its window.opener with its location.url, and for your main page to wait for that instead of polling the popup's location.
,
Dec 23 2017
our main flow is in an iframe, but I have just checked and the same issue presents itself when not running in an iframe
,
Dec 26 2017
,
Dec 27 2017
FWIW it seems this is fixed in current Beta (64)
,
Dec 27 2017
Unable to reproduce this issue on reported version 63.0.3239.108 using Mac 10.13.1 as we are seeing below error on pasting given code in console of NTP. Uncaught DOMException: Blocked a frame with origin "https://www.google.co.in" from accessing a cross-origin frame. at setInterval (<anonymous>:6:34) @Reporter: Could you please provide sample test file to check this issue and possible please guide us with steps to reproduce the issue with sample file. This would help in further triaging of the issue. Thanks!
,
Dec 27 2017
#3: yes, I think this indeed can happen from the main frame as well, if that frame was navigated prior to initiating the OAuth flow. I've just posted repro steps for that at https://crbug.com/796912#c17 , including the main frame variant. Can you please confirm whether your OAuth issue goes away if you launch Chrome with --disable-features=sign-in-process-isolation?
,
Dec 28 2017
Merging to issue 796912 - let's use that one to cover both main frame and iframe cases.
,
Jan 1 2018
I've been on holiday for a while, is there anything needed from me?
,
Jan 2 2018
RE: #c9 No follow-up is needed. As pointed out in https://crbug.com/796912#c32 this issue should be fixed now.
,
Jan 26 2018
Hello Guys, I can still see this issue in Chrome 64.0.3282.119 (Official Build) (64-bit) (cohort: 64_119_win). can help me here? |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by alex...@chromium.org
, Dec 23 2017