Also, while the tab is open, it uses a full core.

Hmm, this doesn't repro for me on Windows 58.0.2990.0.  The tab closes after 1 second.  (Using a full core is expected, given the while (true).)

Avi, do you see this on Mac?

Whoops...on further testing, there's another step.

Step 1b: Open the web inspector.

Oh!  I think that's an intended behavior of DevTools, which disables the unresponsiveness timer so that it doesn't interfere with JS breakpoints.

I think that's a WontFix, but I'll let dgozman confirm.

Yeah, that's expected. The workaround is to close DevTools first (works for me).

This may be working as intended from a devtools perspective, but I don't think it's reasonable for to have to close the devtools to close a tab. More importantly, if you don't close the devtools first, there's no way to close the tab other than killing the process in task manager.

@ojan: What would be your expectations?

If we close the tab within 1 second, web developer would never know that there was a problem. Hitting the "Pause" button on the other hand would break JS execution and point to the offender.

We could restore the unresponsiveness timer and break execution from renderer's IO thread (we can do that using the stack guard), but I'm worried that it would race with the stepping (we need to disable the watchdog there). 

assigning to you to get input...

Hitting the pause button didn't pause and didn't allow me to close the tab when I did it. But, even if it would have worked, there's little reason for a developer to think that a chrome tab not closing is a bug in their page. It certainly would never occur to me and just mentioning it in my cube, someone was talking about their partner who hit this recently and didn't understand that it was devtools related.

There's two complementary things I could imagine us doing:
1. Disable the watchdog timer only when JS execution is actually paused instead of just by having the devtools open.
2. Have the user closing a tab disable the watchdog timer the second time they click on the close button. It's a bit weird, but at least you wouldn't end up with tabs you can't close.

I think we could do both of those. #1 to minimize the frequency with which developers hit #2 to only the cases where they actually have breakpoints in their unload handlers.

I don't think we should rely on making tabs uncloseable for developers to find infinite loops in their unload code.

>> Hitting the pause button didn't pause.

Works for me: https://jsfiddle.net/jbk0phkx/. Not that it leads to a great behavior in your case, but it works.

>> mentioning it in my cube, someone was talking about their partner who hit this recently 

Walked over several cubes and conducted a little survey - people don't hit it, there are no other bugs filed for it, DevRel did not (yet) recognize it as a recurring theme.

>> 1. Disable the watchdog timer only when JS execution is actually paused instead of just by having the devtools open.

I would not want this, because it would mask a real problem of blocking unload handler.

>> 2. Have the user closing a tab disable the watchdog timer the second time they click on the close button. It's a bit weird, but at least you wouldn't end up with tabs you can't close.

We can try doing this, or we can try breaking the execution when program being closed is busy. But that is non-trivial investment. I recognize that we have a problem, but I don't see a solution that would be on par with the issue severity.

FYI, I'm working on modernizing the hang timer, and one of the things that I'm going to do is split off the "closing page" timer from the "unresponsive to input events" hang timer.

Would that be of interest to you, gentlefolk? :)

I would probably use it to fix this bug, so yes. I would disable the unresponsive timer from debugger, but would leave closing page one alone.

@avi: could you mark this issue as blocked upon yours once you have it?

pfeldman: I'll loop you into the CL then.

The bug that I'm working on is bug 669881. You can block this bug on that one if you want, but the part about splitting off the closing page timer is only one of several pieces of the work for that bug.

Actually, the splitting of the close timer will be under  bug 418266 .

pfeldman:

I'm playing around with https://codereview.chromium.org/2725993002/ . It definitely solves the original post here, with an infinite loop in the unload handler. The question I have for you is how to do proper devtools integration in it.

If the devtools are just up, but not stopped in a breakpoint, we should allow the unload. Unfortunately, with that CL patched in, even if the devtools is stopped in a breakpoint in the unload handler, the new timer will force the tab closed despite the devtools actively debugging the unload handler, which is something we don't want.

I can't even use DevToolsAgentHost because that lives at the WebContents level, and the close timer lives at the RenderViewHost level.

Thoughts on the right approach here?

>> I can't even use DevToolsAgentHost because that lives at the WebContents level,

DevToolsAgentHost lives on the RenderFrameHost level, just introduce another HasFor or GetFor or whatever you need in content/public/browser/devtools_agent_host.h.

>> and the close timer lives at the RenderViewHost level.

RenderViewHost... I haven't heard this name for a long time and was hoping that we would limit ourselves to code on RenderFrameHost and WebContents levels. So I can't recommend anything here.

Forget the RVH then. Suppose we were at the WebContents level. Is there a way to ask devtools if it's actually stopped in a debugger for the page?

Right now WebContentsImpl::RendererUnresponsive has DevToolsAgentHost::IsDebuggerAttached, but that just means that devtools is open on the page. Can I get a DevToolsAgentHost::IsDebuggerStoppedAtBreakpoint?

> Is there a way to ask devtools if it's actually stopped in a debugger for the page?

More precisely, if it's stopped in a debugger for any frame in the page? In OOPIF-land, we might have an OOPIF in which the debugger is stopped, and we'd like that to prevent closing the top-level page.

>> Forget the RVH then. Suppose we were at the WebContents level. Is there a way to ask devtools if it's actually stopped in a debugger for the page?

We could plumb it, but it would need to be a renderer roundtrip to avoid the race.

>> In OOPIF-land, we might have an OOPIF in which the debugger is stopped, and we'd like that to prevent closing the top-level page

we have a DevtoolsAgentHost per RFH.

So what would you like to do? If the onunload spins and devtools are open, we can either:
- Not allow closing of the page. Pro: allows debugging of onunload. Con: surprises users.
- Allow closing of the page. Pro: allows closing of pages. Con: doesn't allow debugging of onunload handlers.

Without plumbing debug state, I'm not sure how to proceed.

Debugging unload is a known important use case, so it would be: "not allow closing of the page."

>> Without plumbing debug state, I'm not sure how to proceed.

Preserve existing behavior and use DevToolsAgentHost::IsAttached() for now. That does not fix Ojan's bug, but it also does not make things worse.

OK, then.

There is nothing we are doing about it in the nearest future, closing.

 Issue 764693  has been merged into this issue.