Re: Issue 128196 in chromium: AdBlock extension causes renderer memory utilization to double

[chro...@googlecode.com]

Comment #2 on issue 128196 by bat...@chromium.org: AdBlock extension causes
renderer memory utilization to double
http://code.google.com/p/chromium/issues/detail?id=128196

I have not looked closely into the rule database that is injected, but I
hope that this becomes better with the declarative WebRequest API. I would
like to introduce actions that inject CSS or execute a JavaScript callback
based on specific URLs. The rules would be registered only once per
profile, not once per frame.

[chro...@googlecode.com]

Updates:
Status: Available
Owner: ---
Cc: erik...@chromium.org kei...@chromium.org ericdin...@chromium.org
jhurw...@chromium.org

Comment #3 on issue 128196 by erik...@chromium.org: AdBlock extension

causes renderer memory utilization to double
http://code.google.com/p/chromium/issues/detail?id=128196

Dominic, don't they have a test version that uses the new API already? Is
it possible to test to see if this improves the situation?

I do agree that we should be tracking memory impact of our top extensions
in the store. There are a few things that could help us to do this. One
is that we're working on some new page cycler tech that should make it
easier for us to run extensions through repeatable sets of pages. The
second is that we're adding some better server-side analysis into the
publish pipeline which could run this kind of page cycler test
automatically and track differences. These building blocks are only just
coming together now though, so I don't think anyone will be able to look at
this kind of thing until next quarter at the earliest.

[chro...@googlecode.com]

Updates:
Cc: joc...@chromium.org

Comment #4 on issue 128196 by bat...@chromium.org: AdBlock extension causes

renderer memory utilization to double
http://code.google.com/p/chromium/issues/detail?id=128196

I discussed this with Jochen today. We believe that the Declarative Web
Request API with simple CSS and JavaScript injection is not a solution. We
need to introduce a notification mechanism that triggers a listener and
passes the DOM element that was blocked. The good new is that we now have a
plan that is likely to be accepted by the WebKit folks (thanks, Jochen!):
---
we add callbacks to the frame loader client for when the different resource
types we're interested in failed to load, e.g. HTMLImageElement (or image
loader probably) would call
frame->loader()->client()->notifyImageFailedToLoad(this, error) and so on.

If something is blocked by an extension, we would pass in a special html
error code. Now when render view (our frame loader client) is invoked with
that special error code, we know that the request failed due to an
extension.
---

The implementation should work likewise for the old and the new WebRequest
API. It's on my agenda.