If it's in fected with some type of virus that won't let the application go that could be a problem. I could suggest doing scans right away, but if you can disable any and all add-ons for the browser (or start it in safe mode) I suggest doing that as a test.

Background Info: There's a long standing issue for processes stalling (ie not responsive).
FEW systems support fully asynchronous I/O as a default. Most I/O is preformed in BLOCKING mode, meaning the process gets no service until the I/O completes. When I/O is initiated, there are several layers of software to get into the kernel code where it actually gets initiated. As long as the process is not in the kernel, the process is easily killed. Once in the kernel however, the process stalls until the I/O completes.

For I/O to locally attached devices (hd, usb, video, kb, mouse, ...) this is seldom an issue unless you have a faulty device or have disconnected the device while it was active (a device that is offline/not ready will never get into the kernel).

For networked devices (eg mapped drives) you are at the mercy of the system which has that resource as a local device. If that system/user takes the resource offline, then you are exposed.

Network sockets work much like network devices, but have always had a timeout associated.

But you say "Hey, it's a browser and it is threaded" - - true enough and although the tread may be stalled in the kernel, the process SHOULD (in theory) never stall as all threads are controlled by the program that created them, and by now, *most* programers who can write threaded code, know enough to not access resources in the parent.

If the process window can not be minimized/maximized, then the process is not getting any CPU - - and the quest begins :sigh: