On Mac, this will even happen in a non-nested runloop case, because more than one event/message queue (work source) is attached to the loop. Servicing those other work sources could also make the UI thread miss its ThreadWatcher pong even though it is making progress. But Mac will also have the nested loop issue described in the OP.

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

commit 505bed3a721218e94c8c5b6d3ee9ebc3507b6b1a
Author: Gabriel Charette <gab@chromium.org>
Date: Fri Jan 26 23:16:49 2018

Disable hang watching on the UI thread for now.

Also restrict hang reporting to the Canary channel while uncovered
issues stabilize.

R=asviktine@chromium.org

Bug: 806174,  804345 
Change-Id: Ie99b0e7b36d606102642ccab10ef3a30832f08ab
Reviewed-on: https://chromium-review.googlesource.com/888498
Reviewed-by: Alexei Svitkine <asvitkine@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#532086}
[modify] https://crrev.com/505bed3a721218e94c8c5b6d3ee9ebc3507b6b1a/chrome/browser/metrics/thread_watcher.cc

François will take a stab at improving thread watching :)

Data point on why hang reporting on the UI thread is important :

UI thread hang watching (before being disabled) identified issue 805717, the culprit for a long endured and hard to figure out problem documented in  issue 802163 .

Because of the issue here with MessageLoopForUI hang reporting though the stack was considered by the devs that initially looked at it as noise (it is waiting in a system dialog and thought to be an instance of this very issue). While they were correct that a hang report could be generated if the user waited long enough, we also had a true hang here in some scenarios, ref.  https://crbug.com/802163#c24 .

This will be trickier than just adding hang watching that's aware of MessageLoopForUI as in this case, even the nested loop is responsive. But it's in a livelock as it is waiting on the response of a chrome task to unwind which will never run per the default policy of not allowing application tasks to run in a nested loop. This will be a tricky but important problem to unwind (after the initial one of detecting when the MessageLoop is outright unresponsive)!