Setting M-57 milestone, however, this is not really an issue until Apple released iOS 10.3. Of course, we don't know when.

Further testing using the PasswordViewer/PasswordSender test apps show that the underlying communication mechanism between Chrome and 1Password seems to be working fine. It is likely to be getPasswordFormDataList() as described by one of the Apple engineers.

"Note that our investigation into WebKit suspected that a change in throwing a SecurityError for cross-origin access was to blame. The cross-origin access was always being blocked, but the change was the new exception being thrown which we did for compatibility and consistency with Firefox and Chrome. Based on the script analyzed, it seems that a try/catch needs to be used for the getPasswordFormDataList()."

This is the error message on the console (line breaks added to aid readability):

[0126/175832.478927:ERROR:crw_web_controller.mm(2917)]

JavaScript error: SecurityError (DOM Exception 18): Blocked a frame with origin "https://www.amazon.com"
from accessing a frame with origin "https://s.amazon-adsystem.com".

Protocols, domains, and ports must match.

URL: https://www.amazon.com/ap/signin/151-6741101-1645533?_encoding=UTF8&openid.assoc_handle=anywhere_v2_us&openid.claimed_id=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fidentifier_select&openid.identity=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fidentifier_select&openid.mode=checkid_setup&openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0&openid.ns.pape=http%3A%2F%2Fspecs.openid.net%2Fextensions%2Fpape%2F1.0&openid.pape.max_auth_age=0&openid.return_to=https%3A%2F%2Fwww.amazon.com%3F_encoding%3DUTF8%26ref_%3Dnavm_hdr_signin


Stack trace when error message happened:

* thread #1, name = 'CrWebMain', queue = 'com.apple.main-thread', stop reason = breakpoint 2.1
    frame #0: Chromium`::-[CRWWebController handleWindowErrorMessage:context:](self=0x000000010a181e00, _cmd="handleWindowErrorMessage:context:", message=0x000000017425be10, context=0x000000017445d700) at crw_web_controller.mm:2913
    frame #1: Chromium`::-[CRWWebController respondToMessage:userIsInteracting:originURL:](self=0x000000010a181e00, _cmd="respondToMessage:userIsInteracting:originURL:", message=0x000000017425be10, userIsInteracting=NO, originURL=0x000000016fdd5968) at crw_web_controller.mm:2518
    frame #2: Chromium`::-[CRWWebController respondToWKScriptMessage:](self=0x000000010a181e00, _cmd="respondToWKScriptMessage:", scriptMessage=0x0000000174646f90) at crw_web_controller.mm:2610
    frame #3: Chromium`::-[CRWWebController didReceiveScriptMessage:](self=0x000000010a181e00, _cmd="didReceiveScriptMessage:", message=0x0000000174646f90) at crw_web_controller.mm:2573
  * frame #4: Chromium`::__31-[CRWWebController setWebView:]_block_invoke(.block_descriptor=<unavailable>, message=0x0000000174646f90) at crw_web_controller.mm:4413
    frame #5: Chromium`::-[CRWWKScriptMessageRouter userContentController:didReceiveScriptMessage:](self=0x0000000174431e80, _cmd="userContentController:didReceiveScriptMessage:", userContentController=0x000000017032a280, message=0x0000000174646f90) at crw_wk_script_message_router.mm:93
    frame #6: 0x000000019467721c WebKit`ScriptMessageHandlerDelegate::didPostMessage(WebKit::WebPageProxy&, WebKit::FrameInfoData const&, WebCore::SerializedScriptValue&) + 196
    frame #7: 0x0000000194616a14 WebKit`WebKit::WebUserContentControllerProxy::didPostMessage(IPC::Connection&, unsigned long long, WebKit::FrameInfoData const&, unsigned long long, IPC::DataReference const&) + 176
    frame #8: 0x0000000194618e8c WebKit`void IPC::handleMessage<Messages::WebUserContentControllerProxy::DidPostMessage, WebKit::WebUserContentControllerProxy, void (WebKit::WebUserContentControllerProxy::*)(IPC::Connection&, unsigned long long, WebKit::FrameInfoData const&, unsigned long long, IPC::DataReference const&)>(IPC::Connection&, IPC::Decoder&, WebKit::WebUserContentControllerProxy*, void (WebKit::WebUserContentControllerProxy::*)(IPC::Connection&, unsigned long long, WebKit::FrameInfoData const&, unsigned long long, IPC::DataReference const&)) + 156
    frame #9: 0x000000019444a828 WebKit`IPC::MessageReceiverMap::dispatchMessage(IPC::Connection&, IPC::Decoder&) + 120
    frame #10: 0x00000001945f25ec WebKit`WebKit::WebProcessProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) + 32
    frame #11: 0x0000000194410918 WebKit`IPC::Connection::dispatchMessage(std::__1::unique_ptr<IPC::Decoder, std::__1::default_delete<IPC::Decoder> >) + 164
    frame #12: 0x0000000194413104 WebKit`IPC::Connection::dispatchOneMessage() + 232
    frame #13: 0x000000018f320c24 JavaScriptCore`WTF::RunLoop::performWork() + 172
    frame #14: 0x000000018f320efc JavaScriptCore`WTF::RunLoop::performWork(void*) + 36
    frame #15: 0x000000018a99e3c8 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24
    frame #16: 0x000000018a99dd38 CoreFoundation`__CFRunLoopDoSources0 + 540
    frame #17: 0x000000018a99b944 CoreFoundation`__CFRunLoopRun + 744
    frame #18: 0x000000018a8cb9bc CoreFoundation`CFRunLoopRunSpecific + 424
    frame #19: 0x000000018c338074 GraphicsServices`GSEventRunModal + 100
    frame #20: 0x0000000190c7a984 UIKit`UIApplicationMain + 208
    frame #21: Chromium`main(argc=1, argv=0x000000016fdd7ac8) at chrome_exe_main.mm:63
    frame #22: 0x00000001898d959c libdyld.dylib`start + 4

