On iOS when trying to use window.postMessage I get 11 errors saying: Blocked a frame with origin "null" from accessing a frame with origin "null". Protocols, domains, and ports must match. See this screenshot: http://i.imgur.com/JJkIEy5.jpg This happens when using WKWebView in a Cordova project or in the Safari browser when using the file:// protocol. The error doesn't happen when using UIWebView or when using the HTTP(s) protocol. I have tested it in iOS 9 and 10 with the same result. I have attached 2 HTMLs files. Open index.html in the Simulator with Safari iOS using a file:// protocol and click the buttons. Here is a simple cordova project that you can test too for WKWebView. https://github.com/PierBover/cordova-wkwebview-iframe-bug To reproduce in the cordova project you need to install the cordova CLI and then: 1) go to the cordova folder 2) cordova emulate ios --target="iPad-Air-2, 9.3" 3) Open Safari. On the Developer menu open the JS console for the webview. 4) Click the buttons on the webview. If you test this URL in Safari for iOS you will see the error doesn't reproduce which confirms it only happens when using file:// http://pierbover.com/pub/iframe-bug/
Created attachment 289704 [details] html files to reproduce the error
What's really bizarre is that the event ends up going through anyway as you can see in the screenshot.
This sounds more or less the same as bug 154916. Quite bizarre indeed that it works despite logging errors - perhaps there are multiple operations made behind the scenes.
Is this ever going to be fixed? It's been almost a year since I posted the bug and it has been completely ignored by the WebKit team.
(In reply to Pier Bover from comment #4) > Is this ever going to be fixed? > > It's been almost a year since I posted the bug and it has been completely > ignored by the WebKit team. I understand the frustration. Regrettably, with 1000's upon 1000's of bug reports incoming in a given release cycle and only so many eyes on them all. Here are some reasons why this bug hasn't gotten any obvious traction: 1 - As you note, while errors are emitted, the operations still work. 2 - This is the only such report we've gotten, which suggests this isn't a widespread issue. This doesn't mean we don't think it *is* an issue, but we necessarily have to focus on more wide-reaching bugs than those only a handful of folks see. 3 - The steps to reproduce do not lend themselves to easy exploration. For bugs that affect only 3rd party apps it is *extremely* useful for there to be an attached archive with an xcode project inside, and for the steps to reproduce to simply be "build and run the attached project and you'll see the bug" Do you think that's something you'd be able to put together?
Hey Brady There is at least another bug that I know of which might be related to this one. https://bugs.webkit.org/show_bug.cgi?id=154916 People are stumbling on this because they are using Cordova but the problem is really in WKWebView. When replacing WKWebView with UIWebView the problem disappears, alas UIWebView is too outdated. In my original report from a year ago I included both the HTML files necessary to reproduce the bug, the Cordova project in the repo, and the steps to start the Simulator. The Xcode project is also there as you can see in the Github link, although if you are not familiar with Cordova I understand this might have been not clear. https://github.com/PierBover/cordova-wkwebview-iframe-bug/tree/master/cordova/platforms/ios Here is the bug reproduced when running the simulator with iOS 10.2. I just made that screenshot in a new project I'm working on. http://imgur.com/B5I1j7e.jpg In that project I need to open HTMLs in an iframe and sometimes randomly the webview refreshes itself when creating the element in the DOM. I suspect this is also related to the same problem although I don't have a reproducible case yet.
(In reply to Pier Bover from comment #6) > > In my original report from a year ago I included both the HTML files > necessary to reproduce the bug, the Cordova project in the repo, and the > steps to start the Simulator. The Xcode project is also there as you can see > in the Github link, although if you are not familiar with Cordova I > understand this might have been not clear. You're right, I'm not familiar with setting up a Cordova app. And if any WebKit contributors are, then I don't know who they are nor if their eyes are simply not on this bug. I personally don't have the time to learn how to get a Cordova app up and running, and I'm not nearly the busiest in the project. If this is a bug with WKWebView, then necessarily it's something that could be reproducible without these relatively opaque and unfamiliar steps to set up a Cordova app, right? Usually when people report a WKWebView app bug they include a simple WKWebView app that shows the bug. > https://github.com/PierBover/cordova-wkwebview-iframe-bug/tree/master/ > cordova/platforms/ios This URL is a 404.
The URL I posted works fine. Check the screenshots. http://imgur.com/a/6SPdm Maybe you are viewing the URLs on a client that is breaking them? If you need something that I haven't already provided let me know and I'll do my best to help you. We all want this fixed, right?
Ok, since you sound somewhat bitter and I want to make this as easy as possible for you I made an Xcode project. No Cordova, nothing. Just a view with WkWebView and 2 local HTML files. I've attached the project as a zip file. I've also made this video reproducing the bug. https://youtu.be/GAiY2_7oRQM
Created attachment 319159 [details] Xcode project without Cordova
(In reply to Pier Bover from comment #10) > Created attachment 319159 [details] > Xcode project without Cordova The Xcode project didn't include the html files. Downloaded them separately and rejiggered the xcodeproj to point to them. With that fix, easy to reproduce in the test app. But... Just opening those HTML files as file: URLs in desktop Safari is all you need to reproduce the issue. That would've been good information to have a long time ago. CC'ing a few folks who have worked on tightening down cross origin restrictions (including for file: urls)
Steps to reproduce: 1 - Download the attached HTML files 2 - Open them in Safari as file urls.
(In reply to Brady Eidson from comment #12) > Steps to reproduce: > 1 - Download the attached HTML files > 2 - Open them in Safari as file urls. 3 - Click the buttons
> The Xcode project didn't include the html files. Oh sorry, I thought Xcode would copy the files to the project. > But... Just opening those HTML files as file: URLs in desktop Safari is all you need to reproduce the issue. Damn, I was so focused on iOS that it never crossed my mind it would affect desktop too. Thanks Brad.
<rdar://problem/35751736>
Mass move bugs into the DOM component.