299356 - permissions.default.image (image blocking) not working

Status: RESOLVED FIXED

(Camino Graveyard :: General, defect)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Apparently network.image.imageBehavior (used for image blocking) was replaced by
permissions.default.image on the trunk in December (?, bug 240070).

Folks upgrading from 0.8.4 to 0.9a1 are reporting that the old pref doesn't work
anymore (of course) and discovering the replacement doesn't either. 
<http://forums.mozillazine.org/viewtopic.php?t=282618> (there are several other
recent MZ forum threads tracking image-blocking problems that are probably related)

I've confirmed that user_pref("permissions.default.image", 2); (which should
block all images) does absolutely nothing.  In tonight's Deer Park, turning off
"Load Images" (their UI for this pref) works as expected.

When all of the changes were done on the trunk, did someone forget to update
Camino (or tell you Camino needed changes)?  I'm not sure who to cc from Core
about this....

Our hostperm.1 not blocking subdomains/images (bug 281000) could be related, but
we were getting some blocking through March, so it's not a straight dupe.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Does camino build the "permissions" extension?

Comment 2

[Josh Aas]

Putting this on the 0.9 list at least until we have some better analysis.

Comment 3

[Josh Aas]

Attachment: fix v1.0

This should fix it. I don't have time right now to respin my build and check.

Apply this patch, then run fink's version of autoconf in the mozilla dir
(/sw/bin/autoconf). May need to do make clean or something like that first.

Comment 4

[Simon Fraser [no longer active]]

I'll review once it's been tested  :)

Comment 5

[Josh Aas]

You need to add libpermissions.dylib to the project file and put it in the copy
files phases for static and shared products. I can't do this because I only have
Xcode 2.1 machines.

Simon or Mike - I'm pretty sure that my patch plus the project file changes I
just described, and running /sw/bin/autoconf in root source dir (to pick up the
patch's configure.in changes) will fix this bug. Somebody is going to have to
test it with an Xcode project modified by pre-2.1 anyway.

Comment 6

[Josh Aas]

can't take this one any further myself

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Let's at least give it back to Mike :-)

Comment 8

[Simon Fraser [no longer active]]

I'll test.

Comment 9

[Simon Fraser [no longer active]]

Attachment: Patch to configure.in, and the camino project

Comment 10

[Mark Mentovai]

Comment on attachment 189203 [details] [diff] [review]
Patch to configure.in, and the camino project

r=me, noting:

+ path = ../extensions/permissions/libpermissions.a;

We do this elsewhere in the project, so it's OK, but I think it's better in
general to make references to the links in ../dist.  It's a mish-mash now, but
using dist consistently prevents having to do this silliness:

+ LIBRARY_SEARCH_PATHS = "../dist/bin ../dist/lib ../dist/lib/components
../intl/unicharutil/src ../gfx/src ../js/src/liveconnect
../intl/unicharutil/util ../js/src/xpconnect/loader
../extensions/transformiix/build ../extensions/permissions";

each and every time.

It should also save us from having to withstand changes to the internal
structures of all of those directories, but we've got the same problem with
bin-lib confusion in dist for the moment anyway.

Comment 11

[Simon Fraser [no longer active]]

Checked in (with some project path tidyup).

Comment 12

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Reopening because this isn't fixed in 20050714.  I know the changes made it into
this build because the tooltip fix works, and it was checked in after this, and
because permissions.default.image shows up in the third-party about:config
prefpane (with a default of 1).

If I change that to 2 (or put an entirely new pref in user.js with it set to 2
and relaunch Camino), all images are still loaded, even on sites I've never
visited before.

So even though we're building the permissions extension, something else is still
missing :-(

Comment 13

[Mark Mentovai]

Attachment: Fix static builds

I'm testing this right now.

Comment 14

[Mark Mentovai]

Comment on attachment 189413 [details] [diff] [review]
Fix static builds

Fix is incomplete, doesn't fix the problem.

Comment 15

[Mark Mentovai]

Also need to add the permissions module to nsStaticComponents.cpp, but it seems
incomplete even with that.

Comment 16

[Simon Fraser [no longer active]]

I thought nsStaticComponents.cpp was generated at build time with the
appropriate components?

Comment 17

[Mark Mentovai]

We wish.  Camino has a static nsStaticComponents file, because it can't use the
one generated at build time for suite.  I'd like to revisit this and have the
Camino build use suite's file, stripping out unneeded components, but that
wouldn't help here either (yet).

Comment 18

[Mark Mentovai]

Attachment: Fix static builds for real

It was an ordering problem.  This one's good.

Comment 19

[Mark Mentovai]

Checked in.  Sorry I couldn't make the cutoff for the morningly.