Closed Bug 155315 Opened 22 years ago Closed 22 years ago

Implement image blocking

Categories

(Camino Graveyard :: Preferences, enhancement)

Product:
Camino Graveyard
Component:
Preferences
Platform:
PowerPC
macOS
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: neilio, Assigned: sfraser_bugs)

References

Details

(Whiteboard: [good thirdparty])

Attachments

(3 files, 3 obsolete files)

Tarball of new files for Images PrefPane
9.33 KB, application/x-gzip
Details
Patch to chimera.pbproj, MVPreferencePaneGroups.plist, MVPreferencePaneDefaults.plist
10.51 KB, patch
Details | Diff | Splinter Review
pref panel icon from Ugo
22.46 KB, image/tiff
Details 
Just wanted to know if image blocking is planned any time soon for Navigator -
this is one of the few reasons why I use Mozilla as my primary browser instead
of Navigator... thanks!
Summary: Image blocking coming any time soon? → Implement image blocking
Severity: normal → enhancement
FYI, you can do image blocking, even sent made by java, via OS X:
http://www.macwrite.com/criticalmass/mac-os-x-hosts-revisited.php
Summary: Implement image blocking → [RFE] Implement image blocking
*** Bug 162240 has been marked as a duplicate of this bug. ***
We could just say image blocking is the province of proxies (personal and
otherwise) or hosts mapping and WONTFIX this.
Well, Mozilla supports image blocking - why not Navigator?
Navigator is intended to be far, far, far, far, far less complex than Mozilla.
Good point. It'd be great to have this, but I do understand that this is really
just an enhancement.
I've got a patch for this... it involved the implementation of a new class, and
some small modifications to BrowserWindowController and the BrowserWindow.nib.
Header to a class that can block images/cookies.
This is the actual implementation of the cookie/image blocking class. It
basically abstracts nsIPermissionManager so that you don't have know about how
that class works. Everything is done by three private methods. The public
methods (described in the header) just route the calls to those private ones.
It should be simple to use. Also, the use of the two NSMutableArrays is so that
it'll be simple to put this into an NSTableView or whatnot. 

If someone would review the XPCOM stuff I used, that'd be good. I'm not
experienced with it at all, so it would probably be good if someone
double-checked that there are no leaks involved.
These are just the changes to BrowserWindowController. The big changes were
support for image blocking via contextual menu (a la Mozilla), and menu item
validation related to that.
Finally to finish of this patch, a few changes have to be done to the
Chimera.pbroj and BrowserWindow.nib. I can't make these changes 'cause I'm using
beta devtools whose files probably won't open in older versions.

Changes to Project Builder File:
The build settings for the Navigator and NavigatorStatic targets has to be
changed. They need the following additional search path for headers: 
"../dist/include/cookie"

Changes to BrowserWindow.nib:
An additional menu item needs to be added to the ImageLinkCMenu and the
ImageCMenu. The item is the same for both menus, and should have the title
"Block Images from this Server." BrowserWindowController should also have an
additional action called toggleImagePermissions: to which the aforementioned
menu item is connected.


I apologize for not being able to do this... I just don't think the files would
work on the CVS.

Note that for right now, the only UI is a contextual menu item for image
blocking/unblocking. There is no list of blocked servers visible to the user,
but it should be simple enough to implement. I suggest a pref pane with an
NSTableView and two buttons: Add Server and Remove Server. This makes it both
simple to understand/use and functional.

The CHPermissionManager class can also handle cookie blocking/unblocking at the
API level. I haven't made a UI for it yet though. I suggest a UI almost
identical to the image blocking prefpane above. Code-wise, they'll both be very
similar too.


cc: pinkerton to get his input on these patches.
simon, what d'you think? (reassign as needed.)
Assignee: saari → sfraser
Component: General → Preferences
QA Contact: winnie → sairuh
Do we want to forgo custom cookie/image blocking and just implement a CAPS UI à
la bug 38966?
Simon told me on IRC before I submitted my code that it might not even make it
into the tree because it might be "too advanced a feature." If that's the case
(which Simon can surely elaborate on if necessary), a site policy system would
seem to be an even more of advanced feature that probably wouldn't be used as
much by our user base (the general Mac public) due to its complexity.

Basically, all they have to do with this patch is right-click on an image and
choose "Block Images from Server." With the proposed addition/removal UI
(comment 11), it's about as simple as you can get. I'm not sure that stuff for
more complex site policies could be as simple.

Of course, I'm probably defending this 'cause I wrote the patch. More objective
opinions are probably better... ;-)
The reason I mention it is because the back-end functionality appears to already
be in Chimera, but without a UI. I for some reason, was under the mistaken
impression that Chimera didn't have CAPS, but it seems to. I tested some JS
blocking and it worked.

Certainly the server-oriented blocking you mentioned could probably store its'
rules as CAPS policies, rather than reinventing the wheel. As for the UI, some
of the proposal mockups look like they could possibly be simple enough for Chimera.

