Bug 162512 – window.postMessage error with iframe and file:// protocol

• Component: DOM
• Status: NEW

[Pier Bover]

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/

[Pier Bover]

Created attachment 289704 [details]
html files to reproduce the error

[Pier Bover]

What's really bizarre is that the event ends up going through anyway as you can see in the screenshot.

[Alexey Proskuryakov]

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.

[Pier Bover]

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.

[Brady Eidson]

(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?

[Pier Bover]

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.

[Brady Eidson]

(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.

[Pier Bover]

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?

[Pier Bover]

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

[Pier Bover]

Created attachment 319159 [details]
Xcode project without Cordova

[Brady Eidson]

(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)

[Brady Eidson]

Steps to reproduce:
1 - Download the attached HTML files
2 - Open them in Safari as file urls.

[Brady Eidson]

(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

[Pier Bover]

> 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.

[Radar WebKit Bug Importer]

<rdar://problem/35751736>

[Lucas Forschler]

Mass move bugs into the DOM component.