If AdblockIE isn't loading, it's probably due to this bug. Follow the instructions posted in the comments section for a (clumsy) workaround.
This should be fixed in the next version. See this thread for more information.
Monday, April 20, 2009
Sunday, April 19, 2009
.NET 3.5 Requirement
Some people have asked about why AdblockIE requires .NET 3.5. The short answer is that I wrote this addin for my own use, on my own machine, and on my machine I already have .NET 3.5.
The more technical answer is that I made some very limited use of .NET 3.5-only technologies--specifically, XML Linq. This comprises a total of maybe thirty lines of code, however, so it should only take someone familar with C# half an hour or so to rewrite for .NET 2.0.
I'll happily take a submitted patch that renders this 2.0 compatible. I don't, however, plan to do this myself. The time I can devote to this project is currently very limited, and I'd rather spend it adding cool new features and making AdblockIE more fast and reliable rather than rewriting the parts that rely on .NET 3.5. That's why it's open source, however--because you can change the source, submit patches, or fork it into a whole new project that does what you want.
The more technical answer is that I made some very limited use of .NET 3.5-only technologies--specifically, XML Linq. This comprises a total of maybe thirty lines of code, however, so it should only take someone familar with C# half an hour or so to rewrite for .NET 2.0.
I'll happily take a submitted patch that renders this 2.0 compatible. I don't, however, plan to do this myself. The time I can devote to this project is currently very limited, and I'd rather spend it adding cool new features and making AdblockIE more fast and reliable rather than rewriting the parts that rely on .NET 3.5. That's why it's open source, however--because you can change the source, submit patches, or fork it into a whole new project that does what you want.
Saturday, April 18, 2009
Hit the damn monkey.
If you don't remember these ads from a few years ago, then my new banner will probably seem surrealist at best.
Just a bit of weekend fun.
Friday, April 17, 2009
A note on performance
In the 1.0 preview, AdblockIE ran most of the filtering asynchronously. That is, the webpage finished downloading, IE fired the "DocumentComplete" event, and AdblockIE spun off an asynchronous delegate to filter the DOM. This meant that, depending on threading considerations, the page could be loaded for a few milliseconds before it got fully filtered.
In 1.1, I did away with this, for the simple reason that my limited perf tests showed no advantage to this approach.
But with Apple, Google, Mozilla, and Microsoft releasing browser benchmarks every other week, you might be wondering what effect AdblockIE has on browser performance. I did a little bit of testing with the PerfTest BHO that's checked into the AdblockIE source tree. Unfortunately, as is often the case with this sort of thing, the results are far from conclusive.
In most cases, AdblockIE seems to add at most a few hundred milliseconds to total page load time. That's within the same order of magnitude as conscious visual perception, so probably not something to be too worried about.
On the other hand, there are pathalogical cases where AdblockIE can significantly slow down a page's load time. The New York Times Article Skimmer prototype is one such case, seemingly due to the weird and complicated JavaScript on the page.
Obviously I'm looking into these cases, and keeping IE fast is a big concern for me. (Unfortunately, the DOM-based filtering approach--which enables the NoScript-style JavaScript blocking--is inherently less efficient than simply blocking downloads at the HTTP layer.) In my very limited tests on the current alpha, I haven't seen any huge perf problems, or anything that indicates that this will be an architectural issue with AdblockIE. But we'll have to see how it scales when the ruleset grows, and see how it holds up on other machines and under other users.
In 1.1, I did away with this, for the simple reason that my limited perf tests showed no advantage to this approach.
But with Apple, Google, Mozilla, and Microsoft releasing browser benchmarks every other week, you might be wondering what effect AdblockIE has on browser performance. I did a little bit of testing with the PerfTest BHO that's checked into the AdblockIE source tree. Unfortunately, as is often the case with this sort of thing, the results are far from conclusive.
In most cases, AdblockIE seems to add at most a few hundred milliseconds to total page load time. That's within the same order of magnitude as conscious visual perception, so probably not something to be too worried about.
On the other hand, there are pathalogical cases where AdblockIE can significantly slow down a page's load time. The New York Times Article Skimmer prototype is one such case, seemingly due to the weird and complicated JavaScript on the page.
Obviously I'm looking into these cases, and keeping IE fast is a big concern for me. (Unfortunately, the DOM-based filtering approach--which enables the NoScript-style JavaScript blocking--is inherently less efficient than simply blocking downloads at the HTTP layer.) In my very limited tests on the current alpha, I haven't seen any huge perf problems, or anything that indicates that this will be an architectural issue with AdblockIE. But we'll have to see how it scales when the ruleset grows, and see how it holds up on other machines and under other users.
1.1 Release Ahead of Schedule
This is embarrassing. I was going to make a release with the new features discussed below this weekend, after more testing. But I just discovered a bug in my installer setup that didn't show itself on my dev machine (a missing dependency that I had on my dev machine because it's my dev machine). While this is alpha software, I feel pretty stupid having pushed out an MSI that didn't actually work, especially since I did at least do nominal dev testing on a second machine.
I've just put up a new build, sooner than expected, with the fix and the new features. I also put up the dev and release builds. The only difference is that the dev build will show asserts and exceptions and logs data (which elements were blocked or not blocked) to %TEMP%\Low\adblock.log. If you're interested in this sort of thing, try the dev build. If not, stick with the release.
(In the future, I'll provide a simpler way for getting those data, but I didn't want to hold this release up any longer due to the MSI bug.)
As always, thanks for your patience while I'm still in the apha stage, and use the Discussions page to let me know about any problems.
I've just put up a new build, sooner than expected, with the fix and the new features. I also put up the dev and release builds. The only difference is that the dev build will show asserts and exceptions and logs data (which elements were blocked or not blocked) to %TEMP%\Low\adblock.log. If you're interested in this sort of thing, try the dev build. If not, stick with the release.
(In the future, I'll provide a simpler way for getting those data, but I didn't want to hold this release up any longer due to the MSI bug.)
As always, thanks for your patience while I'm still in the apha stage, and use the Discussions page to let me know about any problems.
Planning
I wanted to give readers a feel for what I'm currently working on and where some of the more important work items stand. First off, I seem to have a working fix for the unfiltered-on-refresh issue (Work around DocumentComplete not firing on refresh), which basically involves filtering on every DownloadComplete event, and some associated jiggery-pokery.
These fixes also seem to provide a partial resolution to Fails to block Google Pageads on Gmail, though I'm getting inconsistent results with Gmail still. I'm investigating.
I've also significantly reworked the rule syntax, though preserved backwards compatibility, to allow per-site rules and filtering of specific page elements, including <div> tags (Add stylesheet class-based blocking; add per-domain rule specificity). In the process, I've switched from the .NET regex engine to a much simpler handwritten globbing engine (supporting only wildcard and single-character wildcard--i.e. * and ?--a la shell globbing). This is a little limiting, but it should provide sufficient expressiveness for most rules, is a lot closer to what most other ad filters (e.g. Adblock Pro) do, and is roughly 45 times faster than .NET's regex engine. When I have a new alpha ready, I'll be sure to post some sample rules here with an explanation of their function and how to do advanced stuff.
These changes, collectively, provide the core requirements for Implement NoScript-style JavaScript blocking, though to make it usable I really need a toolbar GUI (if script blocking is on by default, you really need an easy way to enable scripts for certain sites, other than hand-editing an XML file).
I have a bit of testing and debugging to do still before I'm ready to put up a new release, as well as some perf testing and some other business (e.g., I'd like to add a keyboard shortcut for "reload unfiltered"). But hopefully I'll have a new alpha build by this weekend or early next week with all the new features.
These fixes also seem to provide a partial resolution to Fails to block Google Pageads on Gmail, though I'm getting inconsistent results with Gmail still. I'm investigating.
I've also significantly reworked the rule syntax, though preserved backwards compatibility, to allow per-site rules and filtering of specific page elements, including <div> tags (Add stylesheet class-based blocking; add per-domain rule specificity). In the process, I've switched from the .NET regex engine to a much simpler handwritten globbing engine (supporting only wildcard and single-character wildcard--i.e. * and ?--a la shell globbing). This is a little limiting, but it should provide sufficient expressiveness for most rules, is a lot closer to what most other ad filters (e.g. Adblock Pro) do, and is roughly 45 times faster than .NET's regex engine. When I have a new alpha ready, I'll be sure to post some sample rules here with an explanation of their function and how to do advanced stuff.
These changes, collectively, provide the core requirements for Implement NoScript-style JavaScript blocking, though to make it usable I really need a toolbar GUI (if script blocking is on by default, you really need an easy way to enable scripts for certain sites, other than hand-editing an XML file).
I have a bit of testing and debugging to do still before I'm ready to put up a new release, as well as some perf testing and some other business (e.g., I'd like to add a keyboard shortcut for "reload unfiltered"). But hopefully I'll have a new alpha build by this weekend or early next week with all the new features.
Subscribe to:
Posts (Atom)