Anyway, just discussion fodder.
I don't get it - if Prachi has a patch that does this, and it won't be major
work to implement (and from my untrained eye it looks like that's the case
[correct me if I'm wrong]), why not? Chimera may be meant to be much less
complex than Mozilla, but IMHO image blocking isn't a major feature... more like
a really, really nice perk.
Greg, do you know if you can you block images and cookies with CAPS? I've been
looking at some docs and code, and I'm really just seeing stuff about
JavaScript. Is there an existing tag for image/cookie blocking, or are you
suggesting that we create our own tag (like loadImages or something).

I'm completely fine with rewriting the patch to block via CAPS, but I kind of
don't see the point. Mozilla already has API that blocks images/cookies through
use of cookperm.txt in the profile directory. I call that API through the
CHPermissionManager class so that no one has to actually learn the Moz API and
so that its easier to set up an NSTableView data source. 

The only reason I would really consider changing to CAPS a better option is if
Navigator has full support for CAPS with a UI, which I doubt will happen.

smfr? pink? Any suggestions?
Actually, I guess it has nothing to do with image blocking. Duh. I thought Moz
used it to block cookies, but you're right; it doesn't.

I thought it might've used something like:
 user_pref("capability.policy.policynames", "noCookies");
 user_pref("capability.policy.noCookies.sites", "http://www.evil.org");
 user_pref("capability.policy.noCookies.document.cookie", "noAccess");
which I presumed would block cookie activity requested by www.evil.org.

Never mind. Sorry for the wild goose chase. We now return you to someone who
knows what the hell they're talking about.
I don't know if CAPS is a better solution for image blocking. Ccing some folks
who might know.
I think image blocking is a very important feature for a modern browser -- it is
currently the biggest issue holding me back from making this my full-time browser.

Like others I've discovered Chimera does to an extent respect the cookperm.txt
file and block images... but it is unreliable, and there is no GUI. It seems
this is a quite reasonable quest, especially since it already seems to "work."

Now, what would be ultimate would the ability to use wild cards. Comparable
bug/feature requests in Mozilla ask for regular expressions. I don't think this
is necessary. I think a plain-old, single-direction, pattern with wild cards is
enough. Like the astrix in filenames:

block:
ads.*
*/ads/*
*/banners/*

where all characters are exactly what they appear to be, with the exception of *
which is a wild card. Much easier for the user than regular expressions, and
possibly faster to implement, since you don't need the ability to search
bidirectionally, as some regexps require.
Summary: [RFE] Implement image blocking → Implement image blocking
This tarball contains the new files required for the pref pane I created.
Basically, you have two directories: Images and Shared. Just copy the Images
directory into mozilla/chimera/PreferencePanes/. For the Shared folder, copy
*the files inside* the Shared folder into
mozilla/chimera/PreferencePanes/Shared/.

The files inside Images basically make the PrefPane work. They rely on the
files inside the Shared folder, which are the interface and implementation
files for CHPermissionManager, a class that uses nsIPermissionManager to block
cookies and images. The reason this class is in the Shared folder is because if
someone wants to implement a Cookie prefpane with Cookie blocking, they can use
the class here.

Next up: patch to the Project Builder project and list of default PrefPanes
Attachment #96029 - Attachment is obsolete: true
Attachment #96032 - Attachment is obsolete: true
Attachment #96034 - Attachment is obsolete: true
This are my diffs to the chimera.pbproj, MVPreferencePangeGroups.plist and
MVPreferencePaneDefaults.plist. 

That rounds out the submission. Reviews are welcome. Barring any major
problems, this should make this bug resolved except for one detail: The icon
for the pref pane is ripped out of iPhoto. We'll need a legit image. 

Pink and Simon: can one of you get in touch with the person who has made the
other icons, and see what they can come up with? I tried one on my own, but it
sucked.
I hate to disappoint, but I'm not sure we want this level of complexity in the
default chimera download at this stage. We are considering some kind of add-on
facility, which would allow people to download and install extra pref panes.

To this end, I suggest that you upload a built version of the pref pane
somewhere, so that we can download and look at it.
This is pretty simple, so I'd appreciate it if you took a look at it anyway. The
way I've made the prefpane, it's not very complex at all, and I think a lot of
people would like it. 

Still, I'm going to be posting directions to download a pre-built version to the
mailing list in a few minutes.

Again, please take a look at it. Unlike Mozilla's image blocking UI, this is
pretty straight-forward. 
Sorry for the spam. For those of you not on the mailing list, this is the post I
just made:

Hey everyone. I've created an Images preference pane for Chimera that 
allows you to block images. It's currently been submitted for bug 155315 
<http://bugzilla.mozilla.org/show_bug.cgi?id=155315>. The important thing 
is that I'd like some of you to test it, so I've posted it to my 
website, and you all can apply the prefpane to your current build of 
Chimera.

Here's what you need to do if you're interested:

Download the file from here: http://comp.uark.edu/~pgauria/ImagesPrefPane.tar.gz
Extract the files from that archive using StuffIt Expander or your 
favorite utility. The archive contains one folder called 
"Images.prefPane".

Make sure Chimera isn't running. Go to the Finder and ctrl-click on 
Navigator.app. Choose "Show Package Contents" from the contextual menu. 
This will bring up a window with the folder Contents in it. Navigate to 
Contents/PreferencePanes/ and copy Images.prefPane in there.

Then, go to Contents/Resources/ and find the file named 
MVPreferencePaneDefaults.plist. Open this file with TextEdit (or your 
favorite text editor), and add the following line between 
"org.mozilla.chimera.preference.appearance," and 
"org.mozilla.chimera.preference.privacy,"
 
 "org.mozilla.chimera.preference.images,"

(without quotes, of course). So when you're done, 
MVPreferencePaneDefaults.plist should look like this:

( org.mozilla.chimera.preference.navigation,
  org.mozilla.chimera.preference.appearance,
  org.mozilla.chimera.preference.images,
  org.mozilla.chimera.preference.privacy,
  org.mozilla.chimera.preference.security,
  org.mozilla.chimera.preference.webfeatures
)

Save the file and close it. Now open the file 
Contents/Resources/MVPreferencePaneGroups.plist. Add the following line 
between "org.mozilla.chimera.preference.appearance," and 
"org.mozilla.chimera.preference.webfeatures"

"org.mozilla.chimera.preference.images,"

(again, without quotes). So when you're done, 
MVPreferencePaneGroups.plist should look like this:

(
   {
      identifier = general; 
      panes = (
            org.mozilla.chimera.preference.navigation,
            org.mozilla.chimera.preference.appearance,
            org.mozilla.chimera.preference.images,
            org.mozilla.chimera.preference.webfeatures
      ); 
   },
  {
    identifier = security;
    panes = (
            org.mozilla.chimera.preference.privacy,
            org.mozilla.chimera.preference.security,
    );
  }
)

Save the file and close it. Now you're done. Start up Navigator and you 
should now see the Images pref pane in your Preferences window. Test it. 
If you like it, email me. If you hate it, email me. I'd like to gauge 
interest in this feature so that I can gather some data as to whether 
the UI (or the feature itself) is too complex for the normal Chimera 
installation.

Also, if you find a bug or have trouble installing it, email me. 

Prachi Gauriar
pgauria@uark.edu
This works as advertised, and it was easy (at least for me) to install. Thanks,
Prachi!
As several people found out on the list, this doesn't work for Chimera 0.5 (due
to changes in the pref pane base classese, I think). Anyway, gotta have a recent
nightly, but I'm assuming that all of you that are testing this already do.
a pref panel icon from Ugo, as requested. Not bad.
Comment on attachment 103335 [details]
pref panel icon from Ugo

Correcting MIME type.
Attachment #103335 - Attachment mime type: application/octet-stream → image/tiff
please please please
Pretty please...
Please refrain from adding evangelical "please" or "me too" comments. If you
want this, code it yourself, or vote for it.
Greg, it's coded... :-) 

I think it does require some changes to make it more robust. My Powerbook is
currently off being fixed (but I should get it soon). When I do, I'll submit the
necessary changes.

But yes, plese, don't post "pleases" here... The Chimera mailing list is a good
place for those. 
I just downloaded the 2002120804 build of Chimera and cannot gain access to the
contents folder to add the image blocking capabilities.
*** Bug 182932 has been marked as a duplicate of this bug. ***
*** Bug 187452 has been marked as a duplicate of this bug. ***
I'd like to mention that I currently use userContent.css to do this. I suppose
it would be convenient, though, to have a nice, lickable way to do a smiliar thing.

With userContent.css I get reg-ex matching too. Does this implementation provide
that? Or is it just basic "block every image from this server", regardless of
the URL?
It's pretty clear that this isn't going to go in the final build. Instead,
according to pink, a custom prefPane mechanism will be added to Chimera so that
a third-party (like me) can develop and distribute this. 

I've filed an RFE for adding a custom prefPane mechanism (bug 193900).

Resolving this as WONTFIX.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
I like the general idea of blocking advertising images. The problems I see are
twofold.

a) Sites make their money from ads. I think everyone agrees that popups are the
spawn of satan, but inline ads while irritating are (IMHO) not actually offensive.

b) This implementation requires user configuration. Chimera generally takes the
"no configuration required or desired" attitude that is pretty much the Mac OS
X/Cocoa ideal. The popup blocker requires no configuration, it "just works". Is
there a way to implement an ad blocker that similarly "just works" without any
configuration?
Simon (Woodside), this bug is resolved wontfix. If you want to reopen it, that's
great, go for it, but I would hope that means you're arguing for it, not against
it as your last comment seems to do. Until then, this bug won't be worked on
anymore. 

As a sidenote, for those of you that voted for this bug, it might be good to
remove your vote from it and add it to something that will actually be implemented.
*** Bug 218600 has been marked as a duplicate of this bug. ***
Pretty sure Prachi's pref pane won't work any more, but I'm working on a pane that puts UI onto the permissions manager, and one of our other devs is working on a UI for CAPS. Between those two, this ought to be pretty much taken care of.
Whiteboard: [good thirdparty]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: