Webrequest

[Zlip792]

@Palant
I think there maybe some Developer tools related extension which may need some experimental API so that's what it maybe... Well, I am really hoping for WebRequest API in Chrome 17. Personally I use FF Nightly.

[Wladimir Palant]

Unfortunately, this change shows that they don't expect webRequest API to become final in Chrome 17 - otherwise landing this change there would be unnecessary.

[tomhedd]

Your new experimental extension works like a charme. There are just a few bugs in noticed. I hope they were not posted somewhere else in the forum.
The experimental extension doesn't hide the placeholders like it should. The option is activated!
Some examples: www.kicker.de between the side's navigation bar and the articles and www.spiegel.de there is still a small bar at the top. I have more examples but I think it was already said in this forum.
Keep up the good work. Adblock Plus is nearly perfection like on Firefox!

[Wladimir Palant]

Well, you don't see the placeholders so the option is working. There is currently no proper way to free the space like in Firefox however: http://crbug.com/97392

[Anomalous]

@Zlip792: I'm not sure this change is relevant for us. If I understand correctly, Webstore is now allowed to install extensions using experimental API. We would still need to be allowed to upload an experimental extension there in the first place however. And I'm not sure that whitelisting Adblock Plus is what they had in mind.

This is probably a dumb idea, but how exactly does their ban on experimental extensions work? Is it just a simple wordfilter, or does it actually run/analyze the code somehow? For instance, would it stop you from doing this?

Code: Select all

var x = "e" + "x" + "p" + "e" + "r" + "i" + "m" + "e" + "n" + "t" + "a" + "l";
var w = "w" + "e" + "b" + "R" + "e" + "q" + "u" + "e" + "s" + "t";
var wr = chrome[x][w];

[Wladimir Palant]

@Anomalous: Tricks like this are perfect to get your extension banned from the gallery. Anyway, it doesn't work like this. Each extension has to declare the APIs it uses in its manifest file. If I don't declare the experimental APIs there I will be able to upload the extension to the gallery but it won't get access to experimental APIs when installed in the browser. In fact, pretty much the only difference between "normal" and "experimental" development builds is that the former declares experimental APIs in the manifest - the code is exactly the same for both and simply checks whether experimental APIs are available.

[stikonas]

I think that this extension is no longer experimental in Chromium 17 (https://code.google.com/p/chromium/issu ... l?id=60101).

[Wladimir Palant]

Yes, and we already support the "stable" webRequest API: forum/viewtopic.php?p=52650#p52650 (both regular and experimental development builds will use it in Chrome 17).

[adam777]

OK, just to make everything clear for myself (and perhaps other that may come).
There are 3 build I can think of at the moment.
- The one on the Web Store.
- The development build from the ABP site.
- The experimental development build from the ABP site.

After this last change, and considering I'm using latest chromium, I suppose until Chrome 17 is out nothing changes with the first one.
But, as for the last two, are those builds essentially the same now? both using WebRequest but only the last needs the Experimental Extension APIs flag?

Thanks, Adam.

[Wladimir Palant]

I would like to update the stable version, we are blocked on a Chrome bug however.

As to the development builds - they are slightly different, even in Chrome 17. The "regular" build is slower and uses more memory because it uses both webRequest API and the old blocking approach. The experimental build disables the old blocking mechanisms. Once Chrome 17 is released the experimental build will become the "regular" one.

[adam777]

Got it, thanks for the quick and clear explanation

[Zlip792]

Hello Palant boss,

There is recent (few snapshot ago) change in WebRequest API, does it gonna improve any performance or any positive effect. Don't mind my noobness that I make such posts to often.
http://commondatastorage.googleapis.com ... ngelog.xml

Implementation of a Matching strategy for URLs in the Declarative WebRequest API. The Declarative WebRequest API needs to be able to match each outgoing URLRequest against a large set of rules. This CL lays the foundation for this. URLRequests can be matched using various criteria (e.g. "hostname ends in foobar.com", or "URL contains 'secret'", or both). In order to match many of these patterns very quickly we want to rely on the Aho-Corasick algorithm. This CL is one step before the A.-C. algorithm: It implements the reduction of URL Pattern matches to that of Substring matches. The SubstringSetMatcher is implemented trivially and will be replaced with a A.-C. implementation in a second

Regards

[Wladimir Palant]

It's related to http://crbug.com/112155. While there is no proper documentation yet, I consider it unlikely that this will help Adblock Plus - declarative blocking will most likely be too inflexible for us, we will continue using the current approach.

PS: Looking at the API definition - "internal: true" probably means that this isn't meant to be exposed to extensions, merely something that will be used by the browser itself. Which would explain the lack of information in the bug.

[alberto]

There is a recent blog post from Chromium that suggests that extensions can make use of the declarative webRequest API. This also links to the declarativeWebRequest API documentation.

A declarative version of the webRequest API lets extensions do network interception without the need for a background page at all.

[Wladimir Palant]

Yes, I was talking to Chrome devs about this as well. Don't know yet whether I can make it work for Adblock Plus however.