I don't think users should have to understand the differences in underlying behavior here; if we try to close a tab, and can't because something about the process misbehaves, it seems like Chrome itself should detect and deal with that (e.g. by automatically forcing close on a timeout).

We do have the hang monitor for this already, so one start here would be to enumerate some real-world cases where that isn't sufficient.

I'm leaving this open for now to make it clear that I'm willing to believe there's a real bug worth fixing, but I don't think the proposed solution is the right one.

I agree that ideally, users shouldn't have to understand the underlying behavior. I think there's two ways that it could be transparently implemented, which would be either for close tab to immediately kill the process, or for the normal close tab process to detect whether the tab has frozen or is slowly eating more and more system resources. 

The first option is a no-go for cases like if someone is editing a document in that tab, in which case the tab should be allowed to prompt the user to save first instead of being immediately killed.

The second option seems difficult, and I'm not certain whether or not Chrome already does some kind of timeout detection when trying to close a tab. Regardless, either some pretty exceptional algorithm will have to be created to quickly detect a situation where the tab has frozen, or there needs to be a fallback for manually killing the page. The task manager fills that role right now, and I'm recommending we introduce a faster way to explicitly end a tab's process.

Perhaps the force close option can be added to the tab's context menu only in the case that the #enable-devtools-experiments flag is enabled, or even create a separate flag, unless a more appropriate flag already exists.

The core issue here is a misbehaving renderer process, right?  And specifically, the case where the renderer process is unresponsive (because otherwise it would presumably close)?

If so, that's where the hang detector comes in.  Can you say more about whether/how this works for you today?  Is it not detecting certain hung processes?  Is the detection timeout too slow?

I have some cases in development where what could effectively be called a headless javascript app I'm working on becomes unresponsive. It begins to slowly eat more and more memory and cpu usage, and trying to close the tab does nothing. The only way to kill the tab is to kill the process from the task manager.

I'll admit that perhaps this is a rare scenario I'm running into, and in most cases Chrome's hang detection should aid a user in killing a frozen tab. So I guess the question now is would it be better to introduce a force close button for the sake of rare situations that aren't correctly intercepted by the hang detection, or should I debug my own app more deeply to find out why it's freezing in such a way that Chrome's hang detector doesn't catch it?

I suppose I just feel that there are outside cases that can't necessarily be anticipated where the hang detector won't catch the problem, and in those cases it would be nice to be able to quickly kill a tab's process without having to open the task manager.

If you're able to share the (buggy) app on some sort of limited-access URL, it's possible we have a bug where the hang detector isn't catching something it should, and we could investigate.  That's something the Blink/V8 folks might want to look at.

If the scenario is really limited to "cases the hang detector is broken", then using Task Manager seems OK for most users, it's just annoying in your case because you're hitting it repeatedly while developing.  But I'd definitely like to find out why the hang detector isn't working here.

Not sure what the right bug category for that is.

Not JavaScript related. AFAIK this is mostly about making the X on the tab equivalent to the task manager kill process after some grace period. 

@9: You may be getting sidetracked by the original fix request here.  The bug is effectively morphed into "hang detector isn't catching a hung page" and the reason I'm putting this back into the JS queue is that AFAIK bugs in the hang detector would go there.

Changing the behavior of the tab close button would be bandaiding the symptom; the underlying problem is that apparently the tab is getting stuck in some state that we're not catching.

I imagine this can't be easily dealt with without a repro case.

Mac triage: WontFix issue without feedback or repro case for > 30 days. If you have a repro case please reopen this bug.