FYI, it works in ALL other browsers.

Unable to reproduce the issue on mac 10.13.3 and mac 10.12.6 using chrome reported version #66.0.3359.181 and latest canary #68.0.3438.0.

Attached a screen cast for reference.

Following are the steps followed to reproduce the issue.
------------
1. Clicked the link inside an iframe, which lead to a site on a different domain.
2. Called window.browser.back().
3. Observed that it navigated back in browser history as expected.

borisl@ - Could you please check the attached screen cast and please let us know if anything missed from our end. Also please check the issue on latest canary #68.0.3438.0 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not.

Thanks...!!

Deleted: 845923.mp4 2.0 MB

	845923.mp4 2.0 MB View Download

I am able to confirm and reproduce this issue in Chrome 67.0.3396.56 on Windows 10.  When attempting to use window.history.back() or window.history.forward(), nothing appears to happen when inside an iframe from a different domain.  The window.onpopstate event does not fire either.  

I've setup two sites, one on glitch.me with buttons wired up to back(), forward(), and pushState().  These buttons work fine when you view the site here:

https://young-road.glitch.me/

Now, when I embed https://young-road.glitch.me/ inside an iframe on jsfiddle, the forward/back buttons no longer work, and the onpopstate event never fires.  Here is a link to the jsfiddle with the embedded iframe:  

https://jsfiddle.net/9p3nh3aj/

We have a production application which is embedded in an iframe that uses the history API.  It is currently broken in Chrome, but works in all other browsers.  Please let me know if there is any other info I can provide.

krajshree, I think the reason window.history.back() worked in your screen cast was because you called that method on the top frame.  The issue happens when you try to call back() from within the iframe.  

I concur what erne suspicion. Sorry I wasnt clear in my description. The issue indeed occurs when you try calling those methods from within the iframe.

Thank you for providing more feedback. Adding the requester to the cc list.

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

Unable to reproduce the issue on mac 10.13.3 and mac 10.12.6 using chrome reported version #66.0.3359.181 and latest canary #69.0.3443.0 as per comment #4.

Attached a screen cast for reference.

Following are the steps followed to reproduce the issue.
------------
1. Navigated to https://jsfiddle.net/9p3nh3aj/
2. Opened dev tools console and clicked on window.history.back().
3. Observed that it navigated back in browser history.

borisl@ - Could you please check the attached screen cast and please let us know if anything missed from our end. A screen cast if provided from your end will be much helpful in understanding the issue.

Thanks...!!

Attaching screen cast

Deleted: 845923.mp4 1.5 MB

	845923.mp4 1.5 MB View Download

krajshree please try the example i've submitted with same steps, including the step in comment #6

Thank you for providing more feedback. Adding the requester to the cc list.

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

krajshree its important for the content of the iframe to be on a different domain then the iframe parent

japhet, any chance this is related to https://bugs.chromium.org/p/chromium/issues/detail?id=624061?

This appears to be fixed in The official production build for Windows (66.0.3359.181), but is still broken in the Beta build for Windows (67.0.3396.56) and on the Canary build for Windows (68.0.3440.7). 

It's possible this has been already addressed in future Canary builds, but this is the newest one I seem to have access to on Windows. 

Deleted: ChromeCanary68_0_3440_7.webm 1.2 MB

	ChromeCanary68_0_3440_7.webm 1.2 MB View Download

I've tried to disable FramebustingNeedsSameOriginOrUserGesture feature (using --disable-features - not sure if this is the right way) and the problem still reproed.  Therefore I am not sure if this is related to issue 624061 as suggested in #c13:
    $ out/rel/chrome --user-data-dir=$HOME/.chrome-history-back https://jsfiddle.net/9p3nh3aj/ --disable-features=FramebustingNeedsSameOriginOrUserGesture,site-per-process --disable-site-isolation-trials --no-sandbox

