Opened 5 years ago

Closed 2 years ago

#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

Change History (16)

comment:1 Changed 5 years ago by mapx

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

comment:2 Changed 5 years ago 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 5 years ago 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 5 years ago by mapx

  • Cc mapx added

comment:5 Changed 5 years ago 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 5 years ago 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 5 years ago by David Rajchenbach-Teller

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

comment:8 Changed 5 years ago 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 5 years ago by philll

  • Platform changed from Firefox/Firefox Mobile to Firefox

Made Firefox and Firefox mobile available as seperate platforms.

comment:10 Changed 5 years ago 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 3 years ago by sebastian

  • Cc sebastian added; snoack removed

comment:12 Changed 3 years ago by fhd

  • Cc trev removed

comment:13 Changed 3 years ago by kzar

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

comment:14 Changed 3 years ago 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 2 years ago 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 2 years ago by kzar

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

Alright I'll reject this issue then, thanks.

Note: See TracTickets for help on using tickets.