Is it possible to have updates from the Firefox team. Is there a place to follow the works on this bug?
I’ve not found any issue in Mozilla bug tracker. Is this bug already declared?
For me it’s impossible to use Firefox to debug my app as it takes more than 14 seconds to load the page…
The debugger team is working on several performance-related items. Right now we are trying to land improvements for projects using source maps.
All the work is made on GitHub at https://github.com/devtools-html/debugger.html. If you can file an issue there with clear steps to reproduce, it will help the team address your issue.
We have several bugs in Bugzilla and GitHub to track specific performance issues. Can you give more details about your issue (URL if it is public, which panel is selected in DevTools etc…).
Then I can either point you to an existing issue or open a new one. Thanks
The URL is not public as it’s a local development.
I’m building an app using Bootstrap and Dojo. When the page loads, it performs 281 requests (mainly js + css files).
The same page takes 2.5 seconds to load with Chromium.
It doesn’t depend on which panel is open. I’ve tried with Console, Memory, Network and Performance and I always have the same time to load the page. If the devtools are closed, the page load in 2-3 seconds.
Thanks for the info. Would you be able to capture a performance profile using the profiler at https://perf-html.io/ ?
Maybe it is a panel which was loaded and then hidden. To make sure if a panel impacts or not the reload time you can do the following steps:
- select the panel (e.g. console)
- close devtools (F12)
- open devtools (F12) (it should still be on the console, don’t change the selected panel)
- reload your page
Any extra info can help!
Sorry, in fact the panel impacts. If I open devtools in console directly, the page lors in 3.9s each time. If I open the network panel it can spend more than 12 seconds.
I’ll try to give you a performance profile.
Thanks for checking. There has been a decent amount of performance work in the Network panel recently. If you are not already using Nightly, it would be worth checking the performance there.
I’ve tried using nightly and there is a little improvement (9 sec instead of 12 sec) but the problem is still present.
Here is the perf without opening the network panel : https://perfht.ml/2CYFNmU
The perf with the network panel open : https://perfht.ml/2oFPlAh
I don’t know how to analyze it so let me know if you there is something I did wrong.
Thanks for the profiles @tony . They highlight a couple methods to investigate already. I found https://bugzilla.mozilla.org/show_bug.cgi?id=1350969 which tracks performance improvements for the Netmonitor and added links to your profiles there.
I tried to find a stable way to reproduce the bug but I don’t have the same behavior. I always have a lot of memory usage but not always in the same range. Sometimes is 2go and sometimes it’s 6go for the same page with the same navigation.
Here is the result of one single page loading when I go to the debugger :
As you can see the CPU is going crazy. The page took about 5 seconds to load but the memory usage increase and the CPU is used for about 30 seconds. If I reload more times, it still continue to use memory.
I went on all tabs of the dev tool and it works well but it goes crazy when I go on the debugger.
It works nicely with Firefox 57. It do this only with the local version of my app but it’s correct with the compressed version in production.
I will try to find a way to reproduce the bug with an online app.
Any news on this front. I have the same issues as mentioned above (debugger tab takes many seconds to open, moving line to line (F10) takes 2-3 seconds each time) mousing over a variable takes a long time to show its value)? Using FF 57.0.3
I have another issue where a bunch of breakpoints keep coming back no matter how many times I remove them.
| Any news on this front […] Using FF 57.0.3
Stepping (F10) performance has been improved on 59 already. “Opening the debugger” can be slow for various reasons, we are still working on improvements related to sourcemaps. If you have a link with steps to reproduce your issue, the best is to open a ticket on https://github.com/devtools-html/debugger.html/issues
Always worth trying Nightly, as we have been landing several performance improvements to the debugger in Firefox 59.
| I have another issue where a bunch of breakpoints keep coming back
| no matter how many times I remove them.
I thought most “breakpoints” issues were fixed before 57 
. As a workaround you should be able to go to about:config and look for “devtools.debugger.pending-breakpoints”. Could you copy the value and report it here? After that you can right click and “Reset” the value. Hopefully it should remove those persistent breakpoints.
Hi, I’ll check out the Nightly .
I’d rather not have the contents of “devtools.debugger.pending-breakpoints” on a website. Can I send it to you privately?
I still have the issue with Firefox 59. A single tab opened with the debugger take 5Go of RAM.
Hi,
Jason Laster did a huge job to improve perf and it’s a lot better with Firefox 60a1, the current nightly build.
You can visit this repo if you want more about the debugger.
2 Likes
I’m able to reproduce, and working on a project that is open source, called GPU.js. I’d like to help solve this as it is the one hangup in firefox that has me switching back (temporarily) to other browsers.
To reproduce:
- Clone this - git@github.com:gpujs/gpu.js.git
- Run
npm ioryarnto install node packages (mostly just QUnit) - Start webserver from root
- Visit (replace “localhost:8000” with your path) http://localhost:8000/test/all/html
- Filter on any of the tests, example: “#195” put a breakpoint in gpu.js around here - https://github.com/gpujs/gpu.js/blob/43bb07e879dc6f6085c45a825b6823e8a78e8ac8/bin/gpu.js#L3207 (return statement of
astMemberExpressionof theWebGLFunctionNodeclass) - Refresh the page, and see how breakpoint changes locations erratically, and causes the debugging environment to freeze up and become unresponsive.
I can reproduce this 10 of 10 times on an i7 MacBook Pro. This is likely over-exasperating Firefox, because this function is somewhat highly recursive, but it will quickly exemplify the problem in a compounded way. Chrome, 10 of 10 times, has no issue whatsoever loading the debugger.
I hope this can help!
1 Like
Nearly two years later, and I’m still seeing this issue.
Happening on my Linux installation too. Running VueJS Dev Tools It’s quite repeatable. It happens the most when using the inspect feature. I’ll be mousing over elements in the panel and there will be no boundaries displayed on the page. It seems to be the main source for the issue in my experience.