It seems to me that (at least at ToT) the root cause of the OOPIF problem is that ViewHostMsg_GoToEntryAtOffset message is subject to swapped-out filtering in SwappedOutMessages::CanSendWhileSwappedOut.  Printf-style debugging output with --site-per-process:
    $ out/rel/chrome --user-data-dir=$HOME/.chrome-history-back https://jsfiddle.net/9p3nh3aj/ --disable-features=FramebustingNeedsSameOriginOrUserGesture --site-per-process --no-sandbox
    ...
    [history.cc(178)] History::back
    [history.cc(190)] History::go; delta = -1; GetFrame() = 0x138613c63b40; GetFrame()->Client() = 0xad189981df8
    [local_frame_client_impl.cc(660)] LocalFrameClientImpl::NavigateBackForward; offset = -1; webview = 0x39fc36ab4010; webview->Client() = 0x1e6f46349b38
    [local_frame_client_impl.cc(668)] LocalFrameClientImpl::NavigateBackForward2; webview->Client()->HistoryForwardListCount() = 0; webview->Client()->HistoryBackListCount() = 4
    [render_view_impl.cc(1547)] RenderViewImpl::NavigateBackForwardSoon; offset = -1
and without --site-per-process:
    $ out/rel/chrome --user-data-dir=$HOME/.chrome-history-back https://jsfiddle.net/9p3nh3aj/ --disable-features=FramebustingNeedsSameOriginOrUserGesture,site-per-process --disable-site-isolation-trials --no-sandbox
    ...
    [history.cc(178)] History::back
    [history.cc(190)] History::go; delta = -1; GetFrame() = 0x40349eea50; GetFrame()->Client() = 0x364c3f90aac0
    [local_frame_client_impl.cc(660)] LocalFrameClientImpl::NavigateBackForward; offset = -1; webview = 0x252a3acb4010; webview->Client() = 0x1a8438e52b38
    [local_frame_client_impl.cc(668)] LocalFrameClientImpl::NavigateBackForward2; webview->Client()->HistoryForwardListCount() = 0; webview->Client()->HistoryBackListCount() = 3
    [render_view_impl.cc(1547)] RenderViewImpl::NavigateBackForwardSoon; offset = -1
    [web_contents_impl.cc(4258)] WebContentsImpl::OnGoToEntryAtOffset; offset = -1; delegate_ = 0x3ea4af658508
    [navigation_controller_impl.cc(693)] NavigationControllerImpl::GoToOffset; offset = -1
    [navigation_controller_impl.cc(660)] NavigationControllerImpl::GoToIndex; index = 2

I agree this is unlikely to be related to issue 624061, since comment #14 says this is broken on 67.0.3396.56, and per https://chromium.googlesource.com/chromium/src/+/67.0.3396.56/content/public/common/content_features.cc#133, framebusting is disabled in that build.

Also, if framebusting is at fault, you should see a "Redirect blocked" notification similar to a popup blocker notification.

FWIW, I can repro the same problem on 66.0.3359.181:

My repro steps:
1. Launch Chrome stable as follows:
    $ google-chrome-stable --user-data-dir=$HOME/.chrome-history-back2 https://jsfiddle.net/9p3nh3aj/ --disable-features=FramebustingNeedsSameOriginOrUserGesture --site-per-process
