Proposal: Provide reporting event for browser's slow extension warnings

[kzar]

Background

Browsers sometimes display a warning to the user that one of the browser extensions that they have enabled is slowing down their experience. Browsers seem to trigger such warnings under different circumstances, and there doesn't appear to be much documentation around this, or ways for extension developers to diagnose the performance issues. It would be nice to support extension developers in proactively improving their extension's performance.

Suggestion

• Provide some way of reporting performance issues to extension developers in an actionable way. For example, perhaps an event could be fired that included at least some details (e.g. a stack trace) of the slow extension code? I realise this would need to be balanced with user privacy however.
• I believe that so far, Firefox will warn the users if a content script is extremely slow (and the user tries to interact with the page), whereas Chrome will warn the user if a background script (in particular inside a blocking onBeforeRequest event handler) is slow. Perhaps the event could also include a description (e.g. "Slow content script", or "Slow onBeforeRequest handler") to point developers in the right direction?

References

• https://searchfox.org/mozilla-central/source/dom/ipc/ProcessHangMonitor.cpp#63-86
  • "EXTENSION NAME" is slowing down Firefox. To speed up your browser, stop that extension. Learn more <Stop>
• https://source.chromium.org/chromium/chromium/src/+/main:extensions/browser/warning_set.cc;l=71-80;bpv=1;bpt=1
  • This extension is slowing down Google Chrome. You should disable it to restore Google Chrome's performance.

[patrickkettner]

May I suggest you change the issue to be just about the reporting portion? While I agree with everything, I do not believe this is the right venue you for the conversation for topics other than the reporting piece. The WECG does not provide documentation, and what actually triggers such a warning is an implementation detail, rather than something that would normally be covered by standards.

[kzar]

Thanks for the feedback @patrickkettner 👍 , I've updated the issue.

[dotproto]

While this group has not produced documentation and we don't have immediate plans to do so, I should note that that kind of material is within the scope of community group deliverables:

Community Group deliverables may be anything, including documents, test suites, tutorials, demos, code, discussion, etc.

- https://www.w3.org/community/about/process/#deliverables

For instance, a Community Group might … convene to have discussions about a tutorial for an existing specification.

- https://www.w3.org/community/about/faq/#what-is-a-w3c-community-group

As I see it, the critical question is whether group members are interested in and motivated to work on this kind of deliverable. If so, I think we can make room in the WECG tent for folks to pursue such projects. I'd only caution that our primary focus in the WECG has been building consensus across browsers and specifying a common WebExtensions platform, so there may be limited interest in creating tutorials or other reference documentation.

Or to put it another way, if a member says, "I want to create a guide for X," I'm happy to support their efforts. But if someone says, "I think the WECG should make a guide for X," that's going to be a harder sell.

[dotproto]

I'm intrigued by the idea of a performance reporting API. I currently feel that extension performance is notably different from website performance in that a poorly performing site slows down a single origin while a poorly performing extensions can slow down the entire browser. While browser vendors and community members can create reference material that helps extension developers better understand how to leverage existing tools and APIs to monitor and measure extension performance, I think we should consider how the platform itself can help steer developers in the right direction.

At the moment I'm imagining an API that allows platform implementers to notify an extension about a variety of conditions, such as a long loop, slow function calls, slow scripts injected into pages, aggregate time of injected script execution, abnormal impact on the user's battery, frequent wakes without work, etc. Such an API could be structured so that it covers the mechanisms used to notify an extension of abnormal conditions, the shape of the events, the format browsers use to identify the relevant file and line number, and other relevant data without being prescriptive about what performance events browsers support.

I'm curious how browser reps feel about this general direction.

[kzar]

At the moment I'm imagining an API...

Yea, that's definitely an interesting idea. Perhaps if we did add the "bad performance" event I proposed, browser vendors could think of additional situations in which to fire that event. Anything that gives developers something actionable like a stack trace and a brief description sounds good to me.

My perspective is mostly as an extension developer. Over the years, I've debugged these issues a few times:

• Sometimes, you know roughly what code is slow. For those cases, you can make sure there's decent test coverage, start measuring the performance to get a good baseline, then start experimenting with changes. Sometimes the required changes aren't obvious, e.g. when the JavaScript engine is able to optimise certain ways of doing things, so trial and error is required. The profiling tools and things like the performance API can get you there, so long as you put the work in.
• Sometimes, you get a bug report from a user. Usually the bug report will be something vague that mentions either that the extension is slow, or that a website is slow, or that they saw a warning about the extension being slow. Debugging these kinds of reports can be really hard. With no way to reproduce the issue, or idea about the cause, it wastes a whole bunch of time trying random things. You know there's a problem somewhere, and maybe which website the problem can trigger the problem... but not much else! I've spent weeks investigating problems like this before. If I could be proactively sent stack-traces and some kind of description by the extension, it would save a whole bunch of my time + user frustration!

In any case, the more I think about it, the more I think this is a good idea. Showing a warning to the user should be a last resort really. Also making that warning available to developers seems like a minimum, and sharing extra warnings with developers as a proactive/preventative measure like @dotproto suggests would be even better.

[xeenon]

While a good idea, I have some concern with having an API for this.

• What is an extension expected to do in response to this event firing? (This likely needs actionable details in the event to be useful.)
• Can an extension even do anything if it is hung in its process? The event might be undeliverable.)

[kzar]

What is an extension expected to do in response to this event firing? (This likely needs actionable details in the event to be useful.)

Good question, here's an example of how I see the event being used:

In the DuckDuckGo Privacy Essentials browser extension, we attempt to protect the user by blocking requests to tracking scripts, and things like that. Sometimes those protections cause a website to break, at which point the user can disable protections by clicking on the extension's icon and clicking to disable protections in the popup UI. If they do that, they are asked if they'd like to report the website as broken. If they do, they are asked a few questions and a breakage report is sent in to us, which includes relevant details such as which protections were active on that page.

If we had this "bad performance" event, the first thing I'd like to do would be to listen for it, and then include details of when it fired with any related breakage reports. It would be hugely useful to have something like a stack trace and a note for performance issues included in those reports. If we saw a spike in breakage reports pointing to the performance of some specific piece of code, the issue would be much easier to address.

Another option, which maybe would be more controversial, could be that the API works in a similar way to runtime.setUninstallURL. Perhaps then, the reports could be fired off in a similar way to CSP violation reports.

Can an extension even do anything if it is hung in its process? The event might be undeliverable.)

Yea, that's a good point. I think some of the time the event would be deliverable, depending on the browser and which process had hung or what the warning was related to. That's my guess at least, it would be good to loop in some more browser devs to check that. Perhaps sometimes the event would not be immediately deliverable, but I think the event would still be useful to extension devs even if it fired with a delay.

I suppose if we went with the runtime.setUninstallURL style API instead of an event this would be less of an issue.