Tested the issue on windows 7 using chrome version 58.0.3029.54 with the below steps
1.Access to https://lo.lacaixa.es
2.Select language "English"
3.Click "Demo version"
4.Click "Accept and continue"
5.Click upper option "Mobile"
6.Click right option "Línea Abierta SMS"
7.Open Developer tools, Network option.
8.Click "data modification"
9.Here not able to see the accounts page 

Could you please find the attached screen cast and confirm if anything missed here.please clarify from step 9.
Also please try the issue on latest beta and if the issue still persists please provide us OS details to triage the issue further.

Thanks,

Deleted: 710008.mp4 4.0 MB

	710008.mp4 4.0 MB View Download

You have reproduced the issue in step 9 (I advanced in my first message the error sometimes occurred in step 8).
As it is clear in the video, the when you click "data modification" the call appears as "(canceled)" in the Network" Tab. This doesn't happen in other browsers, nor in the current Chrome 57.

Could you please review the reason of this error?
Thanks!

Thank you for providing more feedback. Adding requester "kavvaru@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

There is another situation in which we obtain the same error, although it could have different reasons:
You can reproduce it with the following steps:

1.Access to https://lo.lacaixa.es
2.Select language "English"
3.Click "Demo version"
4.Click "Accept and continue"
5.Click the wheel icon (the third rightmost icon in the top, with the alt "Configuration")
6.Click "CaixaBankProtect telephone management"
7.Click "Registration or management of the CaixaBankProtect telephone no."
8.Click "or in a new one", just afther the text where a phone number is shown.
9.The resulting page is a frameset. One of the frames is cancelled.

The website is based in framesets. We believe it has to do with some new restriction in Chrome 58 regarding to frame calls. Could you review having this fact in account?

Thanks in advance,
Ramon

Thanks for the update.
Tested the issue again on Windows 7 using the steps from comment #4.

1.Access to https://lo.lacaixa.es
2.Select language "English"
3.Click "Demo version"
4.Click "Accept and continue"
5.Click the wheel icon (the third rightmost icon in the top, with the alt "Configuration")
6.Click "CaixaBankProtect telephone management"
7.Click "Registration or management of the CaixaBankProtect telephone no."
8.Click "or in a new one", just after the text where a phone number is shown.
9.The Page is shown and observed some error message in console.

Could you please find the attached screen cast and confirm what is the expected behaviour after 9.If possible please provide us expected screen shot or video will help us for better triaging the issue.

Thanks,

Deleted: 710008.mp4 3.5 MB

	710008.mp4 3.5 MB View Download

Hi.
If you open the Network tab before the last click you will see the complete behavior of the page. 
I attach a file with the instructions I followed, but in any case, I recommend doing the same test you report in your video with the Network tab active.

Thanks

Deleted: chrome58_bug.zip 198 KB

chrome58_bug.zip 198 KB Download

Thank you for providing more feedback. Adding requester "kavvaru@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Thanks for the update.

Now finally am able to reproduce the issue on windows 7 using chrome 58.0.3029.54.Able to see the cancelled frame in network panel.
Working on bisect will provide the update soon.

Thanks,

Deleted: 710008.png 206 KB

	710008.png 206 KB View Download

Able to reproduce the issue on windows 7, Ubuntu 14.04 using chrome version 58.0.3029.54 and canary 59.0.3069.1.
This is regression issue broken in M58. Please find the bisect information as below
Narrow Bisect::
Good:: 58.0.3013.0  --    (build revision 450530)
Bad:: 58.0.3014.0  ---    (build revision 450840)

change Log::
https://chromium.googlesource.com/chromium/src/+log/183dc82ce88ae08056adfcc97e48937c0fe1be59..04fdd09f342badeb2af3a639d62a4da65d4baaa1

Possible suspect::
https://chromium.googlesource.com/chromium/src/+/04fdd09f342badeb2af3a639d62a4da65d4baaa1

davidsac@ Could you please look into this issue if it is related to your change,else please help us in finding the appropriate owner for this issue.

Thanks,

Hi,
We confirm from CaixaBank that calls between frames have the same url (the information that makes every call to work differently travels in POST area). Anyway, I'm not sure if it fits with this issue.

Specific information that might help to diagnose it:
- When we create the frameset, it calls two different urls that work propperly.
- When there is a js call from one frame to submit information in the other, this call is cancelled.

If it fits with this issue, we'd appreciate information about the expected schedule of resolution.
Thanks!

Any news about this issue? We are very concerned about the effect it has in our website and would appreciate more information about it's resolution expected date.

Thanks,
Ramon

Hmm, I guess this is because of the improved nested iframe blocking.

The requested URL that's blocked is:
https://loc4.lacaixa.es/GPeticiones;WebLogicSession=LysnYvvQP5DtF6pQGf8Z7hbXYwg2MpZ7Q3QmvKlQyBgGmJ8yDQs1!471800827!-38559312

with an initiator of
https://loc4.lacaixa.es/GPeticiones;WebLogicSession=LysnYvvQP5DtF6pQGf8Z7hbXYwg2MpZ7Q3QmvKlQyBgGmJ8yDQs1!471800827!-38559312?PN=SMS&PE=1&CLICK_ORIG=RED_SMS_0&RefNumeroCuenta=&RefNumeroTarjeta=&TELEFONO=&CLAVE_CUENTA=&CLAVE_TARJETA=&RefContinuacionCuenta=&RefContinuacionTarjeta=&NUMERO_CUENTA=&NUMERO_TARJETA=

In fact, many of the frames in this page appear to all have the same URL, ignoring the query string.

Yes, most calls in the website have the same url (the difference between calls is in the post area).
So there is an issue in the beta version you are working on?

Thanks