2. Click the "window.history.pushState()" button 3 times
3. Click the "window.history.back()" button 3 times.
   Observer that nothing happens (in particular the Current Location displayed
   in the iframe doesn't change).

This is slightly unexpected - this doesn't match ernesto@'s report in #c14.  OTOH, reproing the problem on M66 does match the #c0 comment from  borisl@ (which talks about 66.0.3359.181 just like #c14).

Tweaking the labels based on the observations in #c16 and #c17 - please shout if you disagree with the new labels and/or removal of some old labels.

ernesto@ can you please clarify how you attempted to repro the problem on M66 and M67?  Did you explicitly try to opt-into or out of Site Isolation?  Is it possible that you were accidentally enrolled into Site Isolation field trial in one case but not the other and this is what caused no-repro on M66?  (FWIW, Site Isolation field trial is enabled for 90% of the Beta population and 10% of the Stable/M66 population;  Site Isolation plans to launch to 100% in M67).

To force Site Isolation you can use the following cmdline switch: --site-per-process (or use chrome://flags/#enable-site-per-process).

To disable Site Isolation field trials you can use the following cmdline switch: --disable-site-isolation-trials (or use chrome://flags/#site-isolation-trial-opt-out).

lukasza@ I had a co-worker test it on 66 on his Windows 10 machine.  I don't think he has any special version of Chrome installed.  I'll install 66 on my machine and check if site-per-process is enabled.  

Also note I had some one else test on 66.0.3359.170 and they were able to reproduce the problem.  Then I asked them to update to 66.0.3359.181, and it fixed the problem for them.  I'll see if they can check if they have site-per-process enabled.  

WIP CL @ https://crrev.com/c/1076326

lukasza@ I had my friend running 66.0.3359.181 enable Strict site Isolation manually via chrome://flags/#enable-site-per-process, and he was able to reproduce the problem.  So presumably the 10% that have been opted into the trial are experiencing this issue.  

What's strange though is that Strict Site Isolation is disabled on my Beta build (67.0.3396.56) and on my Canary build (68.0.3440.7), and yet I experience the bug in both builds.  Both of those builds have "Site isolation trial opt-out" set to "Default".  

Some things that I've discussed with creis@:

A) I mentioned that the repro at https://jsfiddle.net/9p3nh3aj/ doesn't respond in the same way to 1) the Chrome/top back button as 2) the |subframe| button / history.back().  There is nothing to worry about here - this is just an artifact of how the repro page is set-up (|currLoc.innerText| is only updated in response to clicking the buttons in the subframe, not to history state updates).

B) Whether the behavior should exactly match Firefox.  Repro steps (Chrome/ToT behavior is the same with/without Site Isolation after the CL from #c21):
    1. Navigate to https://jsfiddle.net/9p3nh3aj/
    2. In the subframe click the |window.history.pushState| button 3 times
    3. In the subframe click the |window.history.back| button 1 time
       Observe:
       - Firefox: the Current Location span in the subframe gets updated and shows the previous URL
       - Chrome: nothing happens
    4. In the subframe click the |window.history.back| button 1 more time
       - Firefox and Chrome: the Current Location span in the subframe gets updated and shows the previous URL

I don't really understand B, but I assume that matching the behavior without Site Isolation is good enough.  creis@ - could you please confirm that?  Is there a need to investigate this discrepancy further and open a new bug if needed?

I can confirm that in 67.0.3396.62, after Opting out of Site isolation trial opt-out under
chrome://flags/#enable-site-per-process the history.go(-1) behaves as expected again while inside the iframe.  my repro steps are recorded in what appears to be a duplicate bug report at: https://bugs.chromium.org/p/chromium/issues/detail?id=814355

Thanks for the reports, and to lukasza@ for finding the root cause!  Agreed that this is a case where Site Isolation is causing problems with history.back(), since the IPC isn't getting delivered from an out-of-process iframe.

Comment 22: The chrome://flags page won't indicate if your instance of Chrome has Site Isolation enabled via a field trial, only whether you've enabled it manually.  The easiest way to check is to simply look in Chrome's Task Manager and see if there are subframe processes for cross-site iframes (per https://www.chromium.org/Home/chromium-security/site-isolation#TOC-Verifying).  In this case, all the signs are consistent with the bug being due to the Site Isolation trials.

Comment 23: That test page is updating the "current location" value too soon-- at the point the history navigation was initiated, rather than after it commits.  This means it's always showing a stale value (which you can confirm by visiting https://young-road.glitch.me/ in the main frame in Chrome).  It's likely this is a difference from Firefox, due to Chrome's asynchronous history navigations.  I think it would work if it used popstate, as the attached modified repro should show. 

Deleted: pushstate-repro.html 1.2 KB

pushstate-repro.html 1.2 KB View Download

 Issue 814355  has been merged into this issue.

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

commit 2f721d639689e6b3b1ee586ad049435a37ab2f2a
Author: Lukasz Anforowicz <lukasza@chromium.org>
Date: Tue May 29 22:17:38 2018

Support |history.back()| (and similar APIs) in OOPIFs.

This CL pokes a hole for ViewHostMsg_GoToEntryAtOffset in
SwappedOutMessages::CanSendWhileSwappedOut.  This fixes an issue where
|history.back()| and similar calls in an OOPIF would be filtered/lost
instead of being processed in the browser process.

In addition to running automated regression tests (including the new
test being added in this CL), I've also tried the following manual test
steps (step 5 is broken before this CL and working after this CL):
1. Launch Chrome with --site-per-process
2. Navigate to https://jsfiddle.net/9p3nh3aj/
3. In the subframe click the |window.history.pushState| button 3 times
4. In the subframe click the |window.history.back| button 1 time
   Observe that nothing happens (the same behavior is observed
   with and without Site Isolation)
5. In the subframe click the |window.history.back| button 1 more time
   Observe that the Current Location span in the subframe gets updated
   and shows the previous URL.

Bug:  845923 
Change-Id: I8fa9aeb70d282d963e0ba8224d16c24690aaa518
Reviewed-on: https://chromium-review.googlesource.com/1076326
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/heads/master@{#562627}
[modify] https://crrev.com/2f721d639689e6b3b1ee586ad049435a37ab2f2a/content/browser/frame_host/navigation_controller_impl_browsertest.cc
[modify] https://crrev.com/2f721d639689e6b3b1ee586ad049435a37ab2f2a/content/common/swapped_out_messages.cc

Let's verify the fix in the next Canary - the fix will most likely be present in 69.0.3445.0

The NextAction date has arrived: 2018-05-30

Will the feature still be exposed to 100% in Chrome 67, despite the issue. What is the expected date for a release of the fix?

 Issue 847820  has been merged into this issue.

Commit 2f721d63... initially landed in 69.0.3445.  I've verified in 69.0.3445 (on a Windows Canary) that the fix works as expected (e.g. I could no longer repro the issue using the https://jsfiddle.net/9p3nh3aj/ page).  Let me request a merge to M67 and M68:

Safety of the fix:
  - The fix just adds 1 line to content/common/swapped_out_messages.cc,
    adding one more case to a switch statement
  - The impact of the 1 line change seems well understood - the handler
    of the IPC that will now go through should be able to handle the IPC
    in exactly the same way as if it came from the main frame (e.g.
    the behavior doesn't depend on which frame sends the IPC;  additionally
    the IPC only contains a single value in the payload - the history offset)
  - I've looked at Crash reports and there were none containing either
    CanSendWhileSwappedOut nor OnGoToEntryAtOffset in the callstack

Desirability of the fix:
  - Without the fix |history.back()| and similar APIs doesn't work at all in
    OOPIFs.
  - It is a bit unclear right now how widespread the impact of this bug may be,
    but it seems likely that it might become a blocker for shipping Site Isolation
    to 100% of the Stable channel.
  - FWIW, so far we got 3 reports from the wild (this bug,  issue 847820 ,  issue 814355 
    back in February), so users are hurt by this issue and actively reporting it
    despite the fact that Site Isolation rollout has been less than 10% of the population
    so far (we've ramped up from 5% to 10% only 2 weeks ago).

I've wondered whether additional bake time on M68 Beta might be desirable and I don't think so:
- The extra bake time will negatively impact users being covered by the Site Isolation roll out
- Given the simplicity of the fix, I think the extra bake time is unlikely to uncover issues
  that should block the merge

This bug requires manual review: Request affecting a post-stable build
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

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

Including abdulsyed@ as well for M68 merge request.

I can also confirm the bug is fixed on 69.0.3445.0 when using the steps for https://jsfiddle.net/9p3nh3aj/, as well as with the following repro steps:

1) Start Chrome with Site Isolation enabled.
2) Visit http://csreis.github.io/tests/cross-site-iframe.html
3) Click "Go cross-site (simple page)"
4) Open DevTools and select the "csreis.github.io/" subframe in the Console.
5) Enter "history.back()" into the console.
"Initial page" is visible as expected in 69.0.3445.0, unlike in 67.0.3396.62 or 68.0.3438.3.

