Also repros on Windows.

Firefox 52a has the same experience, before popping a notification bar: "A web page is slowing down your browser. What do you want to do?"

Symbolicated Mac backtrace attached. It seems that it's a hang in v8:

Deleted: SymbolicatedBacktrace.txt 112 KB

SymbolicatedBacktrace.txt 112 KB View Download

I don't think this is a problem in V8. As Firefox shows the same behavior I suspect this is simply bad code on Amazon. I would have expected that we also display a Hang window though which interrupts endless loops. This Hang window is triggered by Blink though.

I can't even close the tab or the browser on my MacBook (Chrome 56).

So, is the issue that hang monitor is not triggering?

I guess there are two issues. First, the hang monitor is not appearing for some (I can reproduce the problem but I do get the hang monitor).

The second is looking into why the renderer is hanging in the first place. c#5 suggests bad code - if that's the case then OK, but someone should investigate to make sure that's what it is.

hablich@, could you confirm that this is not V8 and if yes, retitle and remove the Blink>JavaScript label. BTW, hang monitor is not Blink.

Just had a look with jochen@ and about:tracing. Looks like an endless loop orchestrated by setTimeout() => JavaScript code one the page is bad.

From an user point of view the behavior is unsatisfactory though:

-Hang dialog does not appear (at least on my MacBook) but does appear on my Linux workstation
=>Dialog should always appear
-Clicking on "Wait" on the dialog is making the tab unresponsive. The user can't close the tab and it keeps on consuming 100 % CPU. The tab can be killed via the task manager only
=>Display another dialog after some time or make the process killable via the X on the tab?

What are the next steps here? Do we need to spin out a separate bug?

This is a problem with the "Kill process"/hang dialog. No clue which component this is though.

The hang monitor is based purely on acks of input events sent from the browser.

On Mac; I can get the Hung Renderer dialog provided I move the mouse onto the renderer viewport. If I just stay inside the OmniBox with the mouse then it won't appear. Both Kill and Wait work correctly for me in 54.0.2840.71.

justincohen@ is it that you weren't moving your mouse onto the renderer viewport?

I can still reproduce this today, even if the mouse is over the renderer.

Can you confirm which exact version of chrome and which OS version you are reproducing this on. thanks.

I repro on Win7 Chrome 56.0.2901.0 {"arch":"x86-64","nacl_arch":"x86-64","os":"win"}

Notably, I can scroll the page, but I cannot click anything in it, and I cannot close the tab. I do not get a "hung page" dialog at any point.

Mac 10.11.6 Chrome 54.0.2840.71

Are all chrome://flags restored to default settings?

Are you continuously scrolling or clicking?

I can get the Hung Renderer Dialog on 56.0.2901.0 on Windows 10 as well.

The Hung Renderer timer is reset once it receives an input event ack. If you scroll the page then because the renderer is responsive and ack's the mouse wheel events it resets the count. Same with clicks although the main thread is borked. If you leave your mouse for 60s and don't touch anything does the hung renderer dialog appear?

Re #20: Interesting. Indeed, on Windows 7 if I don't scroll the page, the Hung Page dialog does eventually appear. If I click in an edit repeatedly for a long time without scrolling, the hang dialog eventually shows as well, although the dialog disappears on the next click in the edit. 

(Part of the reason this is confusing is because Windows/IE hang detection works when the app is unresponsive to clicks.)

Yes, if I don't do anything for 60 seconds I get the hung renderer dialog.

tdresser@ Any idea why MouseDown and MouseUp are never explicitly acknowledge by the renderer? https://cs.chromium.org/chromium/src/ui/events/blink/web_input_event_traits.cc?q=ShouldBlockEventStream&sq=package:chromium&l=198

So clicking on a page will always reset the hung renderer dialog timer. I don't think this is a P1 though.

Granted this is probably a P1 that you can't kill the tab. I don't know why you can't do that. I could always kill the tab.

There's something unusual about this case-- if I visit other pages that scroll (e.g., https://www.chromium.org/Home) and put them into an infinite loop (e.g., typing javascript:while(1); into the omnibox), I'm no longer able to scroll them.  But on this Amazon page, the scrolling continues to work.  I would think that would indicate the renderer is still responsive?

dtapuska@: Do you know if there's something different about scrolling?  Could something be blocking the rest of the input events?

It does seem like the dialog shows up 60 seconds after the last scroll, whether other mouse moves are happening or not.

And by 60 seconds, I mean 30 seconds (according to a timer).

This is because www.chromium.org/Home is likely causing main thread scrolling.

Where as mouse wheel scrolling can completely be driven by the compositor thread; don't ask me what release I did that in but it was earlier this year.

On the amazon page try to cause a main thread scroll by dragging the scrollbar and you'll see that you can't. Perhaps we should not be resetting the hung renderer count on acks coming back from the compositor thread (or synthetically generated events that occur in the browser process)?

