1124073 - [e10s] UX for Notifying user of addons that are slowing their browser down significantly

Status: RESOLVED WONTFIX

(Toolkit :: Performance Monitoring, defect)

Description

[Brad Lassey [:blassey] (use needinfo?)]

splitting this off from bug 1071880 with the intention of landing a basic UX there and having more involved UX discussions here.

Comment 1

[alex_mayorga]

Why not put this bar at the top like the "slow script" one or the now gone "pop-up blocked" one?

Comment 2

[Thomas Stache]

(In reply to alex_mayorga from comment #1)
> Why not put this bar at the top like the "slow script" one or the now gone
> "pop-up blocked" one?

Because it is not tab-specific like your examples. The lower bar is for global things, like Sync errors.

Comment 3

[Brad Lassey [:blassey] (use needinfo?)]

One suggestion I received via twitter was to include data in the UX (perhaps with a "more info.." button). This could take the form of "addon Y is taking X% of your CPU" or "caused Firefox to skip Z frames" or some combination of the two.

Comment 4

[avada]

Will it also include memory usage statistics?
When a lot of memory is leaked away you get quite horrible hiccups/hangs and general slowness.

Comment 5

[Andrew Halberstadt [:ahal]]

I find the current UX a bit anxiety inducing. Basically I'm getting told my favourite extension ever is making Firefox slow and I'm being forced to choose between the functionality of the extension and performance of the overall browser. This is an apples to oranges comparison and I have no way of knowing which is the better option. Usually I hover over "Ignore Forever" and "Disable" for a few seconds as my mind has an internal struggle before finally clicking "Ignore for now". Then I go through the same process again the next time I restart my browser. I do not find this a pleasant experience.

It's possible that having more data as per comment 3 will help out a lot, but hard to say. Personally I'd prefer if users had to explicitly ask which extensions were being slow instead of being told.. after all, ignorance is bliss.

Comment 6

[David Teller [:Yoric] - still alive but not very active]

The Addon Watcher now computes a cause and a gravity (which it uses to update the histograms). It would be pretty easy to expose both to the front-end, if someone will design the UX.

(In reply to avada from comment #4)
> Will it also include memory usage statistics?

Not yet. Memory is something that we don't know how to track per addon yet. Progress on that front is handled in bug 1123434.

Comment 7

[David Teller [:Yoric] - still alive but not very active]

Bug 1188966 will tell us a bit about how people react to the current UX.

My personal experience (and 100% of the feedback I have received so far) is that the current notification is annoying, and doesn't feel very useful. This may be something that may be fixed bug 1188616 or bug 1189066, or this may be something that requires UX love.

One thing we could do to make things a little clearer for the user is merge "Ignore permanently", "Ignore for now", the "X" and the auto-closing into something that ignores the next N alerts, then the next N*2 alerts, then N*4, ... and, of course, persist the choices across restarts.

Another thing we could do is show the notification only once per browsing session instead of once per 15 seconds.

Another thing we could do is replace the notification with "Something seems to be slowing down your Firefox: <Get rid of it> <Show me what>", where <Get rid of it> disables add-ons and <Show me what> shows about:performance.

Also, the initial plans that I heard of for this feature was to make it part of the Self-Support UX, so we could simply get rid of the notifications and just keep the underlying API, letting Self-Support deal with notifying users.

Comment 8

[David Teller [:Yoric] - still alive but not very active]

Erin, any news about UX reinforcements?

Comment 9

[Florian Quèze [:florian]]

about:performance is being redesigned; mass closing the bugs related to parts of the current about:performance page that we are not keeping.

Our goals with the redesign are to reduce the overhead caused by having the page opened, increase the reliability of the displayed information, and make the offered information actionable for most users. The back-end work is being tracked in bug 1419681.