Capturing a long performance sample makes Firefox unresponsive.




Developer Tools: Performance Tools (Profiler/Timeline)
2 years ago
2 years ago


(Reporter: Jukka Jylänki, Unassigned)


(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [btpp-fix-later])



2 years ago

1. Navigate to
2. Open the Performance tab and run a long profile (5 minutes+)
3. Stop the profile and open the tree view of the samples.
4. Click on different parts of the browser, e.g. toggle keyboard focus between the text box on the page, and one of the text elements in the bottom-up tree view.

Observed: Firefox process has become very unresponsive and it takes 5+ seconds for Firefox to respond to the changed keyboard focus on the page. The spinning cube on the page halts rendering between mouse presses. Alt-tabbing back in and out of the Firefox window takes 5+ seconds as well, as does changing mouse cursor from arrow to caret when mouse is hovered over various elements of the page. Switching between the "Console" and "Performance" tabs of the devtools view also takes several seconds.

At this point, Firefox Nightly process consumes 1.1GB of RAM, and Plugin Container for Nightly 308MB. The system I am testing on has a Core i7-5960X with 16 logical cores and 32GB of RAM, so it is definitely not running out of memory and swapping.


2 years ago
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64

Comment 1

2 years ago
Here is another example:

Perform a sample run for 30 seconds or so, and as a result, Firefox becomes very unresponsive.
I suspect this is an issue with the single-threaded architecture of the performance tool, and other performance issues. These are being tracked in Bug 1160330. Thanks for reporting!
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Whiteboard: [btpp-close-now]
Duplicate of bug: 1160330

Comment 4

2 years ago
Hey, let me reopen this.

In past experience, I've had a bug be closed as a duplicate of another bug, and after the other bug has been fixed, the fix might have been for a generic case, and since nobody ever looks at closed bugs, the STR I originally posted would never be checked for the fix to be confirmed. Please let's not close bugs with clear STRs as duplicates, unless the duplicate has an equivalent STR. I'd rather have the metabug depend on this bug, wouldn't that be better?
Resolution: DUPLICATE → ---
Sounds good to me, I didn't think about that. Your STR are a great test case for this problem.
Blocks: 1160330
Priority: -- → P2
Whiteboard: [btpp-close-now] → [btpp-fix-later]
You need to log in before you can comment on or make changes to this bug.