Slugish response from UI during general usage

RESOLVED WONTFIX

Status

()

RESOLVED WONTFIX
a year ago
a year ago

People

(Reporter: andrixnet, Unassigned)

Tracking

({perf})

52 Branch
All
Windows
Points:
---

Firefox Tracking Flags

(firefox-esr52-)

Details

(Whiteboard: [fxperf])

Attachments

(2 attachments)

(Reporter)

Description

a year ago
I work in a public institution environment and this report is based both on my personal experience and on technical support I provided to various users.

Mine and most of our systems run the ESR branch (for obvious corporate strategical reasons) and also to facilitate (and extend the timeframe for) the transition between the feature changes introduced by FF57, so we run at FF-ESR52 latest. 

Most our systems have been kept up to date by small incremental steps with each update that appeared, however there is a small number of systems that still run an earlier version and discoveries while upgrading these prompted me to write this bug report. 

At this time most our systems run at FF-ESR-52.5.2 (latest at the time of writing this report) on win 7 systems, with a few leftovers on XP and Vista.

General usage show an increasingly sluggish experience. FF UI seems to stop responding from fraction of seconds (but observable and annoying) up to several seconds (but OS does not regard it as "not responding")

It happens immediately after startup, it takes a good number of seconds to respond to user input and intermittently does not react to user actions, including hover. 

It happens often on most websites that FF UI does not respond to user actions, including hover not only over webpage contents, but also all FF UI controls, such as bookmarks toolbar, menubar, location bar. 
Most response interruptions occur while webpage is loading (and probably rendering), but they also happen while scrolling or interracting with the page such as hovering over interractive content such as menus. Some webpages that make significant use of Javascript are barely usable.
This includes scenarios of 3-7 open tabs on i7 @3.8GHz systems as well.

While FF exhibits lack of response I can't establish a direct corelation with CPU usage because most of the behaviour is intermittent, but also because it doesn't show up as usage spike followed by flat high usage until UI reponds again. 

Examples of UI sluggishness:
- FF does not respond to mouse over or mouse click on bookmarks toolbar, menubar, location bar
- FF does not respond to vertical scrollbar drag attempts
- typing into a text input field / textarea (plain or rich) does not happen until FF responds again, and after that some of the typed characters get written into the field, but not always all of them. 
- loading animation icon on tabs halts while FF does not respond

The appliable scope on of this bug on the performance of FF is broad enough that I cannot cite specific websites. It applies to most modern websites, including Facebook and YouTube. It seems to apply less to websites with simpler CSS and less JS. 

The problem gets much worse with increasing number of open tabs. 

Disabling/Enabling addons seems to have no distinguishable effect. 
Examples of addons experimented with: adblock (applied to all sites), classic theme restorer, firebug, web developer toolbar.

Problem report is based on general browsing experience and general usage. I carried out various experiments navigating various websites, increasing and decreasing the number of open tabs, enabling and disabling addons. 

One corelation I was able to establish was the following: 
having known about the problem (I personally experienced it as a gradual decrease in performance during the past major version updates), I tried to use several of the systems that still had existing installations of FF47 and FF49, then upgrade to FF-ESR-52-latest, then redo the same usage pattern (during the same day). I did this for several systems, using existing user profiles. 
The result was that overall performance has decreased and user experience has worsened significantly after arriving at FF-ESR-52-latest.

I do not have other [real world, not sterile test] installations with intermediate versions such as 50 and 51 to perform additional tests and downgrading doesn't seem to work because of profile file format changes.

My own personal experience using FF indicates that a significant performance loss began to occur sometime during the FF-ESR-52 branch, with early versions still working reasonably well, but since 52.4.x or 52.5.x performance and it's impact on user-experience has got distinguishably worse.

Updated

a year ago
Has STR: --- → no
tracking-firefox-esr52: --- → ?
Keywords: hang
(Reporter)

Comment 1

a year ago
I would like to add several more details: 

On some FF-ESR-52 installations with several add-ons such as firebug, adblock, classic theme (I can provide complete list, but still happens with them disabled) I encounter quite often an interval of several seconds when FF hangs after startup.
* start FF
* FF is up and running and responding (several seconds)
* FF hangs, no response (several seconds)
* FF resumes responding (overall behaviour is degraded as reported)

Reproducing this is quite consistent, however OS caching makes subsequent starts faster and the hang period sometimes seems shorter. 

Clicks and keypresses issued before and during the non-responsiveness reported are properly processed after FF resumes responding. However this hang of several seconds soon after startup fails to process some of the keypresses issued during the responding interval between startup and hang.

Further sluggish behaviour follows the pattern described above.
Downgrade to FF-ESR-52.2 doesn't seem to help much.
(Reporter)

