Closed Bug 504770 Opened 16 years ago Closed 14 years ago

Need a way for users to tell where time is being spent when the UI goes unresponsive

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Version:
3.6 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED DUPLICATE of bug 703800

People

(Reporter: digulla, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: perf)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1 (.NET CLR 3.5.30729) AutoPager/0.5.2.2 (http://www.teesoft.info/) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1 (.NET CLR 3.5.30729) AutoPager/0.5.2.2 (http://www.teesoft.info/) Every now and then, the UI locks up for a few seconds up to half a minute. FF will not response to redraw events, window close will time out, can't switch tabs or click on links. The frustrating part is that I have no idea what is going on. I'm really like to have a plugin or a monitor thread that collects some statistics on what is locking the UI up to help to find and fix such issues. For example, on Linux, FF would hang because the Beagle index plugin would block because of NFS problems. Going through all the plugins is a tedious process. FF should really look after itself and tell me pro-actively "This plugin is currently blocking. Kill/Uninstall/Ignore?" Reproducible: Sometimes
Please create a new profile with no changes and try there.
Keywords: hang
OS: All → Windows XP
Hardware: All → x86
Version: unspecified → 3.5 Branch
Reporter, are you still seeing this issue with Firefox 3.6.13 or later in safe mode or a fresh profile? If not, please close. These links can help you in your testing. http://support.mozilla.com/kb/Safe+Mode http://support.mozilla.com/kb/Managing+profiles
Whiteboard: [CLOSEME 2011-2-25]
Neither safe mode nor managing profiles solves my issue. What I want is Firefox to *tell me* what is hogging the CPU instead of me spending several hours switching plugins on and off, restarting, browsing, trying to reproduce the issue. I want to be able to press a button to get a dump of FF's activity *right now* so I don't have to stab in the dark. So please add an independent thread to the FF executable that listens to a signal, a button or a keypress and which shows where FF is currently spending time.
Whiteboard: [CLOSEME 2011-2-25]
Version: 3.5 Branch → 3.6 Branch
After switching to Firefox 4 beta, I've started to experience this more often than with FF 3.xx, it seems. I'd say several every day. What I also notice is that this is accompanied by a very intensive hard drive activity. By the way, Skype exhibits a similar behavior, and it's known that it is related (at least, in some cases) to SQlite.
Using FF 4.0b13pre on 32-bit Windows 7.
Aaron, URLs would be helpful. @Roman, And also in safe mode? http://support.mozilla.com/kb/Safe+Mode
Severity: normal → major
Keywords: hang → perf
Wayne, thanks for looking at this. As I said: I want a key stroke or a button that I can press which then pops up a new window giving me a task list which shows which part of FF is currently active. Just like the process list that I get with Alt-F2 on KDE or the process explorer on Windows. This isn't tied to a specific URL or plugin. What I want is a catch-all debug tool that helps power users like me to provide you with useful information what is going on. Look at it like this: I have 25 years of experience as a software developer but I can't tell you why FF hangs. All I can tell you is "100% CPU" Then you start telling me to disable plugins, waste a couple of hours, etc. when FF basically already knows what is going on. So please give us this tool so we all can stop wasting time :-)
Attach a debugger to the running process. On win3 you can use windbg with the Mozilla symbol server....
Excellent solution. Please include the debugger with the standard FF release, allow to start it with a hot key (Shift-Esc or Ctrl-Shift-Esc) and patch it to show the current stack trace as the first thing after opening a window. *sigh* Dear Firefox developers: Not everyone in the world wants to compile Firefox from the source. Not everyone wants to learn how to use a debugger to give you useful bug reports. If you want better bug reports, please provide the tools to create them *automatically*. Like KDE which gives me a dialog that searched the bug database for a similar problem, collects all the relevant data and even has a button to install the debug symbols if necessary. That is a solution which clearly communicates: We not only care for the grandmothers and infants but also for IT specialists who don't really want to spend one hour to collect information that other software collects automatically with the push of a button.
(I'm not a developer so I'm not going to speak like one or speak for them) The triage comments thus far have been about your bug summary and comment 0, which don't mention your later focus on debugging. So if your real request is about comment 9 ... 1. it doesn't match comment 0 nor the bug summary 2. it's an enhancement request, not "major" 3. a "solution" is probably at least partly OS dependent - which may not have a trivial solution 4. mozilla (very likely) isn't going to package OS dependent tools that already exist externally, and benefits a fraction of the user base 5. you do understand that comment 8 does not require that you compiles source, and clear instructions exist for many situations that anyone with modest technical skills can follow? 6. if you had "a key stroke or a button that I can press which then pops up a new window giving me a task list", how does a task list lead to better bug reports or improved ability for the "user" to self diagnose, when so many issues don't lend themselves to a "one size fits all" approach? That said, it sounds like you have one or two SPECIFIC issues that you have encountered and used tools to diagnose a problem. So I'd suggest giving some examples of how you'd "automate" those examples, bearing in mind the issues above. It wouldn't hurt to cite examples of other products which do what you want to see, like KDE (but you didn't provide details or references). Also, have you looked at or asked about plans in progress or in waiting for js, opp, electrolysis, Socorro, breakpad or instrumentation which seek to enhance the stability or FF or improve debugging capabilities. about:support being a simple, recent example. Last, the most intriguing thing you wrote is you want to be able to file better bug reports. Again, citing examples would help. And have you ask about these issues in a mozilla forum like mozilla.dev.quality or on IRC?
roc, this sounds like a situation in which your proposal for event loop telemetry would maybe help... Is there an existing bug on that? On a side note, on Mac this is part of the OS-provided activity monitor... the problem is the other OSes that don't provide that sort of thing out of the box. :(
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Firefox UI intermittently unresponsive → Need a way for users to tell where time is being spent when the UI goes unresponsive
(In reply to comment #11) > roc, this sounds like a situation in which your proposal for event loop > telemetry would maybe help... Is there an existing bug on that? Not as far as I know.
Depends on: 668653
Depends on: hang-detector
I don't think telemetry would really help here, would it? All that will tell you is "yes, your browser was unresponsive for this amount of time". What you really want is to have something hooked up to SPS (bug 683229) to get profiling info out when this happens.
Is too much to ask for an "about:cpu"?
Along the lines of "about:cpu": Add a button which is hooked to an independent thread which opens "about:cpu" when I click it and dump a stack trace of the currently JavaScript interpreter(s) plus the URL from which the JavaScript was loaded.
You can't hook a button to an independent thread, because click events (as well as all other input events) are processed on the thread the event loop runs on.
In fact, I'm just going to dupe this forward. Feel to reopen if you disagree. It isn't quite the same thing, but I'm not sure there's any way to really diagnose what a hang is while it is hanging, within the browser. But this bug has the same philosophy of letting a user figure out why their browser isn't responding for short periods of time.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.