See also  Issue 683385  and https://codereview.chromium.org/2646733007
Also removing RVG since the other issue is already public.

Since rick already checked in a fix, is this fixed? Can we test it?

Tested in 58.0.2998.0 canary, iPhone 6S iOS 10.3 bug is still reproducible.

There are 2 cases where win.document was used without try/catch. Rick fixed one. I fixed the other. The "other" is the one that actually broke 1Password integration.

Still waiting for OWNERS review on CL mentioned in comment 5.

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

commit ea5098bb3372baa8d32b117f1b687e739e075988
Author: pkl <pkl@chromium.org>
Date: Tue Jan 31 14:12:01 2017

Catches and ignores errors when accessing win.document in Password Autofill JS

Old implementation assumes that win.document will silently return nil.
Under some versions of iOS, access to win.document may generate an
exception, thus the try/catch.

BUG= 685761 

Review-Url: https://codereview.chromium.org/2661503003
Cr-Commit-Position: refs/heads/master@{#447228}

[modify] https://crrev.com/ea5098bb3372baa8d32b117f1b687e739e075988/ios/chrome/browser/passwords/resources/password_controller.js

Verified in 58.0.2999.0 canary.
Request cherrypick.

Your change meets the bar and is auto-approved for M57. Please go ahead and merge the CL to branch 2987 manually. Please contact milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), ketakid@(cros), govind@(desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

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

commit afa15792ff95c1cd79b83115198bd5e4be74ab2d
Author: Eugene But <eugenebut@google.com>
Date: Fri Feb 03 18:23:53 2017

Catches and ignores errors when accessing win.document in Password Autofill JS

Old implementation assumes that win.document will silently return nil.
Under some versions of iOS, access to win.document may generate an
exception, thus the try/catch.

BUG= 685761 

Review-Url: https://codereview.chromium.org/2661503003
Cr-Commit-Position: refs/heads/master@{#447228}
(cherry picked from commit ea5098bb3372baa8d32b117f1b687e739e075988)

Review-Url: https://codereview.chromium.org/2677703002 .
Cr-Commit-Position: refs/branch-heads/2987@{#293}
Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943}

[modify] https://crrev.com/afa15792ff95c1cd79b83115198bd5e4be74ab2d/ios/chrome/browser/passwords/resources/password_controller.js

verified the issue on latest canary build 58.0.3005.0 canary, tested on iPhone 5SE(iOS 10 beta 3).

User name and password is filled in amazon, works fine.

Verified on chrome beta version 57.0.2987.35 on iPhone 7+ with iOS 10.2.1, following the steps mentioned in comment #0.  Looks good.

Can we verify M57 beta with iOS 10.3 beta to make sure that cherrypicked change is there? Thanks!

Verified on chrome beta version 57.0.2987.52 on iPhone 6 plus with iOS 10.3 beta, following steps mentioned in comment #0. Looks good.