We previously had logic in Blink to block iframe loads of the same URL nested more than 2 levels deep.

We moved this logic into the browser to handle some cases that we missed before, such as redirects and OOPIFs: see  issue 650332  and  issue 527367 .

And which is next step? 
Are you working on changing this behaviour or do you intend to release it in new Chrome 58 version?

Thanks

I can confirm that this is due to the improved self-referential checks from r450728.  The checks actually take query strings into account, i.e., we won't block URLs with different query strings.  But this doesn't help here: the structure I see in the bottom part of the frame chain is

https://foo/bar.html
 +- https://foo/bar.html?some_query_params
    +- https://foo/bar.html
       +- navigates to https://foo/bar.html via POST <-- blocked

(where https://foo/bar.html is https://loc1.lacaixa.es/GPeticiones;WebLogicSession=GjHzYvycjzhKwSJgvNvX1cpvMLnN3GMzSD61VPyJGk3Btd8CQDh0!-1970735480!371744418)

This currently triggers the self-referential block, as the bottom frame is navigating to the same URL as two of its ancestors.

We definitely weren't aware of this use case.  I think we might need to skip these checks for POSTs; I'll see if I can fix that.  As a workaround in the meantime, you could include some different extra query string params in URLs of the affected frames.

Tentative fix up at https://codereview.chromium.org/2814413003.  I've verified that this fixes the problem on my local build.

Thanks for the investigation, Kalpana, please verify in canary once it lands. If all goes well merge to M58 ASAP.

FYI: M58 stable promotion is scheduled next week and RC cut on Monday 04/17.

Thanks for all the work and information! I confirm the fix you are working on would solve our problem (there's no problem on checking only the last page, I agree it makes no sense making get calls nested in previous pages requested by the same url in post).
Would you tell us when there is a beta with this issue fixed?

We've verified that the workaround you suggest also works. The problem is that there is a huge amount of pages in our homesite, all of them with the same url and parameters structures, and we would not have enough time to modify and test all of them is so short time.
We'll wait for the fix.

Thanks again,
Ramon

Thanks much for your report. This patch will be shipped to Beta users on Wednesday 04/19.

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

commit e49d7dfd68361fcdd6b83bb696fc475276afae8f
Author: alexmos <alexmos@chromium.org>
Date: Thu Apr 13 21:46:36 2017

Skip self-referential frame checks for POST requests.

The improved self-referential frame blocking in r450728 broke sites
that rely on constructing frame hierarchies where frames are loaded
via POSTs with the same URLs.  To fix this, skip POST requests in
self-referential URL checks.

Note that this only checks whether the current request is a POST, not
whether the ancestor frames were also loaded via POSTs.  The only case
where the latter would matter is if we've got two ancestors frames at
a same URL, with one or both of them loaded via POST, and the current
frame is loading that same URL via GET, which seems very unlikely to
happen in practice.

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

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

[modify] https://crrev.com/e49d7dfd68361fcdd6b83bb696fc475276afae8f/content/browser/frame_host/navigation_handle_impl.cc
[modify] https://crrev.com/e49d7dfd68361fcdd6b83bb696fc475276afae8f/content/browser/frame_host/render_frame_host_manager_browsertest.cc

We should be able to verify the fix from #21 in tomorrow's canary, and if it looks good, I'll merge it to M58 tomorrow.

Also, Daniel and I discussed an alternate approach, which is to only enforce self-referential checks on initial navigations in frames.  This takes care of POSTs, since a POST can't ever be an initial navigation in a frame, and maybe other cases that we aren't aware of.  However, in some cases it might be a bit too relaxed -- previously, self-ref navigations via a frame's 'src' attribute were blocked, but would now be allowed.  For reference, that CL is at https://codereview.chromium.org/2815413002.  I'm not planning on landing it now, but we might want to revisit it if there's any other fallout from tightened self-referential checks.

I've confirmed that the fix (r464556) works on Mac Canary 59.0.3071.0.  The fix also made it in before the branch cut.  Requesting merge to M58.  

Your change meets the bar and is auto-approved for M58. Please go ahead and merge the CL to branch 3029 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), 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/+/9302f10628d14eba1e0e8cf953813330b35f50c8

commit 9302f10628d14eba1e0e8cf953813330b35f50c8
Author: Alex Moshchuk <alexmos@chromium.org>
Date: Fri Apr 14 22:06:25 2017

Skip self-referential frame checks for POST requests (Merge to M58).

The improved self-referential frame blocking in r450728 broke sites
that rely on constructing frame hierarchies where frames are loaded
via POSTs with the same URLs.  To fix this, skip POST requests in
self-referential URL checks.

Note that this only checks whether the current request is a POST, not
whether the ancestor frames were also loaded via POSTs.  The only case
where the latter would matter is if we've got two ancestors frames at
a same URL, with one or both of them loaded via POST, and the current
frame is loading that same URL via GET, which seems very unlikely to
happen in practice.

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

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

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

[modify] https://crrev.com/9302f10628d14eba1e0e8cf953813330b35f50c8/content/browser/frame_host/navigation_handle_impl.cc
[modify] https://crrev.com/9302f10628d14eba1e0e8cf953813330b35f50c8/content/browser/frame_host/render_frame_host_manager_browsertest.cc

Verified the issue on Mac os 10.12.3 , ubuntu 14.04 and windows 7 using chrome beta M58 #58.0.3029.81 and followed the steps mentioned in comments #5 & 6 and issue is fixed.

All the frames in the page are loaded .

Attached screenshot for reference.

Adding TE-Verified labels.

Thanks!

Deleted: 710008.PNG 433 KB

	710008.PNG 433 KB View Download

Is the beta that solves this issue already available to download?
Thanks,

Not yet, It will be available by tomorrow if all goes fine.
Thanks,