Bug to keep track of all spinner-related issues with e10s. Filing in gfx for now as that's the most likely culprit for long/delayed paint times.

Is the spinner made as such to cancel the urlbar results? It seems to me that way. Often I start typing and frustrated by nothing appearing. And as soon as the spinner's gone the results appear. After some testing once or twice when I was fast enough, I could get the results appearing, then disappearing as the spinner appeared, then appearing again as the spinner was gone. Without this the spinner wouldn't be so annoying. I don't have good STR though. Especially since it necessitates the spinner appearing for a significant time after opening a new tab.

Do we have any good method to get the stack information for this issue? (especially for the released Firefox) I have tried: 1. :ted.mielczarek's Crash Me Now! add-on It does not work for spinning tabs. 2. crashinject.exe It somehow does not work for Release channel (but works for Nightly). 3. Gecko Profiler, both old (maintained by :bgirard) and new (maintained by :mstange) versions I *guess* they don't work while there are some spinning tabs, because I waited for half an hour and they were still loading the samples. 4. Attach debugger to the process, and call profiler_save_profile_to_file() I've tried this under my Mac machine, I can call the function though but no file was written. And I think this is not convenient for regular users, because they must a. have a debugger installed b. have debugging symbols for Firefox to resolve the function address 5. Use some external tools to extract stack at the moment e.g. Activity Monitor for Mac and Process Explorer for Windows No JS stack information, and if it the reason of hung is not an IO blocker, the captured stack might not be the root cause. For Mac, we still need debugging symbols. 6. Use some external tools to profile the process No JS stack too, and it needs debugging symbols for Mac. Also, I think some antivirus daemons caused the spinner by DLL injection. I hope at least we can do something like WatchDog or BackgroundHangMonitor for this problem.

(In reply to Wei-Cheng Pan [:wcpan] [:wcp] [:legnaleurc] from comment #2) > Do we have any good method to get the stack information for this issue? > (especially for the released Firefox) > Currently, in my opinion, the best method is the Gecko Profiler add-on, without a doubt - though, unfortunately, this method only seems to work if the content process is not completely hung. There was the profiler_save_profile_to_file capability for the hung process case, but that now appears to be broken, and is hard for end users to do. In the event of a fully hung content process, the crash injector might be the next best bet. And if that doesn't work, you could also try closing all of the remote tabs. The parent process will wait some number of seconds before force killing a hung content process that's associated with closed tabs, and when it does that, it'll collect a paired minidump for crash report submission.