I agree that the fix is very safe and is important to include in M67 and M68.

For reference, I've also patched r562627 into my local M67 branch and confirmed that it fixes the bug and passes the test there as well.

Approving merge to M67 branch 3396 based on comments #32, #34 and #35. Pls merge so we can pick it up for next M67 stable respin (if any) for Desktop. Thank you.

abdulsyed@, can you please confirm that it is okay to also go ahead with a merge to M68?

Branch:3440

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

commit 602a6e98438b0fa94dcfec01f72ce151a373cd94
Author: Lukasz Anforowicz <lukasza@chromium.org>
Date: Wed May 30 17:13:36 2018

Support |history.back()| (and similar APIs) in OOPIFs.

This CL pokes a hole for ViewHostMsg_GoToEntryAtOffset in
SwappedOutMessages::CanSendWhileSwappedOut.  This fixes an issue where
|history.back()| and similar calls in an OOPIF would be filtered/lost
instead of being processed in the browser process.

In addition to running automated regression tests (including the new
test being added in this CL), I've also tried the following manual test
steps (step 5 is broken before this CL and working after this CL):
1. Launch Chrome with --site-per-process
2. Navigate to https://jsfiddle.net/9p3nh3aj/
3. In the subframe click the |window.history.pushState| button 3 times
4. In the subframe click the |window.history.back| button 1 time
   Observe that nothing happens (the same behavior is observed
   with and without Site Isolation)
