Open Bug 1280368 Opened 4 years ago Updated 1 year ago
Implement asynchronous content blocking API
Over time the needs changed and we should consider implementing an asynchronous API for content blocking which could replace nsIContentPolicy. Let's gather some thoughts and ideas within this bug as a first measure.
For reference, this is currently causing performance issues in Adblock Plus with e10s. Our content process code needs to query the parent for content policy decisions because that's where the state is. Currently it has to happen synchronously because nsIContentPolicy requires a synchronous decision - so rather than delaying a single network request slightly we block the entire content process every time. IMHO, that's what is causing the issue described in bug 1192585 comment 17.
4 years ago
Severity: normal → major
It's normal that ADP make terrible slow down some pages when e10s is on and dom.ipc.processCount;8, even when I turn off any filter nad "Count filter hits" option? I load 80 page with "Open all in Tabs" option and get this: 80x http://www.thecrims.com/ ADP ON (without any filter): 138s, 136s, 139s ADP OFF: 22s, 24s, 22s 80x https://www.wikipedia.org/ ADP ON (without any filter): 16s, 17s, 19s ADP OFF: 9s, 9s, 9s I use I7-2600k, 32GB RAM, HDD 7200rpm, Win7 64bit, FX Nightly 64bit. When I turn off e10s results are terrible, even when turn off ADB, but it's FX problem (older version was much bether in this area: https://bugzilla.mozilla.org/show_bug.cgi?id=1140892). But for e10s finally there is some progress. Why ADP so much affect the first domain?
Of course not ADP but ABP:) Even when I made "Disable everywhere" (ABP icon becomes gray) slowdown still exist. To make the tests I must turn off ABP in standard way (through about:addons).
Priority: -- → P3
Whiteboard: [domsecurity-backlog] → [domsecurity-backlog1]
You need to log in before you can comment on or make changes to this bug.