(*** This bug was imported into bugs.kde.org ***) Package: konqueror Version: 1.9.8 (KDE 2.0 >= 20001117) Severity: wishlist Compiler: gcc version 2.95.2 19991024 (release) OS: Linux 2.2.17 i686 (compiled sources) Hi I would like to be able to block content specifically advertising banners from specific domains. And I want to be able to configure it easily from within Konqueror or Kontrolcenter like similar things. Installing and configuring an extra program like Junkbuster or Junkex would be too complicated for most users. The option to accept/decline cookies from specific domains is great! I would want content blocking to be similar. Maybe there could be an extra option in the cookie dialog; "Decline and block all content" which would of course not be available if the domain is the one you wanted to go to but only if it is an external (advertising) domain. Then there could be an item in the right-click menu for images to block content from the domain it was loaded from. But I'm sure you can decide how to implement it nicely!
An even better solution would be to integrate something like Internet Junkbuster into Konqueror. With the regular expression editor this could be really useful.
I concur with the need for ad blocking. Konqueror is _intolerable_ to use compared to browsers which have this feature. For example, on Windows using IE, the Adshield freeware blocker (adshield.org) has proven to be marvelously effective at this task. It uses substring matching to filter URLs. No regular expressions or proxy server setup necessary. To set up a filter, the user simply right-clicks on the offending image, selects the 'Block this ad...' menu item. A messagebox pops up allowing to user to select all or part of the URL to block. After hitting OK the filter is in place. It takes less than a minute to clean up most ad-heavy pages. Don't underestimate this feature request. It markedly improves the browsing experience.
*** Bug 23966 has been marked as a duplicate of this bug. ***
*** Bug 36196 has been marked as a duplicate of this bug. ***
*** Bug 56754 has been marked as a duplicate of this bug. ***
While we are blocking stuff we don't want to see, why not go ahead and block flash ads, along with certain ad images, which would make for crystal clear web pages.
Currently the easiest basic way blocking ads is using a customized "hosts" file blocking complete servers known for storing advertising data (eg. ad.doubleclick.net). Konqueror could offer an RMB entry allowing to add the clicked content's URL to the mentioned hosts file. I think that would be a good start.
Flash-ad blocking should indeed be added as well, as more and more ads are flash-based. Flash ads are also the most annoying, by consuming system resources and download time.
Another important remark: With Mozilla's banner-killer, it happens that you accidentally block ALL pictures from the entire site. This can cause the user to panic, not knowing how to restore the page. When the user chooses to ban a certain image/flash source, the banner-killer should count the total number of images on the current page that will be banned after the URL filter takes effect, so that the user can see it when the filter blocks more images than the user intended. The most beautiful solution would be that the banner-killer provides a mechanism to ban only part of the selected URL and display the amount of banned images every time the user changes the URL filter. This will enable the user to interactively choose the right URL filter without unexpected results.
*** Bug 65524 has been marked as a duplicate of this bug. ***
On the basis that I can use the AdBlock extension (http://adblock.mozdev.org/) to Mozilla Firebird is the principle reason why I now use that rather than Konqueror which I'd love to return to, if only I could get rid of those animated-gif ads! Adblock goes beyond just domains and allows blocking from urls such as http://*/ads/ and so any URL which refers to an 'ads' directory will be blocked.
*** Bug 68342 has been marked as a duplicate of this bug. ***
Hi All, Used to have the same complaint about Konqueror, until I saw a comment on Google about this. Apparently, installing a local proxy server with ad-blocking capability is the way to go. The article mentioned Privoxy (http://www.privoxy.org) as an option. I was able to get the RPM using apt-get and set up Konqueror and Mozilla to use it without any problems. It's been working out great.
I just tried out Privoxy. I think it is too difficult to install and use for the average user. The default settings blocks too much and I had trouble resolving that problem within 5 minutes. Besides that it seemed slow, i.e. I had to wait some extra seconds which IMHO was too long. As others have said before: we need a solution that is integrated into Konqueror and is easy to use (just like Mozilla).
*** Bug 30118 has been marked as a duplicate of this bug. ***
+1 I have the knowhow to install privoxy if I wanted to. But I also have a family, job, church, etc... A right click and "block this server" is as much time as I want to spend on this!
The AdBlock extension mentioned in comment #11 (http://adblock.mozdev.org/) is sorely missed in Konqueror (at least I do miss it). I know about proxy servers, I had Proxomitron configured and running just fine on Windows, but then I left it in favor of AdBlock, because it's so much easier and more elegant to use. On Linux I'd like to use Konqueror (and in fact, I do), but AdBlock keeps pulling me towards FireFox. AdBlock is a killer feature (I find it very weird that it's not included by default in the FireFox distro) and IMO Konqueror should have an equivalent for it, for my part it can be a 1:1 feature copy, including the neat semi-transparent tab allowing blocking of Flash movies.
Another vote for this bug :-) In Mozilla, we just have to check "Block popup windows" (in fact it is checked by default). Theire is no need to explicitly define URLs to block (we can allow some sites) and that's easy and no brain-taker ;-) I don't know how it work : just block popup windows ? it's easy but efficient !! Of course, I would also love flash blocking (perhapse that thing would be more difficult to make it to "just work") because it's ressources consuming and they are unfortunately more spread those days...
To block JavaScript popups in Konqueror, goto Settings->Configure Konqueror->Java & Javascript and click on java script tab. The is an option to set the policy for JavaScript popups. Konquorer still needs mozillaesq url blocking with wildcards like adblock does for mozilla/firefox, IMHO.
I don't believe this bug is legit. What do you actually want ? that Konqueror will as a browser will implement a mechanism that you get as an extension/plugin/3rd party software for other browsers ? If you want that functionality, then simply write a similar extension for konqueror - it does support a fully capable extension mechanism just as mozilla. such an extension would sure be welcomed by many users, and it might even make it into the KDE distribution, but I don't think it should be an integral part of konqueror (ever heard the word bloat?). On general I think that konqueror's developers should not bother themselves with stuff that can and need to be a 3rd party extension. IMO the developers should concern themselves with developing core frameworks (maybe a Mozilla compatible extension framework that can run Mozilla's XPI ?) and not bother with highly specific high-level logic that's only useful to a handful of users. And BTW - privoxy is not hard to install at all. on my system I logged in as root, typed 'urpmi privoxy' and then 'service privoxy start' and configured konqueror to use it as a proxy - all there is to it, nothing actually to configure except konqueror's proxy setup. I suggest to close this bug as WONTFIX
> And BTW - privoxy is not hard to install at all. on my system I logged in as > root, typed 'urpmi privoxy' and then 'service privoxy start' and configured > konqueror to use it as a proxy - all there is to it, nothing actually to > configure except konqueror's proxy setup. Good that privoxy is easy to INSTALL. But it does not really matter for this issue. What really matters is how easy it is to use in Konqueror. For example does it appear in the right-click menu of images like described in this bug report?
Also, it should be easy to bypass. Thankfully in Konqueror I can quickly turn the proxy on or off.
aaronw@net.com wrote: >------- Additional Comments From aaronw net com 2004-05-26 23:43 ------- >Also, it should be easy to bypass. Thankfully in Konqueror I can quickly turn the proxy on or off. > > And this is an example of a good extension. want ad blocking integrated into konqueror ? port Ad block to a KPart::Plugin :-)
------- Additional Comment #20 From Oded Arbel 2004-05-26 21:19 ------- >I don't believe this bug is legit. What do you actually want ? that Konqueror >will as a browser will implement a mechanism that you get as an >extension/plugin/3rd party software for other browsers ? Well, you don't really need any plugins / extensions for this in Mozilla / Firefox. There is the option to rightclick any image and select "Block images from domain.tld". Very simple, very functional. What you are refering to is the AdBlocker extension which is a lot more. Maybe the original bug was a bit vague on what exactly is wanted, but your "this bus is not legit" seems to be a bit harsh ? Isn't the point of bugtracking / feature requests to request things users would like to see in a product?
"What do you actually want ? that Konqueror will as a browser will implement a mechanism that you get as an extension/plugin/3rd party software for other browsers ?" Yes, that's exactly what we want. Just like Konqueror has native support for pop-up blocking (IE still requires a plug-in), we want the same built in functionality to exclude specific domains from loading.
I do block many (>100) sites with squid right now (addware/spyware). It would be good if konqueror/'all kde apps' can block/ignore 'whole sites'/'url regexps' somehow. I can think of a squid compatible list somewhere in /etc for global system protection and/or a URI for this purpose(centralized administration)... Compatability with squid would be great for me (one file with domains and one with regexps, one item per line and comments). However I can't judge to what extent this feature should be implemented. For the home user it's probably enough to have per user/machine settings. For a whole network it could be better to implement this with squid and/or firewall.
Ideal solution would be have a wildcard/regexp-matching system to block not just by domain but by URI. For example "www4.somedomain.com/ads/banner.jpg" could be blocked by "www?.somedomain.com/ads/*".
What about not just blocking images from being loaded but also discarding clicks on them? Otherwise you might click on an blanked area and get somewhere else...
... I think the best solution is going to come in the form of something similar to the way that cookies are handled, ie, hacking something into kio so that all of KDE's HTTP traffic honors its cookies. Similarly, there's going to need to be a database (with Control Panel administration linked into Konq's Preferences, identically to the way that Cookies are handled) that is queried before any HTTP(S) request is made that will query the result in some kind of action (or non-action). The hard part, IMHO, will be in Konq to have the the onMouseOver() signal for links to query the database and to configure the action for the user (ie, no action/don't change the mouse, or still clickable but redirected to an info page about unblocking a URL, etc). Actually, I don't think that'd be too hard to do... I guess the hard part would be getting the performance to not suck with a large number of domains and potentially regexp's. Just a few thoughts from a Qt hacker (who wishes he had time to futz with KDE, but doesn't right now).
> The hard part, IMHO, will be in Konq to have the the onMouseOver() signal for > links to query the database and to configure the action for the user (ie, no > action/don't change the mouse, or still clickable but redirected to an info > page about unblocking a URL, etc). Actually, I don't think that'd be too > hard to do... I guess the hard part would be getting the performance to not > suck with a large number of domains and potentially regexp's. Why not cache it in the image somehow when the document is loaded? Set a property or just change the link.
> Why not cache it in the image somehow when the document is loaded? Set a property or just > change the link. Because this isn't exclusively a konqueror problem. Filtering URLs is something that needs to happen in the io slave so that the data is never fetched to begin with, regardless of what program in KDE is fetching the data (uniform policies are good because consistency is good). Then, in konqueror, you need to have a set of methods that are used to check to see if a URL should be clickable, whether or not the image should be loaded, etc. Good interface design, to me, dictates something like (certainly not limited to these three methods!!!!): bool canClick = KUrlActionDb::isClickable(QString url, QString uri = "/", int port = 80, bool https = false); int urlActionType = KUrlActionDb::getAction(QString url, QString uri = "/", int port = 80, bool https = false); QString newUrl = KUrlActionDb::rewriteUrl(QString url, QString uri = "/", int port = 80, bool https = false); something similar to that (whether isClickable() or getAction() are from some ficticious class like KUrlActionDb or is included in the some other URL class, I have no clue), but, an interface like that seems the most unobtrusive to me. If urlActionType is something like, KUrlActionDb::KONQ_LOAD_BLANK_IMG, then sure, loading an image makes sense, but you don't want to have a blank image that's clickable, by and large. urlActionType may be something like KUrlActionDb::KNOQ_REWRITE_URL and rewriteUrl(QString("ad.doubleclick.com")) may return something like QString("file:///usr/local/share/docs/kde/konqueror/why_we_block_ads.html"). The status bar could be changed, the link's address may be changed, the mouse cursor should probably change if KONQ_LOAD_BLANK_IMG is the returned type, etc. *shrug* My $0.02.
*** Bug 82674 has been marked as a duplicate of this bug. ***
Customize graphically, as QT Designer does for GUI, any page/site : move or remove - DIV - TABLE, TR, TD... - IMG - any kind of text - FRAME
Please consider my suggestion made on Bug #56517. Blocking images with absolute URLs would block almost all ads, too.
A block regex that honors all data types would be pretty cool. In Mozilla, I can block ads all I want, but Java and Flash apps still appear. So, I'd love if someone added a right click context menu entry to "block all files from this domain" (or similar wording) to Konq (or KHTML, which ever generates the context menu).
This function would be great...
I dont know if I am right, but the way I *feel* about AdBlock's behavior is as if the web page itself is rewritten, and the data is never loaded from the web (in contrast of downloading the webpage and not displaying some parts of it). for example, if I block */ads/*, all IMG, FRAME and IFRAME tags are collapsed into nothing, stripped from the html, prior to loading the images themselves. If the blocking behavior is going to be extended beyohnd the web, user might have to write "http://*/ads/*" if they do not want to block thing from everywhere. AND, having another setting to select which protocols will be filtered and which ones will not, to save cpu time.
AdBlock propose two behaviors in recent versions : - blocking (ie not retreiving the data, quicker for low bandwith links) - hiding (so the page layout is ok) I think both are interesting.
*** Bug 30392 has been marked as a duplicate of this bug. ***
Many people want this feature, and it also holds many people off using Konqueror as their default browser. Mozilla's adblock extension blocks images, iframes, flash applets, javascripts, and sites (so that links to e.g. doubleclick are not followed). It allows blocking (not loading) and hiding (loading but not showing) of content, and has collapsing (clearing the page space so that the space where ads were to be shown is freed for e.g. text) available as a seperate option. I think hiding is a bit useless (why load content that is not shown?), and that collapsing is great, especially for inline ads and ads that are at the top of a page.
(in reply to Mark Janssen) >why load content that is not shown? ... hum, ... to not make the 'sites' aware 'we' are ad-blocking their ads? Let's think about it; if everyone started ad-blocking (not loading their 'stuff' from the server) it'd be a dead give away what's going on. ... which will lead to them having to 're think' of how promote advertisement .... which could lead to other more intrusive methods .... etc etc. BTW, I'd also ad a "load ad & in the background - randomly make it as if though the user *clicked the ad* & followed the ad to the pointing url ... etc". Sure, I'd (and we all) would consume our broadbands for all that unnecessary downloading (not that we'd look at it) ... but if it'd make it that much harder for them to notice/find out that 'we' are blocking their ads ... the better I say (not that it make much difference to me, personally, as I have broadband....).
Thats true. If it'd support hiding (so do load) and collapsing it'd be even better.
danalien wrote: >>why load content that is not shown? >> >> >... hum, ... to not make the 'sites' aware 'we' are ad-blocking their ads? > > >BTW, I'd also ad a "load ad & in the background - randomly make it as if though the user *clicked the ad* & followed the ad to the pointing url ... etc". > >Sure, I'd (and we all) would consume our broadbands for all that unnecessary downloading (not that we'd look at it) ... but if it'd make it that much harder for them to notice/find out that 'we' are blocking their ads ... the better I say (not that it make much difference to me, personally, as I have broadband....). > > And you'd also be helping the site owners to make a buck - which is a "Good Thing"(tm). Site owners usually get money from the advertisment companies per click, so by faking clicks on ads you'd be helping the people who make the sites you watch earn more money and keep those sites up.
It'd be difficult to 'click' google ads (javacript) etc. though.
Plus, if you click through the ad, and even if you only load the image, it gives spammers a really simple way to verify your email address. It would be better if Thunderbird had an option to block all images (like it can already, right?), and then gradually permit images from different sites as necessary.
We're talking about (1) Konqueror and not KMail and (2) about KDE and not Mozilla.
Some dialup users, such as myself, block content specifically to preserve bandwidth. I don't mind actually seeing them.
At the moment I have blocked internet access to doubleclick, and when Konqueror tries to load a page with an image/script from doubleclick it takes ages, until it times out.
Firefox' adblock extension is really the greatest thing ever. The ability to collapse iframes and block using wildcards like www.site.com/ads/* really can give new life to messed up web pages. When that is said, I don't think it should be included in Konqueror itself, but rather in the form of a plugin. But is a plugin that changes the parsing of the html possible? Where to start looking?
If this is included, a whitelist should really be one of the features.
This feature is basically blacklists. Why would you need a whitelist? Just don't add that domain to the blacklist.
No I mean whitelisting a certain site from having the ads blocked - e.g. you might want to whitelist your own site to check if ads are still working.
to Trejakz Xaoza; what I think 'Mark Janssen' meant about 'whitelist' was that if you're blocking for eg. "ad*.doubleclick.net/ad/*" by default for all sites ... but you'd wanted '${SITE.A}' to load the ads, you could add '${SITE.A}' to your 'whitelist' :-)
Hmm. I dunno, this seems like a bit of an edge case. Even if I were forced to put DoubleClick's ads on my own site, I still wouldn't want them in my face while I'm trying to use the said site. :-) However, an option to temporarily disable the AdBlock for this sort of "development" purpose does sound useful for site developers plagued by advertising. :-)
If we could: * have this whitelist * have the blacklist block *everything* by adding the '*' wildcard * lockdown both blacklist and whitelist via KIOSK Then we would have the perfect tools to make Konqueror a child-safe browser.
I agree with Dik Takken, except ad blocking should be off by default. Then users can blacklist and whitelist all they want afterwards. Btw, the white/blacklists need to work on either websites that have ads *and* ad servers themselves. (IE, I want to be able to block google ads, but whitelist my-google-ad-using-website.com) Someone mentioned this before, but being able to block any ad media format (gif, png, jpg, swf, java, etc) is also a plus. Ultimately, shouldn't we just clone Mozilla's Adblock extension? It seems to do everything people want.
FYI, I've just implemented a KDE-wide domain blacklisting feature. There's no GUI for it, though. At least, not yet.
For two years I've been a user of Konqueror but for the last one I've been using Firefox. The only reason is AddBlock (well, and it's blocking of scripts using 100% CPU for too much time, which saves a lot of hangs in the browser). I prefer _all_ other Konqueror features (speed, render, pretty, features) but AddBlock is just too much damn useful.
It's strange nobody mentions adzapper. It works for me, puts an image ("this ad zapped") and let's me click on it, but I know it's an ad. And configuring adzapper+squid it's really easy (I don't even remember if I had to configure it)
I still prefer something like AdBlock over a blocking proxy.
Something I find better on a proxy approach is that you don't have to block ads on each browser you use. Think about more than 1 person using the same computer, or being behind the same firewall/proxy. This approach blocks ALL ads on ALL browsers on ALL computers of ALL users. If you have to configure Konqueror, Mozilla, Firefox, Opera, Links2 (graphic mode) and (why not?) Internet Explorer, Safari, Crystal Atari Browser, Voyager (Amiga), ... you have to open each and put the blocker. I think it's easyer to use a proxy and share for the same price the downloaded files between every user and browser. Wasn't "the Unix way" to make little programs that do their work and chain them to make something bigger? OR ARE WE GONNA SEE LINUX BECOME WINDOWS' HEIR???
It's true - but the proxy method cannot do element collapsing, javascript blocking, or support rightclicking an element and selecting "block this".
And as a personal user, do we need the overkill to run a proxy on our workstation? Mark Janssen wrote: >------- You are receiving this mail because: ------- >You are a voter for the bug, or are watching someone who is. > >http://bugs.kde.org/show_bug.cgi?id=15848 > > > > >------- Additional Comments From praseodym+kdebugzilla gmail com 2005-02-08 18:06 ------- >It's true - but the proxy method cannot do element collapsing, javascript blocking, or support rightclicking an element and selecting "block this". > >
On Tuesday 08 February 2005 18:01, Miguel Angel Lopez wrote: > Something I find better on a proxy approach is that you don't have to block > ads on each browser you use. Think about more than 1 person using the same > computer, or being behind the same firewall/proxy. This approach blocks ALL > ads on ALL browsers on ALL computers of ALL users. Yes, but that's exactly what I *don't* want. I like to have my own blocking preferences, other user their own etc. and with proxy that's rather hard to do. The KISS approach for this IMO would be to create kio_adblock or something.
How is it overkill to run a proxy? As for the unix way, although a proxy server is certainly the most elegant solution, there is some to the point that a proxy server alone cannot do all the things people would expect from an ad-blocker. Therefore I think a good solution would be to have a proxy server and a browser plugin communicating with it and implementing GUI-specific features (like rightclicking->``block this''). That way we could have the best of two worlds. And other browsers could still use limited features of the proxy alone. I don't think it's advisable to reinvent the wheel, as in writing a whole new proxy server (and god forbid in kded). We just need a GUI plugin and some glue code to an existing one.
Is there anyone working on this? A wish with more than 2000 votes and open longer than 4 years must be fixed...
"must be fixed" By who? someone has to enjoy working on it, or want to do it, that's how the Free Software World works... If you or the other voters (me too, btw) don't step up themselves, then, if the dev's don't want to do it, it won't happen. Maybe you could offer money for this, if your really want it... quite a few people have voted, if some are willing to pay for it, it might get done. Or ask someone to start coding... the developers don't want to do it, but hey, this is free software. anyone can do it.
Except ones that cannot code themselves...
then do a trade. ask if a developer has something he wants to get done, and can be done by someone who can't write code. like documetation. you do the doc, he does the coding here. maybe there is a developer 'out there' who is willing to do this... or start collecting money, so you can pay someone to do it. I can't code, but I can ask people that can, to do it. They are free to refuse, well, and if I really want it to get done, I don't think its strange to try to give something back...
A proxy in general might not be overkill, but Squid certainly is. Also, I don't see why a proxy can't do element collapsing and JavaScript blocking. First of all, unless the proxy doesn't see the data (e.g. due to it going over SSL), it obviously _can_ remove the elements. Second of all, why can't a proxy return an empty JavaScript, like AdZap does?
There are some light-weight proxy servers with nice filtering functionality, e.g. middle-man. But when I tried to use them I found it a pain to configure them if something was overdone by the default settings. You have to switch between the browser and config file, study the strange syntax, and refresh from time to time.
IMHO a proxy is useful for admins, saves a lot of work. A single user may find a proxy more work than adblock. Still one can use adblock behind a proxy to improve the filtering. I've been using privoxy/junkbuster for quite a long time, but adblock definitely makes more sense and is much easier to configure, although privoxy has a (complicated!) web interface. Adblock kills anything that annoys you, privoxy sometimes kills sensible images. :-( About the-unix-way: Then why can KMail do POP3 when we have fetchmail? Seems like integration is not generally a bad thing. And adblock is an optional plugin.
Now that Mozilla is abandoning, uh, the Mozilla suite, we need to get this feature implemented to be attractive to all the people that have said that the only thing that keeps them in Mozilla is the ability to block ads (I'm one of those people too, by the way; the only reason I still use Mozilla is Konqueror's lack of that feature, and there's no way I'm switching to Konqueror until the feature is there, but I'll be switching the day it is). What do we need to do to get this done? It's been requested for over four years to no avail and is now the second most desired feature in all of KDE, which is kind of ridiculous, but now we also have a golden chance to capitalize on the feature. I can program in C++, but know 0 about the programming behind KDE and Konqueror; if anyone finds that I can be useful, keeping in mind that I'm a full-time college student without oogles of spare time, I'm more than willing to help myself. Do we need to pass the collection plate around or something? Come on guys, let's bite the bullet and get this one done.
Created attachment 10810 [details] Konqueror filter addition I've produced an initial attempt at a very simple konqueror adblock style url filter, I posted to kfm-devel@kde.org but I've just found this bug. I'd appreciate comments/suggestions. Thanks,
Created attachment 10824 [details] Settings dialog Screenshot of configure dialog.
Ivor Hewitt: well, well, I've let it compile (against the snapshots of '-050427-'th) during the night ... and what do you know, it did so without any (complie) error. (going to attach pics - instead of typing) 1st impression - 2005.04.28.-.00.png before 1st test - 2005.04.28.-.01.before.png ... 2005.04.28.-.01.after.0.apply.and.reload.png ... 2005.04.28.-.01.after.1.apply,.reload..and.restart.png and 2005.04.28.-.01.after.2.removal.of.1st.swf.and.apply,.reload..and.restart.png learnt: * there's finally an attempt of a '(ad) blocking feature' :) * that it needs _some_ polishing ... like: - 'block this image'-link in the '(right-click) alt-menu', - to block flash too not just images (and add a way to easily block them, ... as if you right-click on an flash, you won't see the STD 'alt menu'...) - not having to restart konqueror ... and it would also be nice if one wouldn't have to reload the page too ... just block ${daF00k3r} and it does it on the fly. - fancy wildchars? ... eg. not just http://*ad*.osdn.org/*, but something in the general directon of: http://*ad*.osdn.org/*.{png,gif,jpg,swf} ... too :) - ... yeah, some shortcuts to the 'filter'-dialog would be very nice too :-) .... - and a zillion other feature I can't think of *right* now :) * ... and that Ivor is ${daMan} =) /* I mean, this has been in the bug-tracker for soon 5 years ... nice that someone finally took this upon himself :-) */
Created attachment 10825 [details] 2005.04.28.-.00.png
Created attachment 10826 [details] 2005.04.28.-.01.before.png
Created attachment 10827 [details] 2005.04.28.-.01.after.0.apply.and.reload.png
Created attachment 10828 [details] 2005.04.28.-.01.after.1.apply,.reload..and.restart.png
Created attachment 10829 [details] 2005.04.28.-.01.after.2.removal.of.1st.swf.and.apply,.reload..and.restart.png
Comment on attachment 10828 [details] 2005.04.28.-.01.after.1.apply,.reload..and.restart.png sorry, for some reason save the wrong 'dump'
Created attachment 10830 [details] 2005.04.28.-.01.after.1.apply,.reload..and.restart.png
Created attachment 10831 [details] 2005.04.28.-.01.after.2.removal.of.1st.swf.and.apply,.reload..and.restart.png
Comment on attachment 10828 [details] 2005.04.28.-.01.after.1.apply,.reload..and.restart.png sorry, for some reason saved the wrong 'dump' ... and upped it before I noticed :-/ but see, http://bugs.kde.org/attachment.cgi?id=10830&action=view for the proper one!
Comment on attachment 10829 [details] 2005.04.28.-.01.after.2.removal.of.1st.swf.and.apply,.reload..and.restart.png sorry, for some reason saved the wrong 'dump' ... and upped it before I noticed :-/ but see, http://bugs.kde.org/attachment.cgi?id=10831&action=view for the proper one!
Hi, I see from your settings dialog you have the old patch :). There's a more recent patch posted to the kfm-devel@kde.org mailing list, which is why I've obsoleted the patch here. More complex regexes wouldn't be hard, but I'd like to keep the interface reallly simple for now, and add complex options later on. I agree the restart issue is a problem, but this is my first KDE coding and I haven't worked out how to do that yet! Current Todo list: 0. Remove picture placeholders for chopped images. 1. Add import/export list option. 2. Some way to show all filterable links on the current page. 3. Some way to right click items to add filters. It would be easier to discuss changes suggest features either on the kde mailing list or mailing me directly.
Ivor: v2 - aah, didn't know. but good to know :) /* anyone else, here's a direct link: http://lists.kde.org/?l=kfm-devel&m=111463785409056&q=p3 also, if one wants to follow the conversation, without subscribing: http://lists.kde.org/?l=kfm-devel&w=2&r=1&s=Konqueror+adblock&q=b */
Created attachment 10861 [details] Current adblock patch (v4) This is the latest version of the patch. Changes:- Incorporated David Faure's cleanups. There's now an option to enable/disable the filter. Option of replacing ads with "ghostbuster" icon, or stripping out completely. Right click context menu on images allows block by image or by host. Moved the options in with other konqhtml files. General tidying and stupid bugs fixed. :)
Glad to see that konqi's going to be more and more powerful ! Keep up the good work and thank you :)
Created attachment 10870 [details] Current adblock patch (v5) Latest AdBlocK patch. Minor cleanup, some label renaming and changed image strip method. (removes from dom tree rather than hiding layout)
> changed image strip method. (removes from dom tree rather than hiding layout) Both methods should be available as options, see comment #38 and #40.
from #40 > It allows blocking (not loading) and > hiding (loading but not showing) of content > and has collapsing (clearing the page space This supports 1. Blocking the image and not loading it, but replacing it with a placeholder and 3. Blocking and collapsing the space. I really don't see the point of 2.
> I really don't see the point of 2. Some people do. See comment #41.
SVN commit 409996 by ivor: First commit of khtml AdBlocK feature. BUG:15848 M +12 -0 trunk/KDE/kdelibs/khtml/ChangeLog M +10 -0 trunk/KDE/kdelibs/khtml/html/htmlparser.cpp M +26 -0 trunk/KDE/kdelibs/khtml/khtml_ext.cpp M +3 -0 trunk/KDE/kdelibs/khtml/khtml_ext.h M +2 -0 trunk/KDE/kdelibs/khtml/khtml_popupmenu.rc M +73 -1 trunk/KDE/kdelibs/khtml/khtml_settings.cc M +7 -0 trunk/KDE/kdelibs/khtml/khtml_settings.h A trunk/KDE/kdelibs/khtml/misc/blocked_icon.cpp [License: no copyright] AM trunk/KDE/kdelibs/khtml/misc/blocked_icon.png M +25 -2 trunk/KDE/kdelibs/khtml/misc/loader.cpp M +4 -0 trunk/KDE/kdelibs/khtml/misc/loader.h M +3 -0 trunk/KDE/kdelibs/khtml/xml/dom_docimpl.cpp
Will this patch be featured in 3.4.1?
I don't think so. I thought the general protocol was that new features go into the next release, and only bug fixes get backported to point revisions.
Hrm, but isn't allowing ads in the first place a bug? ;)
Nah, ads are a bug in the web site they're on.
Just a question: Is the filterformat the same that Adblock-Firefox has? Would be great, because for then it would be possible to use the prebuild filters offered for Adblock-Firefox and may be even to synchronise them, if both browsers are used on the system.
I don't think it's in the same format. Firefox appears to store all the patterns in prefs.js as one long list of strings. It would be nice if there were a way to import and export the filter strings between KDE and Firefox.
The Firefox Adblock extension has an export function which exports to newline-seperated files. It also supports importing them. I'm unsure if this KDE feature uses the same filter-format as Firefox's extension, though.
The current version of AdBlocK will support simple (wildcard style) filter sets exported from Firefox AdBlock. I'm making the changes at the moment to make it support Filterset.G.
That sounds great. Would be good if the filter-formats stay compatible to each other. A question: Is it possible to test your Adblock without compiling a whole KDE from SVN? Some suggestions: * How about making it possible to up/download filtersets from http://www.kstuff.org/hotstuff/ ? * It would be great if the filtering could be disabled or limited at certain sites which reject working with that feature on or at least a possible to fast (de-)activate the feature (something which I miss in Firefox)
Message in Firefox-Adblock-Forum: http://aasted.org/adblock/viewtopic.php?t=1992&sid=2c331da0413ba99cc965da7031a60ebe I don't have an account over there, but if someone would care to pass the message along: If the filter formats are incompatible and the developers wish to automate the conversion of Filterset.G and host a usuable version, they should let me know. I licensed the maker of Epiphany's AdBlock extension to redistribute Filterset.G in his format, and I'd be happy to do the same for AdBlocK, if necessary. I can be contacted by emailing pierceive [at] yahoo.
What is Filterset.G ? A list of blockable items to import into firefox's adblock extension ? Why does it need a licence if so ?
>Why does it need a licence if so ? Because, of the fancy name, 'Filterset.G' ... *d'ooh* =) J/k. no, but, I don't know either why a file that stores "raw wildchar-urls" even qualifies as something that needs a 'license' ... /* yeah, I think licensing-stuff has sometimes gotten out of proportion, when everyone sticks a 'license' on everything thinkable... */
*hum*, just checked. But in the adblock patters are stored in: ~/.mozilla/firefox/default.gb3/prefs.js user_pref("adblock.patterns", "ads.osdn.com/?ad_id* http://www.dtf-travel.com/images/web/*.gif [...] "); /* about 'default.gb3' - if the user got multiple profiles, one needs to check ~/.mozilla/firefox/profiles.ini to choose a different profile... */ ...so does one *realllllyy* have to license anything? ... to read ones own profile-settings and apply the same settings in konqi? PS. If we are going to read the adblock from firefox's prefs.js - might I suggest we don't merge those 'filters' with konqi's 'filters', but create a separate 'filter group' dubbed eg. 'firefox adblock filters'? (and yeah, keep them in-sync ... and maybe use 'famd' while konqi is running, so that if the user make a change in firefox, they get updated on the fly in konqi aswell ...). And yeah, the 'firefox adblock filters' group can be turned on/off too :)
You can export the set of filters from Firefox adblock as a text file. This is the format that the Filterset.G is distributed in. The latest version of Konqueror AdBlocK 'should' work just fine with these expressions, just use the import option in AdBlocK.
Ivor, about the export ... yeah, that's true, all in all. but I was thinking of not having to do no more exporting/importing between the browsers ... just read firefox's prefs.js, 'lift' the adblock settings, and keep an eye open & sync when it has changed :-)