Users reporting performance issues, cannot reproduce

Hi, some of our users are reporting performance issues in the sense that our add-on slows down their browser. The thing is, I cannot reproduce it. Does anybody have an idea what to do?

  • Can this be caused by other add-ons that interfere (how?)?
  • Can my add-on see what other add-ons are installed? I guess not, for privacy reasons.
  • Can my add-on somehow notice that it’s getting slow? I’m not sure how this might work, as users report it’s the browser that’s getting slow, not the core feature of our add-on.

Our add-on is this: https://addons.mozilla.org/de/firefox/addon/languagetool/

1 Like

It can make a huge difference whether separate content and extension processes (e10s) are enabled.
If the extension lives in the main process, you can use requestIdleCallback. The function below will resolve after around 1.5 times the input time if the process idles, but can take much longer if it is busy. It doesn’t add to much stress to the system, I think awaiting 1000 idle msec should give you a fare estimate.

function waitIdleTime(time) { return new Promise(done => {
	const start = performance.now();
	requestIdleCallback(function loop(idle) {
		const left = Math.max(5, idle.timeRemaining()); time -= left;
		if (time <= 0) { done(performance.now() - start); }
		else { setTimeout(() => requestIdleCallback(loop), left + 1); }
	});
}); }

If the extension is not hosted in the main process, you could add a browser.* API call every iteration, that forces Firefox to do RPC and enter the main processes event loop (you have to make sure to use a call that is cheap itself and needs to do RPC every time, something in browser.tabs should do).
If content process are active you may also want to ping a content script.

1 Like

Thanks. I’m trying to understand… Where would I put this code, in the background script? Also, whether e10s is enabled or not is a browser setting that’s not under my control, isn’t it? I also cannot programmatically detect it? Or are you suggesting that your code snippt will be slow exactly in those cases where e10s is not enabled?

whether e10s is enabled or not is a browser setting that’s not under my control, isn’t it?

Yes.

I also cannot programmatically detect it?

I’m pretty sure that there is no API for it, there may be some bugs you can detect that only occur whis e10s enabled or disabled.

Where would I put this code, in the background script?

The code I posted would take longer if the load in the current process is high, so unless you want to detect the load in a content process, you’d run it in the background context.

Or are you suggesting that your code snippt will be slow exactly in those cases where e10s is not enabled?

Well. Unless you are doing stupid calculation in your background page, the code will not be slow if e10s is enabled. If it is not slow, you can’t conclude much more without running the additional API call test I suggested or asking the user whether e10s is enabled.

I actually just found a (not very useful) example for this: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/option#compatNote_2