Hi, thanks for the report.  I'm not able to repro this (on M60/mac).  This opens a new tab to example.com, and then that tab navigates to http://testathost.blogspot.com/ (blank), but I see no bug with that. Can you explain what is not WAI?

Attached, please look

Deleted: 2017-04-17 at 11-56-52.mp4 663 KB

	2017-04-17 at 11-56-52.mp4 663 KB View Download

Thank you for providing more feedback. Adding requester "nparker@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

I /think/ this is something that we addressed recently; someone in the navigation space (+creis) probably knows more.

I believe the relevant part of this repro is that the target "testathost.blogspot.in" site has this script at the top:

  <script>
    window.stop();
  </script>

I cannot reproduce ANY badness at all in Chrome 60 on Windows.

In Chrome 57 on Windows, I do get a repro, but it's quite limited in scope. To repro, you must allow the navigation to "testathost.blogspot.in", then *immediately* switch to another tab for a few seconds, then switch back to the repro tab. When you do that, we show the prior/incorrect markup. If you stay on the repro tab without switching, the whole thing paints in gray after about four seconds, but if you switch tabs and switch back, it shows the prior/incorrect markup. Note that it's a "dead" image-- the user cannot select content in the markup or otherwise interact with it, limiting exploitability to out-of-band attacks ("Call this number immediately!"). Another gating factor is that the victim (whose domain you want to spoof) needs to be delivering the window.stop() call.

Deleted: Badness.png 22.5 KB

	Badness.png 22.5 KB View Download

Thanks elawrence. I'm pretty convinced this is not a useful attack given the gating factor you cited. creis -- if this points a larger issue, feel free to reopen.

Oops, and I meant add: Marking WontFix since it's already fixed in M60, and not worth merging.

Thanks for providing the feedback. I think this attack although limited in scope is still page content spoof and can be used to trick the user and therefore should be patched. Also we have just received update of chrome to version 58 from 57 on which I reported this bug and chrome version 60 will take some time, there if possible it should be patched for chrome 58. Also there is little change for this bug behavior on chrome 58, where the page content changes however the title remains the same.

From the behavior described in comment 6, this sounds like a duplicate of  issue 672847 , which was fixed in M58.  Fixed here means we expect the page content to disappear in 4 seconds, and not come back if the user switches tabs and comes back.  That's what I'm seeing on M58.

Ken, can you confirm?  (This is already closed, but I think marking it a duplicate of the fixed bug may be more accurate than WontFix.)

Correct, it is a duplicate.

#9: The omnibar updates with the new URL when the old page has been unloaded from the renderer, even though you can still see the graphics on from the original page. Usually the new page paints within a fraction of a second so the omnibar update looks simultaneous, but there are ways to prevent it from ever painting (such as what your test case does). In that case we evict the old graphics after 4 seconds, showing blank.

The trick about switching active tabs to make the graphics reappear was fixed in 58.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

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