P2 Important issue, possibly already being worked on
P3 Real issue, someone will get to it if they have time
moreinfo We need logs, or clarifying information
invalid Misclassified, remove the MemShrink tag
5 bugs to triage
1220488 - Core :: Audio/Video: Playback - FireFox memory leaks and issues, rampant on a particular site
erahm, what do you think? I'm leaning P1. 95% heap-unclassified is
pretty ridiculous, I think we at least need better reporting here.
Additionally it feels like we really shouldn't be using that much memory
for videos that aren't actively playing (this would be particularly bad
That sounds fine to me. Video can use up lots of memory very fast if something goes wrong.
1221503 - Firefox :: General - Firefox is slow (Windows swapping all the time)
erahm, what do you think? I'm inclined to close this as WFM, I didn't
see anything that stuck out as egregious, this feels more like a
"Firefox uses more memory than a decade ago" bug.
They are using ABP with a version that doesn't have the ABP memory improvements, so that may be a factor. We could see if they are willing to try that and if they get improvements dupe it over to the style sheets bug. I suggested that in the bug. Beyond that, I don't think it is a great use of time to try to debug somebody's issues who is running a version that is a year or more out of date. "Incomplete" is a better designation than "Worksforme", as they are still experiencing the issue.
erahm, what do you think? I'm inclined to P2 this. It's possible that
the async reporting itself is causing a leak, in that case I might lean
Core :: Hardware Abstraction Layer (HAL) - [e10s] (Win) Nightly
(FF45.0a1) main process use a lot of memory in the last builds
It looks like the reporter is suggesting this is fixed, so probably close WFM.
mconley pointed out that this might be a regression in session restore on e10s from bug 1209689, that points to a rather large talos regression in bug 1227275, which now that I think of it we should probably MemShrink (discussion further down).