Able to reproduce the issue on Windows 10, Mac 10.12.4 and Ubuntu 14.04 using reported version #58.0.3029.81 but the same is not reproducible in the latest canary #60.0.3081.0.

Reverse Bisect Information:
=====================
Good build: 59.0.3037.0  Revision(455955)
Bad Build : 59.0.3036.0  Revision(455621)

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/1e2d08a7fc2db1297a7f2a28c40659af534c309e..71e8d307789f1cf492f4803bdceab898e8105a47

From the above change log possible CL that fixed this issue:
Review-Url: https://codereview.chromium.org/2729523003

alexmos@ - Could you please check and merge the fix to M59 if it is a valid candidate.

Note: As it seems to be a recent regression hence, adding label ReleaseBlock-Stable.

Thanks...!!

Issue 715874 has been merged into this issue.

Adding creis@ (reviewer of the relevant CL) for possible further dispatch since alexmos@ appears to be out.

Oh!  I guess  issue 697513  affected hosted apps as well (since Docs is installed by default as a hosted app), and not just data URLs to plugins.

That bug was introduced in r453800 (58.0.3027.0) and fixed in r455821 (59.0.3037.0).  This means the fix is already present in M59, but not M58.

govind@: Do you want to take this fix (r455821) for M58?  I haven't verified it locally, but I can try.

I am able to reproduce this issue in latest M58 -58.0.3029.81, but works fine in all other channels.

Not sure how critical the bug is, able to repro only withe the sample testcase.

Works fine for the below spreadsheets.

https://spreadsheets1.google.com/a/highvolumeseller.com/viewform?authkey=CPzniLkO&formkey=dGRncWtmUnpxaWtQaVZDeWJ5Szd4NVE6MQ

https://docs.google.com/a/storefrontpro.com/spreadsheet/viewform?formkey=dDhSaUxHeHc1cjdEY2w2QS1QMVpvOHc6MA

Adding RBS for tracking purpose.

Similar bug: https://bugs.chromium.org/p/chromium/issues/detail?id=710668

Ok, it looks like  issue 697513  did affect redirects to hosted app URLs.  This apparently also caused issue 710668, where Google Calendar is failing to load in an iframe, presumably due to a redirect to Google Calendar, which is also default installed as a hosted app.

The impact of this is that all redirects to hosted app URLs in iframes will not work on M58.  The "spreadsheets.google.com" and "spreadsheets1.google.com" URLs redirect to docs.google.com, so they're affected.  https://docs.google.com/a/storefrontpro.com/spreadsheet/viewform?formkey=dDhSaUxHeHc1cjdEY2w2QS1QMVpvOHc6MA isn't affected because it doesn't redirect, but if you change "docs" to "spreadsheets", it does redirect and is affected.

Given the number of default installed hosted apps, we should definitely merge the fix to M58.  The fix itself has been baking on M59 since March 9 and is small and targeted, so I think it should be low risk.

I'm currently trying to reproduce the bug on a trunk build with the fix reverted, just to manually confirm the CL is exactly what we need.  No luck so far, but it does seem like this is the right CL.

Issue 710668 has been merged into this issue.

+ bhthompson@ as issue 710668 was reported on Chrome OS.

I'm building an M58 branch now to use for confirming the fix.

For reference, here's a few more details for understanding the bug:

It looks like "apdfllckaahabafndbhieahigkjlhalf" is the default-installed hosted app for docs.google.com URLs, and "ejjicmeblgpmajnghnpcppodonldlgfn" is the Google Calendar hosted app.

More explicit repro steps:
1) Start Chrome 58 and be sure that PlzNavigate is not enabled.  (There is a BrowserSideNavigation field trial on Canary and Dev which may affect your repro steps.  Use --force-fieldtrials=BrowserSideNavigation/Control to ensure it is disabled.)
2) Ensure the Google Drive hosted app is installed from https://chrome.google.com/webstore/detail/google-drive/apdfllckaahabafndbhieahigkjlhalf.  (Click "Add to Chrome" if it's there.  If it just says "Visit Website," it's already installed.)
3) Visit https://csreis.github.io/tests/cross-site-iframe.html
4) In the DevTools console, run:
navFrame("https://spreadsheets.google.com/a/highvolumeseller.com/spreadsheet/viewform?formkey=dFVyb1RYcHNsdHlsWTdaWVdxZktjenc6MA#gid=0")

It will spin instead of loading the URL.

My local M58 build has finished, and I can confirm the bug without Alex's r455821 using the steps in comment 11.  When I apply r455821, the bug is fixed.

Shall I merge it?

 Issue 716056  has been merged into this issue.

Approving merge to M58 branch 3029 based on internal group chat and comment #8 & #12.

Merge landed.  I had the old bug number on it, so it didn't get posted here.  Copied below:

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

commit 0454f5814f0bcd28398d93ec6700fc34adae20a0
Author: Charles Reis <creis@chromium.org>
Date: Fri Apr 28 17:17:15 2017

Fix transfers for data URLs with plugin mime types.

Typically, when a local frame navigates to a data URL, the request is
serviced in the renderer without going up to the browser process.
However, this isn't true for some data URLs, such as those with plugin
mime types.  Those go up to the browser, where they stalled due to
conflicting logic that first decided that a transfer is needed, marked
the current RFH as transferring, but then decided that a process
transfer isn't allowed and kept the load in the current RFH.

When the process transfer is prevented by CanSubframeSwapProcess, the
load will always stay in the current RFH.  This CL tries to recognize
scenarios where this happens for transfers that also starts in the
current RFH, so that we can avoid calling Transfer() for the current
RFH unnecessarily.

BUG=  697513  
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Review-Url: https://codereview.chromium.org/2729523003
Cr-Commit-Position: refs/heads/master@{#455821}
(cherry picked from commit 71e8d307789f1cf492f4803bdceab898e8105a47)

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

[modify] https://crrev.com/0454f5814f0bcd28398d93ec6700fc34adae20a0/content/browser/frame_host/render_frame_host_manager.cc
[modify] https://crrev.com/0454f5814f0bcd28398d93ec6700fc34adae20a0/third_party/WebKit/LayoutTests/FlagExpectations/site-per-process

Issue 713896 has been merged into this issue.

Verified the issue on Mac os 10.12.3 , windows 7 and ubuntu 14.04 using chrome M58 #58.0.3029.96 and issue seems fixed and followed below steps to verify :

1. Saved the provided code in comment #0 into a html file and launched it in chrome.
2. Observed the url loaded in the iframe.

Attached screencast for reference.

Adding TE-Verified labels.

Thanks!

Deleted: 715756.mp4 617 KB

	715756.mp4 617 KB View Download

Thank you creis@ for fixing the bug. 
Requesting a postmortem for this issue. Please see go/chrome-postmortems for the process to follow.

Hi team,

Any idea when the 58.0.3029.96 refresh will land Chrome OS?

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

commit c1a9cc5af57748545858620aab0e9cd8e24dcc93
Author: alexmos <alexmos@chromium.org>
Date: Fri May 19 00:12:53 2017

Add a test for subframes redirecting to hosted app URLs.

We recently had a regression that reached stable channel because we
had no tests for loading subframes that redirect to hosted app URLs.
This CL adds test coverage for that case.

BUG= 721949 ,  715756 

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

[modify] https://crrev.com/c1a9cc5af57748545858620aab0e9cd8e24dcc93/chrome/browser/ui/extensions/hosted_app_browsertest.cc