memory leak when changing an attribute in the Inspector in Developer Tools, but not when using a script
Categories
(DevTools :: Inspector, defect, P3)
Tracking
(Not tracked)
People
(Reporter: gauthierarun, Assigned: bradwerth)
References
(Blocks 1 open bug)
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:74.0) Gecko/20100101 Firefox/74.0
Steps to reproduce:
- Visit about:blank
- Open Developer Tools
- Go to the Memory tab and make a few snapshots to get a baseline
- Go to the Inspector tab and add an attribute on the <body>, for example: abc = "1234"
- Take another memory snapshot. With me it rises by around 0.4mb.
- Change the attribute value to a different string of the same length. For example: abc = "9999". With me it rises at a minimum of 0.1mb for each change.
Notes:
- do it fast: sometimes the memory will be reset to what it was at page load.
- I can't find a memory leak when an attribute is changed consecutively by a console script, I used:
setInterval(function(){ document.body.setAttribute("abc", Math.random().toString().substring(2,6)) }, 1)
Actual results:
I have gotten to 7.88 Mb on a memory snapshot in the Memory tab in Developer Tools for an about:blank page, after that I became bored of changing the attribute by hand.
Expected results:
Changing an attribute value with a different string of the same length in the Inspector shouldn't increase memory usage.
|
Reporter | |
Updated•4 years ago
|
|
||
Comment 1•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
|
Assignee | |
Comment 2•4 years ago
|
||
Possible manifestation of Bug 1503036. I'll re-test with patches applied and see what happens.
|
|
Assignee | |
Updated•4 years ago
|
|
||
Comment 3•4 years ago
|
||
Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3 (Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3 (normal.)
|
||
Comment 4•3 years ago
|
||
Thanks for logging!
The summary states that after a while the memory goes back to normal. To me this looks like normal GC behavior? The inspector consumes memory to create new objects which are eventually collected. If this is an actual leak and the memory is not freed automatically after a while, feel free to re-open.
Description
•