Cannot set 'href' property on 'Location' in cross-origin iFrame.
Reported by
da...@celtra.com,
Jul 3
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36 Steps to reproduce the problem: Go to page http://1.kozak.si/setloc.html. Press on the first 2 buttons ('set loc (no ref)', 'set loc (ref)') and the page 'http://example.com' isn't opened, but when pressing on the 3rd button ('set loc (func)'), it is. The page (most probably) shouldn't be opened when pressing on the 3rd button. What is the expected behavior? What went wrong? We have a simple test page http://1.kozak.si/setloc.html to demonstrate a bug, that occurs on Chrome 68+ (currently reproducible in Canary). We have a cross-origin iFrame and inside that cross-origin iFrame we have 2 iframes. In the 1st iFrame we defined 3 functions for opening an URL in the same window (you can check the code): - directly access the window.top, - access the top window reference from the 2nd iframe window, - pass the function, which then opens an URL. In the 2nd iFrame we defined 3 buttons, where each button calls one of those 3 functions defined in the 1st iframe. The first 2 calls don't work and we get an error: - Uncaught DOMException: Failed to set the 'href' property on 'Location': The current window does not have permission to navigate the target frame to 'http://example.com'. On the contrary the 3rd method (3rd button) works ok and it looks a little fishy. Is this a bug? Also, an important question: can we expect the same restriction in the future for the window.open() call (currently it works with all 3 methods from above). If so, when (in which Chrome version)? Did this work before? N/A Chrome version: 68+ Channel: stable OS Version: OS X 10.13.5 Flash Version:
,
Jul 3
Nate, can you take a look at whether the framebusting intervention (issue 624061, https://www.chromestatus.com/features/5851021045661696) is doing the right thing here, and at the question about window.open()? It does look a little suspicious that there's a difference in behavior between these buttons.
,
Jul 9
The 3rd case is different from the other two based on the value of current_window at https://chromium.googlesource.com/chromium/src/+/d2429f7cf43028af27e7c4e2768f556296880830/third_party/blink/renderer/core/frame/location.cc#275 For the 3rd case, calling_window is the window with the buttons, but for the other 2 cases, it's the sibling window. I believe this is because of where the passed function was created, it's evaluated as being called from the window that created the function? JS window rules still confuse me... Anyway, because the 3rd case is being attributed to the frame where the user gesture is being processed, it's approved, while the first two are attributed to a frame that hasn't received a user gesture. When a frame is marked as having received a user gesture, it also marks its parents, so this case is specific to performing the navigation from a sibling or child. Perhaps the framebusting check should always permit navigations if a user gesture is currently being processed?
,
Jul 17
> Perhaps the framebusting check should always permit navigations if a user gesture is currently being processed? Yes, I believe that from the user's perspective the only relevant circumstance is wether the action is user-initiated or not, not which window does the opener function technically belong to.
,
Aug 9
|
||||
►
Sign in to add a comment |
||||
Comment 1 by woxxom@gmail.com
, Jul 3