If you are someone with a problem yourself could I ask you to keep the troubleshooting within your own support thread.
I have marked this as [Attn: HelpDesk] as I linked it to a thread I have just escalated.
- Firefox memory leak causing slow and stuttery performance /questions/998289
23 replies, 150 have this problem, 3637 views
Any contributor or Admin able to throw light on this or have an opinion please join in.
Our primary method of getting useful information will be to ask users for about:memory reports. It probably would be good to have a method of uploading the gzipped files to sumo as I have mentioned elsethread. (may look up link later). Basically the before and after reports, and then the gzipped files may be easily "diffed". It maybe of interest to note results on AWSY https://areweslimyet.com/ the graphs there show various memory usage way below what users with problems report.
The end user, unless having issues with paging and a lack of RAM is actually probably concerned not directly with the memory usage but the jank that is caused. I think we need to be able to address both sides of this issue.
- Follow up and solve more or our problem threads on memory related issues.
- Get qualitative or quantitative information on Jank, and follow that up at the same time.
I have no idea about how we tackle the jank issue, I do note we have a developers working various performance related issues. I would be pleased to hear suggestions and ideas about what we should or could do. So questions I will throw into the ring will any of these help?
- The built in profiler
- FHR & Telemetry
- It seems to me a good idea to suggest users turn on the data reporting. (Even if the data is not shared it is still available locally isn't it? )
- Which of any of the Histograms or data stored locally in about:telemetry are of use in looking at jank or Memory issues
- For comparison what are the interesting ones to look at on the results database static interactive dashboard
My thoughts on the background & policy My general opinion on trying to solve complaints of this type are
- Memory Regressions do get missed. Fx4 was an issue IIRC.
- Problems are real and important
- For individual users, they can cause users to use unsupported versions or migrate to alternative browsers.
- For Sumo / Mozilla memory use and speed is paramount in browser parity.
It is very detrimental when users do have problems with this but where we are unable to offer an explanation or solution.
- It is a difficult subject to troubleshoot. We need to improve how we help users.
- We rarely get users with the time inclination and ability to follow instructions.
- Problems are often not easily reproducible by others.
- But many others will report the same symptoms.
'We need to troubleshoot separately with single users in separate threads
We get self selection bias, users with the symptom report a problem in the thread they find. We get problems due to multiple or separate different causes. We get user with totally different profiles, hardware & software environments. - I consider it is important we get a baseline comparison and results.
- IS IT FIREFOX ? Prove whether or not Firefox works properly
Clean profile, safe mode, all plugins disabled, windows safemode - IS IT A REGRESSION ? Test for Version Regression (Where that is stated or suspected)
- For windows users use of Portable ESR may be a simple method of doing that.
- More complicated as it is likely to involve multiple profiles and possibly multiple installs is to install & test the previous version AND the current Release.
(We are doomed to failure attempting to file bugs for issues reported along the lines of: "It occurred in Firefox two versions ago. The last version also did not work. I am not willing to test and reproduce in the current Release ) - Mozregression is probably ideal. For the more advanced users It is actually fairly simple to use.
(Firefox is easy and simple to use. Not all user are capable of tasks like copying and pasting or finding hidden files without guidance, but if a problem is real and affects many, some of those users will be more able to help us.)
- IS IT A WASTE OF EFFORT Most problems will probably be from users with many addons in use. We can probably do little to help them. But Hey we may get another Fx4 type regression showing up, or a Tens of Millions of users addon issue like ABP
- IS IT FIREFOX ? Prove whether or not Firefox works properly
- about:memory results. We do need some method of obtaining developer or HelpDesk advice on about:memory results, prior to us being in a position to file a bug.
Until we have anything better we have the ability simply by escalating threads, and should remind contributors to do that. - Bugs We should escalate, follow up; and where applicable file bugs.
It is important to ensure good quality bugs with STR are filed. We must not encourage filing of low quality bugs that stand no chance of being investigated.
- We should as a matter of policy ESCALATE any and all memory related questions that are not almost immediately solved, but importantly only where the user is able and willing to troubleshoot and help us. Otherwise all we do is waste HelpDesk and contributors' time.
- Would developers interested and working on memory or performance issues, or maybe someone from QMO or MDN be willing to look at and suggest improvements to our KB articles on CPU, Memory & Troublshooting & ?
Possibly keep the KB articles simple and end user focussed, but link to &/or write more technical & detailed articles for use by contributors.
If you are someone with a problem yourself could I ask you to keep the troubleshooting within your own support thread.
I have marked this as [Attn: HelpDesk] as I linked it to a thread I have just escalated.
* ''Firefox memory leak causing slow and stuttery performance'' [/questions/998289] <br /> '' 23 replies, 150 have this problem, 3637 views ''
Any contributor or Admin able to throw light on this or have an opinion please join in.
Our primary method of getting useful information will be to ask users for '''about:memory''' reports. It probably would be good to have a method of uploading the gzipped files to sumo as I have mentioned elsethread. (may look up link later). Basically the before and after reports, and then the gzipped files may be easily "diffed".
It maybe of interest to note results on AWSY https://areweslimyet.com/ the graphs there show various memory usage way below what users with problems report.
The end user, unless having issues with paging and a lack of RAM is actually probably concerned not directly with the memory usage but the '''jank''' that is caused. I think we need to be able to address both sides of this issue.
* Follow up and solve more or our problem threads on memory related issues.
* Get qualitative or quantitative information on Jank, and follow that up at the same time.
I have no idea about how we tackle the jank issue, I do note we have a developers working various performance related issues. I would be pleased to hear suggestions and ideas about what we should or could do. So questions I will throw into the ring will any of these help?
* The built in [https://developer.mozilla.org/en-US/docs/Tools/Profiler profiler]
* FHR & Telemetry
** It seems to me a good idea to suggest users turn on the data reporting. (Even if the data is not shared it is still available locally isn't it? )
** Which of any of the Histograms or data stored locally in '''about:telemetry''' are of use in looking at jank or Memory issues
** For comparison what are the interesting ones to look at on the results database static interactive [http://telemetry.mozilla.org dashboard]
<u>'''My thoughts on the background & policy'''</u>
My general opinion on trying to solve complaints of this type are
* Memory Regressions do get missed. Fx4 was an issue IIRC.
* Problems are real and important
**For individual users, they can cause users to use unsupported versions or migrate to alternative browsers.
**For Sumo / Mozilla memory use and speed is paramount in browser parity. <br />It is very detrimental when users do have problems with this but where we are unable to offer an explanation or solution.
* It is a difficult subject to troubleshoot. We need to improve how we help users.
** We rarely get users with the time inclination and ability to follow instructions.
** Problems are often not easily reproducible by others.
** But many others will report the same symptoms. <br />''''We need to troubleshoot separately with single users in separate threads''' <br /> We get self selection bias, users with the symptom report a problem in the thread they find. We get problems due to multiple or separate different causes. We get user with totally different profiles, hardware & software environments.
** I consider it is important we get a baseline comparison and results.
**# IS IT FIREFOX ? Prove whether or not Firefox works properly <br />Clean profile, safe mode, all plugins disabled, windows safemode
**# IS IT A REGRESSION ? Test for Version Regression (Where that is stated or suspected)
**#* For windows users use of Portable ESR may be a simple method of doing that.
**#* More complicated as it is likely to involve multiple profiles and possibly multiple installs is to install & test the previous version AND the current Release. <br /> (We are doomed to failure attempting to file bugs for issues reported along the lines of: "It occurred in Firefox two versions ago. The last version also did not work. I am not willing to test and reproduce in the current Release )
**#*Mozregression is probably ideal. For the more advanced users It is actually fairly simple to use. <br /> (Firefox is easy and simple to use. Not all user are capable of tasks like copying and pasting or finding hidden files without guidance, but if a problem is real and affects many, some of those users will be more able to help us.)
*** IS IT A WASTE OF EFFORT Most problems will probably be from users with many addons in use. We can probably do little to help them. '''But''' Hey we may get another Fx4 type regression showing up, or a Tens of Millions of users addon issue like ABP
** '''about:memory results.''' We do need some method of obtaining developer or HelpDesk advice on about:memory results, prior to us being in a position to file a bug. <br />Until we have anything better we have the ability simply by escalating threads, and should remind contributors to do that.
** '''Bugs''' We should escalate, follow up; and where applicable file bugs. <br /> It is important to ensure good quality bugs with STR are filed. We must not encourage filing of low quality bugs that stand no chance of being investigated.
* We should as a matter of policy ''' ESCALATE any and all memory related questions ''' that are not almost immediately solved, but importantly '''only''' where the user is able and willing to troubleshoot and help us. Otherwise all we do is waste HelpDesk and contributors' time.
* Would '''developers''' interested and working on memory or performance issues, or maybe someone from '''QMO''' or '''MDN''' be willing to look at and suggest improvements to our KB articles on [[Firefox uses too many CPU resources - How to fix |CPU]], [[Firefox uses too much memory (RAM) - How to fix |Memory]] & [[Troubleshoot and diagnose Firefox problems|Troublshooting]] [[Firefox Support troubleshooting guide |&]] ? <br /> Possibly keep the KB articles simple and end user focussed, but link to &/or write more technical & detailed articles for use by contributors.