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): | |||
Description
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 irc.mozilla.org
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
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 https://bugzilla.mozilla.org/show_bug.cgi?id=1157561 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.
https://groups.google.com/d/msg/mozilla.dev.platform/wl1IAsLKMNA/GOBMFxF9aX0J
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
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.
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.