Comment 2

a year ago
Disabling some addons that fetch data from internet during initialization (such as a weather widget) may have some barely noticable impact, but I am not sure and I'll have to retest on a slower computer. 
Question: can an addon (web-extensions based) run some blocking code during UI initialization or network traffic?
(Reporter)

Comment 3

a year ago
Overall sluggishness as reported is not however influenced by such addons being enabled.
Firefox 52 doesn't benefit from the performance improvements in later releases, multiple content processes in particular. Hangs like the ones mentioned above were some of the motivating factors for these changes. Furthermore, the use of legacy add-ons is a common trait in this type of performance problem. 

To properly debug this issue we need the contents of about:support and a performance profile when the browser is misbehaving. Here is a guide about getting a profile:

https://developer.mozilla.org/docs/Mozilla/Performance/Reporting_a_Performance_Problem

We can rule out add-on interference if you can reproduce the issue in safe mode:

https://support.mozilla.org/kb/troubleshoot-firefox-issues-using-safe-mode
Flags: needinfo?(andrixnet)
still needs info from Andrei

The symptoms described in comment 0 and comment 2 are more moderate to severe performand, not hang
Keywords: hang → perf
Whiteboard: [closeme 2018-01-25]
(Reporter)

Comment 6

a year ago
Posted file about_support.json
about:support data, as requested.
Flags: needinfo?(andrixnet)
(Reporter)

Comment 7

a year ago
Performance profile analysis, as requested.
(Reporter)

Comment 8

a year ago
I made a test as follows: 
- start Firefox
- open Facebook (automatically logged in)
- open Yahoo classic mail
- open http://wiki.openstreetmap.org/wiki/Map_Features (a fairly large static page)

During each time the loading indicator animation stopped, the UI did not respond, including any mouse-over effects, clicks to items such as location, menu, trying to drag a scrollbar, etc.

This scenario is profiled in the attachment above. 

I've also tried with addons disabled: same scenario with 3 tabs, same URLs. The problem with UI response continues to be present with approximately the same severity. (I say approximately, because at different times, the hangs may be longer or shorter, but definitely a hinderence).

I've also attached about:support info.
(Reporter)

Comment 9

a year ago
I've also tried with "hardware acceleration disabled", no change.

Updated

a year ago
Whiteboard: [closeme 2018-01-25]
Whiteboard: [qf:?][fxperf]
Flags: needinfo?(mconley)
Flags: needinfo?(mconley)
Whiteboard: [qf:?][fxperf] → [qf][fxperf]
(In reply to Andrei Boros from comment #7)
> Created attachment 8947019 [details]
> Firefox 2018-01-31 12.20 profile.sps.json.gz
> 
> Performance profile analysis, as requested.

This profile shows long periods of unresponsiveness caused by add-ons, and some periods of unresponsiveness caused by JavaScript running in web pages (e10s is disabled).

There's no way we can help with performance on the 52 branch, it's just too old at this point. If you can reproduce with Firefox 57 or later, please attach a profile of it, thanks.
(Reporter)

Comment 11

a year ago
Since this discussion is about FF-52-ESR, what does "ESR" stand for exactly? Especially with regard to how this issue is handled. Security updates only?
(In reply to Andrei Boros from comment #11)
> Since this discussion is about FF-52-ESR, what does "ESR" stand for exactly?
> Especially with regard to how this issue is handled. Security updates only?

Yep, security updates only.

See https://www.mozilla.org/en-US/firefox/organizations/ for details - in particular:

"Maintenance of each ESR, through point releases, is limited to high-risk/high-impact security vulnerabilities and in rare cases may also include off-schedule releases that address live security vulnerabilities. Backports of any functional enhancements and/or stability fixes are not in scope."
As noted by Panos, these kind of issues are out of scope for ESR releases, so not tracking it.
tracking-firefox-esr52: ? → -

Comment 14

a year ago
(In reply to Andrei Boros from comment #0)
> I work in a public institution environment and this report is based both on
> my personal experience and on technical support I provided to various users.


Are you by chance running the user profiles from a networked location?  If so, does the issue go away by using a local profile?
Duplicate of this bug: 1436770
(Reporter)

Comment 16

a year ago
No, all profiles are stored on local disk. Only OS login credentials and policies handled across the network.
Whiteboard: [qf][fxperf] → [fxperf]
ESR won't get the latest performance fixes until 60 IIRC, so I will close this bug. You can contact the enterprise mailing list if you want to discuss this topic or potential mitigations further.
Status: UNCONFIRMED → RESOLVED
Last Resolved: a year ago
Resolution: --- → WONTFIX
There is a discussion about esr performances issues in bug 1436297
You need to log in before you can comment on or make changes to this bug.