Bug 187411 - REGRESSION (r219757): Accessing response getter of XHR instance from IFRAME sets constructor to Object from the IFRAME
Summary: REGRESSION (r219757): Accessing response getter of XHR instance from IFRAME s...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: Safari 11
Hardware: Mac macOS 10.13
: P2 Normal
Assignee: Chris Dumez
URL:
Keywords: InRadar
Depends on:
Blocks: 174740
  Show dependency treegraph
 
Reported: 2018-07-06 14:06 PDT by cvazac
Modified: 2018-07-24 21:47 PDT (History)
11 users (show)

See Also:


Attachments
test case (1.51 KB, application/zip)
2018-07-06 14:06 PDT, cvazac
no flags Details
Patch (6.20 KB, patch)
2018-07-20 15:34 PDT, Chris Dumez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description cvazac 2018-07-06 14:06:29 PDT
Created attachment 344453 [details]
test case

Scenario:
base page with one same-origin IFRAME
base page creates an XMLHttpRequest instance

Issue:
If the IFRAME adds a `readystatechange` listener to the XMLHttpRequest instance, and it reads the response getter before the `top` context does, the `constructor` of the object will be equivalent to `iframe.contentWindow.Object`, not `top.Object`. 

This "works" in other browsers, including Safari 10.0.1.

Works in 604.5.6.
Fails in 605.1.15.

Code executed in the IFRAME:
xhr.addEventListener('readystatechange', function(){
  xhr.response
})

From this point forward:
xhr.response.constructor === iframe.contentWindow.Object
xhr.response.constructor !== top.Object


See https://cvazac.netlify.com/xhr-response-constructor/ for reproducible case.
Comment 1 Radar WebKit Bug Importer 2018-07-06 21:20:18 PDT
<rdar://problem/41920593>
Comment 2 cvazac 2018-07-09 15:03:02 PDT
I attempted to bisect the issue using:
./Tools/Scripts/bisect-builds -c release -p mac-highsierra -s 219162 -e 224949

But every build that attempts to launch gives me:
Starting SafariForWebKitDevelopment with DYLD_FRAMEWORK_PATH set to point to built WebKit in /var/folders/33/prqh7l5n7fgd1l6d3kq6bq_r0000gy/T/tmpK9xc8x/Release.
dyld: Symbol not found: __ZN3WTF8JSONImpl10ObjectBase6removeERKNS_6StringE
  Referenced from: /System/Library/PrivateFrameworks/WebInspector.framework/Versions/A/WebInspector
  Expected in: /var/folders/33/prqh7l5n7fgd1l6d3kq6bq_r0000gy/T/tmpK9xc8x/Release/JavaScriptCore.framework/Versions/A/JavaScriptCore
 in /System/Library/PrivateFrameworks/WebInspector.framework/Versions/A/WebInspector
Comment 3 Alexey Proskuryakov 2018-07-10 09:31:30 PDT
Yes, these WebKit revisions are so old that they don't work with latest Safari.

I bisected to r219757. Sam, Chris, could you take a look?
Comment 4 Chris Dumez 2018-07-10 09:47:06 PDT
Likely caused by us caching the response in the wrapper.
Comment 5 Chris Dumez 2018-07-20 15:34:38 PDT
Created attachment 345483 [details]
Patch
Comment 6 Chris Dumez 2018-07-23 09:41:30 PDT
Comment on attachment 345483 [details]
Patch

ping review?
Comment 7 WebKit Commit Bot 2018-07-24 21:47:45 PDT
Comment on attachment 345483 [details]
Patch

Clearing flags on attachment: 345483

Committed r234188: <https://trac.webkit.org/changeset/234188>
Comment 8 WebKit Commit Bot 2018-07-24 21:47:46 PDT
All reviewed patches have been landed.  Closing bug.