OS version:macOS sierra 10.12.6

If you want to keep this state for a longer time,you can delay doing clearIntercal.

For example:

setTimeout(function(){
    clearInterval(b);
},80000);

I cannot reproduce any badness here-- can you attach a video (QuickTime can record one) showing what you see? Does the effect last longer than 4 seconds?

OK,this effect can last langer than 25 seconds,here is the video:

Deleted: 2017-08-01 00-11-24.mp4 10.2 MB

	2017-08-01 00-11-24.mp4 10.2 MB View Download

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

This has the same symptoms of  Issue 734298 , but without the caveats that made that one "Won't Fix"able.

Ken, can you take a look?  I suspect this might be a duplicate of  issue 739621 , which you just landed a fix for last week.  In that bug, the 4-second visual reset timer wasn't effective on Mac, and your fix made it more effective.

In my local tests, this seems to be Mac specific, and I see the unresponsive spoof text visible for more than 4 seconds on Chrome 59.0.3071.115 and 60.0.3112.78.  However, on today's Canary (62.0.3172.0), I only see the spoof text stick around for 4 seconds.  That suggests Ken's r489942 (which landed in 62.0.3169.0) might have resolved this.

This isn't a dupe of  issue 739621 , that one related to a page being hidden with the timer fired.

 Issue 734298  is probably more relevant, because it is trying to load apple.com on port 82, and then doing a document.write while the navigation is pending.

Charlie, do you know if any relevant navigation behavior changed? I think this repro doesn't work on Canary because it is successfully loading apple.com, so the trick with the invalid port number fails to circumvent the timer.

Hmm, maybe PlzNavigate is affecting it?  It's enabled for 50% of Canary, so maybe that's affecting whether the apple.com navigation succeeds.

We do have a different handling of cancelling navigations when doing a document.write in PlzNavigate. Browser-initiated navigations will never be cancelled, whereas in the current architecture the provisional load of a same-process browser-initiated navigation can be cancelled by a document.write on the current document.

Hmm, I can't repro this on Canary or trunk, even with PlzNavigate manually disabled in flags.

I think this must have been fixed at some point since M60, but I can't see any obvious candidate changes that might have done it. I've verified it isn't related to my recent timer change.

I ran a bisect on this and it no longer repros as of r481449, which is on the m61 branch.

I'm not clear on exactly how it fixes the issue, since it just means the new tab will be throttled by default when it is started. I can speculate that the throttling timer might be interacting with the compositor lock behavior that was already known to be causing problem with the new content timer on Mac, fixed in r489942.

Since there no longer seems to be a bug here, I am duping into 739621, given that there is a reasonable likelihood of these being related.

1.
r489942 is pushed at Jul 27,2017.
r481449 is pushed at Jun 21,2017,you say "it no longer repros as of r481449",so it can't be fixed by r489942 which pushed at July.

2.
You also do not know whether it was fixed by  issue 739621 ,why duplicate?

3.
And it is on the m61 branch,but stable m60 is still vulnerable.

So I don't agree with this result,could you please take a look again?

This isn't a high-severity vulnerability, so we won't be merging any fix to the m60 branch, which is already on Stable channel. The change that causes your test case to fail to repro will ship in m61 in a few weeks.

481449 breaks the repro case because it makes it so that apple.com always loads instead of the text from document.write. I believe the underlying problem, which caused the timer to stop working that is supposed to blank the stale content, was fixed in r489942. Since this problem was already fixed before it was submitted, duplicating it to a similar bug is correct.

If you can find a way to make this behavior recur on Canary, then please file another bug. I did look at that yesterday for a bit but couldn't find any tweaks that worked.

Regarding comment #19, there is no violation of same origin policy in any of these cases. The problem is strictly a visual one, because attacker-supplied content is being displayed even after a navigation to another site has committed. The attacker's page has been unloaded from the renderer, but we don't erase its graphics from the viewport in order to have a smooth transition between pages on navigation.

We are aware of these problems in general, and our defense is to give the new page (apple.com in this case) 4 seconds to render after its URL appears in the omnibox. If the 4 second timer expires then the display goes all white.

While we had not previously considered your specific approach, it looks like it was hitting some underlying problems that have since been fixed.

Comment 17 is consistent with my current understanding here. The video you supplied shows the 4-second timer working correctly. If you can find a way to make the spoofed content show under the wrong URL for arbitrary times then I would consider that a new bug -- I note that on m60, your original test case would sometimes show the spoof for 15 seconds, which means the timer was failing on those cases.

OK,thank you for the detailed explanation to comment #19.

And it seems that I have understood your description for "4-second timer",do you have noted this on m60?

In this case，I am going to disclose this report publicly,is it OK?

The decision of how and when to disclose a bug that you found is your own, but for the sake of protecting Chrome users we would appreciate if you would consider waiting until M61 ships before making your find public. That is scheduled to happen in early September.

Thank your for submitting this bug to us in the first place and we hope you will continue to do so for future security flaws you find in the browser.

ok，and could you help me to review this report https://bugs.chromium.org/p/chromium/issues/detail?id=698537?

there has been no update on it for a long time.

Hi,Ken,A small question:have you ever test this case in Chrome for iOS,because iOS chrome cannot install M61+,not be released.

Chrome for iOS is built on top of Apple's web APIs, and therefore doesn't have much in common, internally, with Chrome on other platforms. If this or a similar issue were to exist there then it would be an entirely separate bug, and would have to be fixed by Apple.

OK,get it!thank you

In the release update that you linked in comment 29 there is a bug fix related to URL spoofing using internationalized domain names. That bug was opened for public access a couple of weeks ago, if you click through.

Hi Ken,
   
   I have already know the reason for my question,because IDN vulnerability will affects multiple versions.It's an issue in blink

   And I'm sorry to take your time,thank you for your patience.

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