Poor multi-tab user responsivness is caused by primitive FF multi-tasking/ threading.
Could this note be referred please, to the FF programming manager? First my congrats on FF overall of course, to you and your many volunteers. But I notice a large philosophical programming problem which you might consider.
This problem mostly shows with multiple tabs open. Web servers certainly are slow, and many pages' Html etc poor. This all results in lots of delays such as reported during:
Waiting for () Read () Transferring data from () Performing a TLS handshake to () Connecting to ()
These display the moving "working" dot in the left of the affected tab title. And less often, "(not responding)" in FF's title bar, which eventually gets cleared automatically.
I have reviewed all 17 screens, and a number of the individual results, from today's FF forum search of:
169 results for (not responding) for Firefox
None address the lack of prioritized co-operative multi-tasking/ threading, DURING such delays as "Waiting for ()". During such a necessary wait, it is very slow at best, e.g. for a user to switch tabs. Even to one which is ready for display.
Responsiveness to user input should be the top multi-tasking priority. Tab switching. Rendering/ display of the foreground tab. Scrolling that down. Tab closing by user!, and "X" to STOP a page from loading -- give those user clicks priority. Let's not have to wait 10 seconds for a right-click to open its option box. Let the other busy tabs finish up their work, overlapped in the background priority-wise.
This could be done now, but perhaps it would be difficult for volunteer programmers. Worse case might require a custom replacement, for the effective TCP part of the default vanilla TCP/IP stack. However I suspect a lot could be fixed short of that, with the correct management encouragement and guidelines. At least if the continuous motion of the "busy dot" indicator in the tab title is a task, just change that to something like just gray-ed out while busy.
My experience is with much headroom: CPU (50%), memory, disk, and network bandwidth, per Task Manager. NO McAfee. Mainly just ZoneAlarm taking 30% of that CPU 50% usage. This is not a problem with start-up delay. And delays within only one open tab are necessary, of course. Cheers
Modified by Would say boo
Additional System Details
NoScript. All other add-ins disabled.
- User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0
The people who answer questions here, for the most part, are other Firefox users volunteering their time (like me), not Mozilla employees or Firefox developers.
If you want to leave feedback for Firefox developers, you can go to the Firefox Help menu and select Submit Feedback... or use this link. Your feedback gets collected by a team of people who read it and gather data about the most common issues.
Thank you, FredMcD, I have done that. If you don't mind, I will leave this thread open here too. If someone else finds it, who has the same problem or observations, it may save them some typing. Regards
Start Firefox in Safe Mode to check if one of the extensions ("3-bar" menu button or Tools -> Add-ons -> Extensions) or if hardware acceleration is causing the problem.
- switch to the DEFAULT theme: "3-bar" menu button or Tools -> Add-ons -> Themes
- do NOT click the "Refresh Firefox" button on the Safe Mode start window
It is possible that your firewall or other security software blocks or restricts Firefox without informing you, possibly after detecting changes (update) to the Firefox application. Remove all rules for Firefox from the permissions list in the firewall and let your firewall ask again for permission to get full, unrestricted, access for Firefox and the plugin-container process and the updater process.
Boot the computer in Windows Safe mode with network support to see if that has effect in case security software is causing problems.
Thank you. Cor-el -- many good single-tab suggestions, perhaps of value to other readers. And improving single-tab performance certainly reduces the impact of multi-tab problems.
I have pursued all those pertinent suggestions myself, either previously or just now, and will retain them for future re-reviews. In fact my ZoneAlarm firewall using even 30% of CPU was a clue. My refreshing its data-table reference to FireFox, after the latest update to 68.0.2 at least, helped me.
The pages/ servers demonstrating the multi-tab stickiness I see are behind private login, so I'm sorry I can't refer you directly. If I notice a public example, I will. Picture each page, which self-indulgently refers to 35+ other servers. At least one of which servers is usually very slow. Not FF's problem directly, single-tab. FF certainly abides, until done finally. But even Windows occasionally notices FF's "(not responding)".
And I notice, slow UI response attempting another tab. If it was my responsibility, I would set up a test server which could be artificially handicapped. However I'll leave that to the FF programmers. Regards