Closed
Bug 656584
Opened 13 years ago
Closed 13 years ago
BlockSite for Camino
Categories
(Camino Graveyard :: Annoyance Blocking, enhancement)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 314046
People
(Reporter: contact, Unassigned)
References
()
Details
Attachments
(2 files)
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en; rv:1.9.2.18pre) Gecko/20110511 Camino/2.1a2pre (like Firefox/3.6.18pre) Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en; rv:1.9.2.18pre) Gecko/20110511 Camino/2.1a2pre (like Firefox/3.6.18pre) Camino's adblock is great but it lacks the ability to block whole domains (very useful for ads inside Flash players). Wouldn't it be possible to use some kind of JavaScript-based solution like BlockSite ? Reproducible: Always
Reporter | ||
Comment 1•13 years ago
|
||
Comment 2•13 years ago
|
||
Isn't this ultimately just a dupe of bug 314046?
I think I looked at this at one point and thought that if you gave the file the appropriate JS XPCOM registration goop, you could load it as a JS XPCOM component via the profile's components folder.
This is Pierre's script stuffed into the guts of the Do Not Track JS component. Requests to strasweb.com/* and strasweb.fr/img/* silently fail when this is installed in the profile's components folder. Since users can do this on their own via a trivial JS component, I don't think there's reason for us to do this in Camino. It might be nice for someone to write a prefPane that allows users to turn on and off the component and modify the URL list, but not in scope here.
Attachment #531887 -
Attachment mime type: application/octet-stream → application/x-javascript
I think Chris is right; the underlying issue is essentially bug 314046, so rather than WONTFIX this outright, let's dupe it to 314046, because long-term, we would like some better ad-blocking solution.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•