Issue is also reproducible on Dev Build (52.0.2743.19)

Can reproduce, but I don't see how a renderer-level change to script-loading error handling can lock up the UI like that.

Reproduces with r381281 reverted.

Verified not to be r381278 either, but (speculating freely here) r381285 perchance?

Marking the above issue as RB-Stable as this needs to bisect before M53 goes to stable.

This is very unlikely to be r381285. 

r381285 is all about IPC messages that the cast receiver sends to the browser process. This receiver in Chrome is now only used by cast demo extension or testing. 

With response to comment #5: rebisected and found a different narrow bisect range
Narrow Bisect:
https://chromium.googlesource.com/chromium/src/+log/1fd3377af4f809442d49b63d10ba3467a64a27ff..974fa818537a8d00fb3537a836db79e2539a7889?pretty=fuller&n=1000

Suspecting: r381235?

@tdanderson: Kindly help to reassign if this is not the cause of your change.

Can you please clarify the repro steps here? Based on the description given in #0 and watching the video I have no idea how you can even get into a state where the browser becomes fullscreen when the "Save page as..." dialog opens. From what I can tell from trying out Windows canary, when the browser is fullscreen there is no way for me to even open the wrench menu in the first place.

In the meanwhile, it would be helpful if someone cc'ed who uses Windows to develop could quickly check if r381235 is indeed responsible - you'd only need to revert the few lines changed in BrowserView::IsTabStripVisible(), the ash/mash files are not applicable to Windows.

It reproduced for me with r381235 reverted (on Windows.)

lpanse@: Could you please update the thread as per C#10.

@tdanderson: The steps which lead to this issue remain unchanged. As per comment #10 make sure when you keep 'F11' pressed and click 'Save page as..', the browser should get into a state where Full screen is enabled and even the 'Save Page as..' window is open. After closing the 'Save Page as..' window, the browser should still remain full screened. Only then after retrieving from full screen (Press F11 to exit full screen) does the browser become unresponsive. The issue will not reproduce if the browser doesn't get into that state.

As per my understanding, this issue would probably be happening when the wrench menu click occurs after the browser transitions to full screen (which chrome doesn't allow). Hope this helps to repro the issue. Thanks.

I'm still not able to reproduce on canary based on these instructions. As mentioned in #11 this issue reproduces with r381235 reverted, so my CL is not to blame (and nothing else in your bisect range looks like it could be a suspect).

Based on the fact that two disjoint bisect ranges have been given (in #0 and #8), my best guess is that this is a longer-standing issue with unreliable repro steps rather than a recent regression.

Either way, I don't think this is a stable-blocker, so I am going to remove that label.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

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

This does not look Settings related.

***UI Mass Triage ***

Still able to reproduce the issue on windows 10 using chrome latest canary-72.0.3622.0 . As it is non regression issue adding respective labels.
Thanks..!