5. In the subframe click the |window.history.back| button 1 more time
   Observe that the Current Location span in the subframe gets updated
   and shows the previous URL.

TBR=lukasza@chromium.org

(cherry picked from commit 2f721d639689e6b3b1ee586ad049435a37ab2f2a)

Bug:  845923 
Change-Id: I8fa9aeb70d282d963e0ba8224d16c24690aaa518
Reviewed-on: https://chromium-review.googlesource.com/1076326
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#562627}
Reviewed-on: https://chromium-review.googlesource.com/1079385
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/branch-heads/3396@{#720}
Cr-Branched-From: 9ef2aa869bc7bc0c089e255d698cca6e47d6b038-refs/heads/master@{#550428}
[modify] https://crrev.com/602a6e98438b0fa94dcfec01f72ce151a373cd94/content/browser/frame_host/navigation_controller_impl_browsertest.cc
[modify] https://crrev.com/602a6e98438b0fa94dcfec01f72ce151a373cd94/content/common/swapped_out_messages.cc

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

commit e79bc32e7d20d712ceda4ce8d68c717ab1048743
Author: Lukasz Anforowicz <lukasza@chromium.org>
Date: Wed May 30 17:16:02 2018

Support |history.back()| (and similar APIs) in OOPIFs.

This CL pokes a hole for ViewHostMsg_GoToEntryAtOffset in
SwappedOutMessages::CanSendWhileSwappedOut.  This fixes an issue where
|history.back()| and similar calls in an OOPIF would be filtered/lost
instead of being processed in the browser process.

In addition to running automated regression tests (including the new
test being added in this CL), I've also tried the following manual test
steps (step 5 is broken before this CL and working after this CL):
1. Launch Chrome with --site-per-process
2. Navigate to https://jsfiddle.net/9p3nh3aj/
3. In the subframe click the |window.history.pushState| button 3 times
4. In the subframe click the |window.history.back| button 1 time
   Observe that nothing happens (the same behavior is observed
   with and without Site Isolation)
5. In the subframe click the |window.history.back| button 1 more time
   Observe that the Current Location span in the subframe gets updated
   and shows the previous URL.

TBR=lukasza@chromium.org

(cherry picked from commit 2f721d639689e6b3b1ee586ad049435a37ab2f2a)

Bug:  845923 
Change-Id: I8fa9aeb70d282d963e0ba8224d16c24690aaa518
Reviewed-on: https://chromium-review.googlesource.com/1076326
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#562627}
Reviewed-on: https://chromium-review.googlesource.com/1079308
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/branch-heads/3440@{#45}
Cr-Branched-From: 010ddcfda246975d194964ccf20038ebbdec6084-refs/heads/master@{#561733}
[modify] https://crrev.com/e79bc32e7d20d712ceda4ce8d68c717ab1048743/content/browser/frame_host/navigation_controller_impl_browsertest.cc
[modify] https://crrev.com/e79bc32e7d20d712ceda4ce8d68c717ab1048743/content/common/swapped_out_messages.cc

RE: #c30: borisl@: Will the feature still be exposed to 100% in Chrome 67, despite the issue. What is the expected date for a release of the fix?

Because of https://crbug.com/848257#c17 the M67 roll-out won't proceed beyond the current 10%.  The next respin of M67 should include the fix from #c27.

Actually my #c41 might be incorrect - issue 848257 is specific to the Mac OS.  We are still evaluating how M67 is doing on Windows and may decide to proceed with M67 rollout on that platform.

So - the fix from #c27 will be included in the next M67 respin, but at this point 1) we can't promise when the respin will happen nor 2) when M67 rollout will proceed to 100%.

Just to update, I think we are expecting a respin on Win/Mac/Linux early next week (for other reasons), which should include this fix.

Thanks for the update.

Thank you guys! Waiting on an update regarding the respin

Thanks everyone for the updates and the quick turnaround. 

Good news: 67.0.3396.79 is now available with the fix on Chrome Stable.  You can force an update by visiting chrome://chrome.