permissions.default.image (image blocking) not working



14 years ago
14 years ago


(Reporter: alqahira, Assigned: sfraser_bugs)


(Blocks: 1 bug, {regression})

Mac OS X
Dependency tree / graph
Bug Flags:
camino0.9 +



(3 attachments, 1 obsolete attachment)

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. 
<> (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.
Does camino build the "permissions" extension?
Blocks: 281000

Comment 2

14 years ago
Putting this on the 0.9 list at least until we have some better analysis.
Flags: camino0.9? → camino0.9+
Target Milestone: --- → Camino0.9

Comment 3

14 years ago
Created attachment 188736 [details] [diff] [review]
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.
Assignee: pinkerton → joshmoz
Attachment #188736 - Flags: review?(sfraser_bugs)

Comment 4

14 years ago
I'll review once it's been tested  :)

Comment 5

14 years ago
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 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

14 years ago
can't take this one any further myself
Assignee: joshmoz → nobody
Let's at least give it back to Mike :-)
Assignee: nobody → pinkerton

Comment 8

14 years ago
I'll test.
Assignee: pinkerton → sfraser_bugs


14 years ago
Attachment #188736 - Flags: review?(sfraser_bugs) → review-

Comment 9

14 years ago
Created attachment 189203 [details] [diff] [review]
Patch to, and the camino project
Attachment #189203 - Flags: review?(mark)

Comment 10

14 years ago
Comment on attachment 189203 [details] [diff] [review]
Patch to, 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.
Attachment #189203 - Flags: review?(mark) → review+

Comment 11

14 years ago
Checked in (with some project path tidyup).
Last Resolved: 14 years ago
Resolution: --- → FIXED
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 :-(
Resolution: FIXED → ---

Comment 13

14 years ago
Created attachment 189413 [details] [diff] [review]
Fix static builds

I'm testing this right now.
Attachment #189413 - Flags: review?(sfraser_bugs)

Comment 14

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

Fix is incomplete, doesn't fix the problem.
Attachment #189413 - Attachment is obsolete: true
Attachment #189413 - Flags: review?(sfraser_bugs)

Comment 15

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

Comment 16

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

Comment 17

14 years ago
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

14 years ago
Created attachment 189432 [details] [diff] [review]
Fix static builds for real

It was an ordering problem.  This one's good.
Attachment #189432 - Flags: review?(sfraser_bugs)


14 years ago
Attachment #189432 - Flags: review?(sfraser_bugs) → review+

Comment 19

14 years ago
Checked in.  Sorry I couldn't make the cutoff for the morningly.
Last Resolved: 14 years ago14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.