Michael - does it make sense to fix this by changing the expectation? Should WebFrameManagerImpl only report the frames added since the last navigation?

The WebFrameManager should remove all known frames when the page navigates. Right now, this happens inside CRWWebController  (ref below). Do you think an early return in |loadCurrentURL| could be hit in this case, causing the failure? We could move the call to |RemoveAllWebFrames()| up in the method or maybe it needs to be called from a different location in order to support WKBasedNavigationManger.

https://cs.chromium.org/chromium/src/ios/web/web_state/ui/crw_web_controller.mm?rcl=0d6e36c05f8bc8e18eee92d7ee1d9f0009156eb4&l=1937

Ah |loadCurrentURL| is not called in slim nav for renderer initiated navigations (which includes back/forward navigations and reload). I think we should move it to |webView:didStartProvisionalNavigation|. This is a later point than |loadCurrentURL|, but is guaranteed to run for all navigations.

eugenebut@ made the point that we probably want to clear all the frames when we do other cleanup tasks like clearing the certVerificationErrors:

"InitializeExistingFrames is only called when the navigation is committed. I think  clearing frames is similar to |_certVerificationErrors->Clear();|, which happens more often."

iframe injection is not expected to launch yet in M71, so we can punt on this bug until M72.

It's possible that iframe messaging system will be used by autofill in M71. Is this difficult to fix or can we do as described in #c3 to fix for M71?

M71 feature freeze in September 28. iframes feature is not enabled on canary and is still under development. Is it realistic to aim iframes injections to M71?

In the iFrame Messaging Weekly earlier this week we said the chance is very small that it would be ready for M71. However, if we push this bug to 72, then we must also push iframe messaging so we should at least loop in Olivier and Eric, so I'll add them to CC.

The problem is that the about:blank placeholder page gets created as a WebFrame. I can fix that by ignoring it as done in crrev.com/c/1234268. Otherwise, we can try updating the test expectations.

Thanks for looking! Ignoring about:blank placeholder makes sense to me. It's only used for native content, WebUI, and error messages. They shouldn't need iframe JavaScript injection.

Assigning this to you for now. Please feel free to ping it back to me if you don't end up working on it.

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

commit cc462393818947d47173775ef79256932eadef47
Author: Mike Dougherty <michaeldo@chromium.org>
Date: Fri Sep 21 17:29:50 2018

Ignore WKScriptmessages from internal placeholder pages.

With SlimNavigationManager enabled, a placeholder page is rendered at the start
of the navigation stack. Prevent this placeholder page from being registered as
a frame.

Bug:  869884 
Cq-Include-Trybots: luci.chromium.try:ios-simulator-cronet;luci.chromium.try:ios-simulator-full-configs
Change-Id: I09907135bf48720ef4b25fb7ddaa607db4f03a27
Reviewed-on: https://chromium-review.googlesource.com/1234268
Commit-Queue: Mike Dougherty <michaeldo@chromium.org>
Reviewed-by: Danyao Wang <danyao@chromium.org>
Reviewed-by: Eugene But <eugenebut@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593243}
[modify] https://crrev.com/cc462393818947d47173775ef79256932eadef47/ios/web/web_state/ui/BUILD.gn
[modify] https://crrev.com/cc462393818947d47173775ef79256932eadef47/ios/web/web_state/ui/crw_wk_script_message_router.mm
[modify] https://crrev.com/cc462393818947d47173775ef79256932eadef47/ios/web/web_state/ui/crw_wk_script_message_router_unittest.mm