Probably related to 10.3.
Likely similar to crbug.com/702566

Please verify that autofill works correctly on pages with iframes on iOS 10.3.

Could you please provide an where this fails? And did this ever work?

As far as I can tell, this happens when autofill is triggered.

I don't know if this ever worked. It didn't recently start occurring.

I wouldn't make this a release blocker if it's not a regression. Could please point us to an example page where this fails?

I suspect it will fail on this page. http://s.codepen.io/boomerang/iFrameKey-299954da-48e6-0bf8-58d3-22882238bed7/index.html (see http://codepen.io/apexskier/pen/dvEegb).

Facing the same issue on chrome ios. Doesn't matter autofill is enabled or disabled.

See this comment :- https://bugs.chromium.org/p/chromium/issues/detail?id=590375#c12
It recursively tries to extract form fields in iframes without checking the origin which throws the error.

Attached a simple html code which throws error in chrome for ios

Deleted: index.html 283 bytes

index.html 283 bytes View Download

This just started showing up in our logs on April 5, so this looks like a regression.

The following versions are throwing this error:
Chrome 57.0.2987
Chrome 58.0.3029

I just tried this in Chrome 47 and this error is not happening so I can confirm that this is a regression.

CCing vabr in case this is from a passwords change

I don't think this is a recent regression, and unlikely to come from a passwords change. Perhaps this is a dupe of  bug 659173 , which I filed last year?

After more digging through our logs I've found the following:

Two additional Chrome version are affected:
Chrome 52.0.2743
Chrome 56.0.2924

The only thing that is consistent with EVERY error in our log is that the version of iOS is 10.3 or 10.3.1 - 10.3 introduced a lot of WebKit security fixes: https://support.apple.com/en-us/HT207617

iOS 10.3 was released on 3/27, which is 9 days before it started showing up in our logs.  Given that it takes a bit for people to first get the iOS system notification that a new version of iOS is available and then to update to the new version, the 9 day gap from release to first bug in our logs makes sense.

Can you please investigate whether one of the security fixes in iOS 10.3 is the culprit?

This happens with our client websites too. If this is of any help:

Affected Chrome versions:

58.0.3029
57.0.2987
56.0.2924
55.0.2883

All on iOS 10.3.

Still affected:
Mozilla/5.0 (iPad; CPU OS 10_3_2 like Mac OS X) AppleWebKit/603.1.30 (KHTML, like Gecko) CriOS/59.0.3071.84 Mobile/14F89 Safari/602.1

I fixed a similar issue by changing the injected JavaScript:  crbug.com/735634 . I'll send a patch soon and see if you like it.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/051aedf5e9212a891d4c1886e4407e070d08ce09

commit 051aedf5e9212a891d4c1886e4407e070d08ce09
Author: Danyao Wang <danyao@google.com>
Date: Fri Jun 30 14:34:19 2017

Skip cross-origin iframes for autofill.

Previously we rely on document property being undefined in an iframe to
detect cross-origin iframes. This triggers a SecurityError in iOS.
Change the origin check to use only information available from the
parent frame (i.e. src attribute of iframe element) to avoid triggering
the error, which adds noise to console.

Bug:  709132 
Change-Id: I59a3a1f31a43f0db8099e964f1c56841e59ca8e3
Reviewed-on: https://chromium-review.googlesource.com/557421
Reviewed-by: Vaclav Brozek <vabr@chromium.org>
Commit-Queue: Danyao Wang <danyao@chromium.org>
Cr-Commit-Position: refs/heads/master@{#483700}
[modify] https://crrev.com/051aedf5e9212a891d4c1886e4407e070d08ce09/components/autofill/ios/browser/resources/autofill_controller.js
[modify] https://crrev.com/051aedf5e9212a891d4c1886e4407e070d08ce09/ios/chrome/browser/passwords/resources/password_controller.js

I'm not familiar with the relation between fixes and new releases, but I'm wondering when there will be a release for iOS Chrome where this fix is applied?

Hello, this patch has landed in the M61 version slated for wide release in the fall (I think September?). Hope this answers your question.

Sure, thanks :-)

Den fre. 30. jun. 2017, 23:30 skrev ma… via monorail <
monorail+v2.4273537821@chromium.org>:

I seem to be getting a similar issue, but not to do with CORS. Can someone check in M61 that this is fixed otherwise I'll file a new bug. 

Steps to reproduce;
Go to: https://robert-daly.com/temp/mw.php
Focus an element, iOS keyboard will have autofill button

Go to; https://robert-daly.com/temp/mw.php?frame=true
Focus element, autofill buttons missing

Only difference is that there is an GTM iframe on the page.

iOS 10.3.2
Chrome 59.0.3071.102

 Issue 758308  has been merged into this issue.

Hi guys.
Is this issue fixed? 
We still have a lot of 'Blocked frame' errors on Chrome Mobile iOS 61, Chrome Mobile iOS 63

iFrame exploration has been disabled for autofill until we have proper iframe support.
I am not sure for password.

+dvadym for keywords "ios", "iframe", and "password"

PasswordManager processes forms from iframes that have the same origins as the main frame.

sop...@debitoor.com: Don't you have examples of pages where 'Blocked frame' errors are seen?