Issue 697677  has been merged into this issue.

Was this a recent regression, or has it been broken for a while?

The "reload" button triggers the refresh action correctly in M56, so it appears that M57 is the first milestone with this regression.

Should we think about this blocking M57?

+mardini for opinion on blocking

I'd say it's blocking. 

I think this is a poor user experience that might make them feel they're stuck since there is no feedback given. It's quite normal for someone to mistype a URL and wait. If no error page is shown, the user might think there is no network, or that the browser is frozen, ...etc. Do we know the culprit CL? How risky is the fix?

Good Version: 57.0.2965.0 canary #8fa5f27
Bad Version: 57.0.2966.0 canary #39d9d9a

This is something that we should be able to test with EarlGrey to prevent future regressions.

To clarify, is this RBS for M57 or M58?

+ cmasso@

Can you fix it for M57 ?

Sorry I wasn't clear. I meant basically how risky is the cherry-pick?

I'm working on a fix now; I'll update the bug with a CL once I have a fix so we can asses how risky the cherry-pick is.

This was broken here: https://codereview.chromium.org/2597133002

Working on a fix now that doesn't break reading list.

I will also want the fix to be in M57 but let's wait for the CL to see how risky it is to cherry-pick it at this time, so leaving this bug in M58 for now.

kkhorimoto@ can we also add a test to prevent this from happening again?

Fix out for review: https://codereview.chromium.org/2728243002/

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

commit 0f799230c0f27e3e8882868f46d9d5cefe9c8c6d
Author: kkhorimoto <kkhorimoto@chromium.org>
Date: Sat Mar 04 00:28:16 2017

Use targetFrame to decide whether to allow load in static html view.

StaticHtmlViewController intercepts attempted main frame navigations
and performs the load using the UrlLoader protocol.  Currently,
navigations are ignored unless their reported sourceFrame is the main
frame.  However, this has the mistaken behavior of intercepting loads
that are initiated by the main frame, but are intended for a subframe.
Additionally, the current implementation will not intercept navigations
triggered by JavaScript (e.g. setting window.location to a new URL), as
these are reported as having a nil sourceFrame, but the main frame as the
targetFrame.  Since the same-origin policy is enforced by WebKit before
WKWebView navigation callbacks can occur, we can assume that an
navigation with the main frame as the targetFrame are valid and should be
intercepted.

BUG= 695262 

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

[modify] https://crrev.com/0f799230c0f27e3e8882868f46d9d5cefe9c8c6d/ios/chrome/browser/ui/static_content/static_html_view_controller.mm

This bug requires manual review: Less than 6 days to go before AppStore submit on M57
Please contact the 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

Please add some testing instructions about any interstitial page or any page that use this StaticHtmlViewController to make sure we are not breaking anything.

Can we test this on the latest canary?

Verified in 59.0.3031.0 Canary, iPhone 6S iOS 10.3, iPad mini 10.3

Page reloads, Looks good.

This fix can be tested using the steps in the original bug.

Some other things that might be useful to check since they are affected by this code.  In these situations, the link navigation should be intercepted and loaded in the main browser content area:
- Tapping on links in SSL interstitials (e.g. expired.badssl.com)
- Tapping on links in Reading List pages

shbarezer@ please do some additional testing based on  kkhorimoto@'s comment#25.

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

commit c3abab806f8c5229858939f767511d2c5dec9641
Author: Kurt Horimoto <kkhorimoto@chromium.org>
Date: Tue Mar 07 05:06:23 2017

Use targetFrame to decide whether to allow load in static html view.

StaticHtmlViewController intercepts attempted main frame navigations
and performs the load using the UrlLoader protocol.  Currently,
navigations are ignored unless their reported sourceFrame is the main
frame.  However, this has the mistaken behavior of intercepting loads
that are initiated by the main frame, but are intended for a subframe.
Additionally, the current implementation will not intercept navigations
triggered by JavaScript (e.g. setting window.location to a new URL), as
these are reported as having a nil sourceFrame, but the main frame as the
targetFrame.  Since the same-origin policy is enforced by WebKit before
WKWebView navigation callbacks can occur, we can assume that an
navigation with the main frame as the targetFrame are valid and should be
intercepted.

BUG= 695262 

Review-Url: https://codereview.chromium.org/2728243002
Cr-Commit-Position: refs/heads/master@{#454723}
(cherry picked from commit 0f799230c0f27e3e8882868f46d9d5cefe9c8c6d)

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

[modify] https://crrev.com/c3abab806f8c5229858939f767511d2c5dec9641/ios/chrome/browser/ui/static_content/static_html_view_controller.mm

Verified in 59.0.3033.0 Canary, iPhone 6S iOS 10.3, iPad mini 10.3
- Browsing to non-existing site
- Tapping on links in SSL interstitials (e.g. expired.badssl.com)

Pages reload on tapping the Reload button on various error pages.

- Tapping on links in Reading List pages - Reload button is working on the first try only( 697470 was filed)

Verified on chrome 57.0.2987.96 dev, on iPhone 6+ 10.2.1, Page reloads when tapped on the reload button.  

This issue is fixed and verified in M59 and M57 but not in M58
Issue is still reproduced in M58 only. (M58.0.3029.23 beta)
Can you check if the fix needs tobe merged into 58 as well?

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

commit 042bf70b4c3a621423770ab3ff4750537e4a0356
Author: Kurt Horimoto <kkhorimoto@chromium.org>
Date: Tue Mar 21 18:32:22 2017

Use targetFrame to decide whether to allow load in static html view.

StaticHtmlViewController intercepts attempted main frame navigations
and performs the load using the UrlLoader protocol.  Currently,
navigations are ignored unless their reported sourceFrame is the main
frame.  However, this has the mistaken behavior of intercepting loads
that are initiated by the main frame, but are intended for a subframe.
Additionally, the current implementation will not intercept navigations
triggered by JavaScript (e.g. setting window.location to a new URL), as
these are reported as having a nil sourceFrame, but the main frame as the
targetFrame.  Since the same-origin policy is enforced by WebKit before
WKWebView navigation callbacks can occur, we can assume that an
navigation with the main frame as the targetFrame are valid and should be
intercepted.

BUG= 695262 

Review-Url: https://codereview.chromium.org/2728243002
Cr-Commit-Position: refs/heads/master@{#454723}
(cherry picked from commit 0f799230c0f27e3e8882868f46d9d5cefe9c8c6d)

Review-Url: https://codereview.chromium.org/2763793003 .
Cr-Commit-Position: refs/branch-heads/3029@{#336}
Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471}

[modify] https://crrev.com/042bf70b4c3a621423770ab3ff4750537e4a0356/ios/chrome/browser/ui/static_content/static_html_view_controller.mm

Verified the issue on the build 58.0.3029.39 beta tested on iPhone SE(iOS 10.3).
Tapping on Reload on Error pages reloads the page,works fine.