Opened on 05/11/2015 at 04:23:47 PM

Closed on 01/05/2018 at 02:56:52 PM

#2504 closed defect (rejected)

about:performance reports lots of CPOW

Reported by: David Rajchenbach-Teller Assignee:
Priority: Unknown Milestone:
Module: Platform Keywords:
Cc: greiner, tschuster, mapx, sebastian, kzar Blocked By:
Blocking: Platform: Firefox
Ready: no Confidential: no
Tester: Unknown Verified working: no
Review URL(s):


Recent Firefox Nightly builds offer about:performance, which offers some information on the performance of add-ons. Side-note: I know that the UX of that page sucks, suggestions are welcome.

Well, ABP seems to use lots of CPOW. That's annoying, plus it tends to trigger the slow add-on warning a lot.

How can we solve this?

Reminder: I'm Yoric on

Attachments (0)

Change History (16)

comment:1 Changed on 05/11/2015 at 06:11:40 PM by mapx

  • Cc trev greiner added
  • Platform changed from Unknown to Firefox/Firefox Mobile

comment:2 Changed on 05/11/2015 at 06:54:15 PM by trev

  • Cc tschuster snoack added

Yes, we are aware of that. The main issue is likely our nsIContentPolicy implementation. This one can be moved to content, that's merely work. It won't eliminate the issue completely - the decision on whether something should be blocked has to be made synchronously, meaning that a synchronous message will be required (a bit of caching can be applied). Note that making this decision in content isn't realistic from our experience with E10S in Fennec, it will lead to a huge overuse of memory. Still, this will be a lot better than collecting the context from the chrome process which requires a number of DOM objects to be accessed through CPOW.

The plan right now is to have the messages translated into something similar to Chrome's webRequest API in the chrome process. We are already faking that API in Safari, so this would allow unifying the logic here. However, this isn't currently part of our roadmap. Do you know anything on when Mozilla plans to move on with E10S? This would help prioritize this change - it isn't going to be a small one.

comment:3 Changed on 05/11/2015 at 08:20:53 PM by David Rajchenbach-Teller

Definitely this year. I do not know of definite plans, but there are discussions on switching Aurora to e10s in June.

comment:4 Changed on 05/12/2015 at 07:08:17 AM by mapx

  • Cc mapx added

comment:5 Changed on 05/12/2015 at 07:04:50 PM by tschuster

I think should be interesting. I don't know how similar it is to the webRequest API, but I want to try porting our chrome addon code tomorrow.

comment:6 Changed on 05/14/2015 at 08:48:15 PM by trev

Unfortunately, it has the exact same limitations as Chrome's webRequest API - it's very hard and error-prone to get the context of a request (e.g. document URLs). However, we should be able to create similar custom solution that will send sufficient context info as well.

comment:7 Changed on 05/14/2015 at 11:25:34 PM by David Rajchenbach-Teller

You really should start a conversation on dev-platform on whichever API you need.

comment:8 Changed on 05/16/2015 at 12:48:19 PM by tschuster

I just ported our webRequest based filtering from Chrome to Firefox. Something we really need is a way to go from window/parentWindowId to the corresponding URL. We could probably maintain that mapping ourself, but I think this is a valid usecase.

Something else that would be good to have is the whole frame to top-window chain, instead of just the parent.

comment:9 Changed on 05/20/2015 at 02:22:39 PM by philll

  • Platform changed from Firefox/Firefox Mobile to Firefox

Made Firefox and Firefox mobile available as seperate platforms.

comment:10 Changed on 05/21/2015 at 09:34:30 AM by David Rajchenbach-Teller

trev, tschuster: There is an ongoing discussion on dev-platform on how to best do this. You should really take part in the conversation.

comment:11 Changed on 08/01/2017 at 03:14:57 PM by sebastian

  • Cc sebastian added; snoack removed

comment:12 Changed on 12/21/2017 at 11:28:41 AM by fhd

  • Cc trev removed

comment:13 Changed on 12/22/2017 at 09:47:54 AM by kzar

  • Component changed from Unknown to Platform
  • Tester set to Unknown

comment:14 Changed on 12/22/2017 at 09:49:18 AM by kzar

  • Cc kzar added

Is this issue still relevant since the switch to WebExtensions, or is this now a duplicate of #6067 / #6050?

comment:15 Changed on 01/05/2018 at 02:13:26 PM by tschuster

WebExtensions can't have CPOWs. So this specific problem can't exists anymore. Obviously like the linked issue we can still have performance issues caused by other bugs.

comment:16 Changed on 01/05/2018 at 02:56:52 PM by kzar

  • Resolution set to rejected
  • Status changed from new to closed

Alright I'll reject this issue then, thanks.

Add Comment

Modify Ticket

Change Properties
as closed .
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from (none).
Note: See TracTickets for help on using tickets.