s/resetting the hung renderer count/resetting the hung renderer timeout (but decreasing the outstanding count)

ie; the fact that the compositor thread is scrolling means the renderer is alive and well. It does not *imply* that the main thread is alive and well.

Comment 27-28: Yes, we probably don't want to reset the hung renderer timeout if the main thread is hung (just because the compositor thread is responsive).

Copied  issue chromium:654835  to  issue chromium:659742 

I've cloned the issue to 659742 to deal with the fact that the tab can't be closed.

I will work on getting the hung renderer view appearing consistently.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/120e997fc114e87d1b98a32ac9a81bce954e05d2

commit 120e997fc114e87d1b98a32ac9a81bce954e05d2
Author: dtapuska <dtapuska@chromium.org>
Date: Mon Nov 07 20:13:39 2016

Don't restart the hang renderer timeout on messages ack'd from the compositor thread.

Only reset the hang monitor timeout based on an ack actually coming
from the main thread. This way we can put the dialog up even if the
compositor is responsive but the main thread isn't.

BUG= 654835 

Review-Url: https://codereview.chromium.org/2482453002
Cr-Commit-Position: refs/heads/master@{#430355}

[modify] https://crrev.com/120e997fc114e87d1b98a32ac9a81bce954e05d2/content/browser/renderer_host/input/input_router_client.h
[modify] https://crrev.com/120e997fc114e87d1b98a32ac9a81bce954e05d2/content/browser/renderer_host/input/input_router_impl.cc
[modify] https://crrev.com/120e997fc114e87d1b98a32ac9a81bce954e05d2/content/browser/renderer_host/input/input_router_impl_perftest.cc
[modify] https://crrev.com/120e997fc114e87d1b98a32ac9a81bce954e05d2/content/browser/renderer_host/input/input_router_impl_unittest.cc
[modify] https://crrev.com/120e997fc114e87d1b98a32ac9a81bce954e05d2/content/browser/renderer_host/input/main_thread_event_queue_browsertest.cc
[modify] https://crrev.com/120e997fc114e87d1b98a32ac9a81bce954e05d2/content/browser/renderer_host/input/mock_input_router_client.cc
[modify] https://crrev.com/120e997fc114e87d1b98a32ac9a81bce954e05d2/content/browser/renderer_host/input/mock_input_router_client.h
[modify] https://crrev.com/120e997fc114e87d1b98a32ac9a81bce954e05d2/content/browser/renderer_host/render_widget_host_impl.cc
[modify] https://crrev.com/120e997fc114e87d1b98a32ac9a81bce954e05d2/content/browser/renderer_host/render_widget_host_impl.h
[modify] https://crrev.com/120e997fc114e87d1b98a32ac9a81bce954e05d2/content/browser/renderer_host/render_widget_host_unittest.cc
[modify] https://crrev.com/120e997fc114e87d1b98a32ac9a81bce954e05d2/content/browser/renderer_host/render_widget_host_view_aura_unittest.cc
[modify] https://crrev.com/120e997fc114e87d1b98a32ac9a81bce954e05d2/content/browser/renderer_host/render_widget_host_view_mac_unittest.mm
[modify] https://crrev.com/120e997fc114e87d1b98a32ac9a81bce954e05d2/content/common/BUILD.gn
[modify] https://crrev.com/120e997fc114e87d1b98a32ac9a81bce954e05d2/content/common/input/input_event_ack.cc
[modify] https://crrev.com/120e997fc114e87d1b98a32ac9a81bce954e05d2/content/common/input/input_event_ack.h
[add] https://crrev.com/120e997fc114e87d1b98a32ac9a81bce954e05d2/content/common/input/input_event_ack_source.h
[modify] https://crrev.com/120e997fc114e87d1b98a32ac9a81bce954e05d2/content/common/input_messages.h
[modify] https://crrev.com/120e997fc114e87d1b98a32ac9a81bce954e05d2/content/public/test/browser_test_utils.cc
[modify] https://crrev.com/120e997fc114e87d1b98a32ac9a81bce954e05d2/content/public/test/browser_test_utils.h
[modify] https://crrev.com/120e997fc114e87d1b98a32ac9a81bce954e05d2/content/renderer/input/input_event_filter.cc
[modify] https://crrev.com/120e997fc114e87d1b98a32ac9a81bce954e05d2/content/renderer/input/render_widget_input_handler.cc
[modify] https://crrev.com/120e997fc114e87d1b98a32ac9a81bce954e05d2/content/renderer/mus/compositor_mus_connection_unittest.cc
[modify] https://crrev.com/120e997fc114e87d1b98a32ac9a81bce954e05d2/content/renderer/render_view_impl.cc