Closed
Bug 299356
Opened 20 years ago
Closed 20 years ago
permissions.default.image (image blocking) not working
Categories
(Camino Graveyard :: General, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
Camino0.9
People
(Reporter: alqahira, Assigned: sfraser_bugs)
References
Details
(Keywords: regression)
Attachments
(3 files, 1 obsolete file)
622 bytes,
patch
|
sfraser_bugs
:
review-
|
Details | Diff | Splinter Review |
7.20 KB,
patch
|
mark
:
review+
|
Details | Diff | Splinter Review |
2.19 KB,
patch
|
sfraser_bugs
:
review+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Updated•20 years ago
|
Flags: camino0.9?
Putting this on the 0.9 list at least until we have some better analysis.
Flags: camino0.9? → camino0.9+
Target Milestone: --- → Camino0.9
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
Status: NEW → ASSIGNED
Attachment #188736 -
Flags: review?(sfraser_bugs)
Assignee | ||
Comment 4•20 years ago
|
||
I'll review once it's been tested :)
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.
can't take this one any further myself
Assignee: joshmoz → nobody
Status: ASSIGNED → NEW
Reporter | ||
Comment 7•20 years ago
|
||
Let's at least give it back to Mike :-)
Assignee: nobody → pinkerton
Assignee | ||
Updated•20 years ago
|
Attachment #188736 -
Flags: review?(sfraser_bugs) → review-
Assignee | ||
Comment 9•20 years ago
|
||
Attachment #189203 -
Flags: review?(mark)
Comment 10•20 years ago
|
||
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.
Attachment #189203 -
Flags: review?(mark) → review+
Assignee | ||
Comment 11•20 years ago
|
||
Checked in (with some project path tidyup).
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 12•20 years ago
|
||
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 :-(
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 13•20 years ago
|
||
I'm testing this right now.
Attachment #189413 -
Flags: review?(sfraser_bugs)
Comment 14•20 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•20 years ago
|
||
Also need to add the permissions module to nsStaticComponents.cpp, but it seems
incomplete even with that.
Assignee | ||
Comment 16•20 years ago
|
||
I thought nsStaticComponents.cpp was generated at build time with the
appropriate components?
Status: REOPENED → ASSIGNED
Comment 17•20 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•20 years ago
|
||
It was an ordering problem. This one's good.
Attachment #189432 -
Flags: review?(sfraser_bugs)
Assignee | ||
Updated•20 years ago
|
Attachment #189432 -
Flags: review?(sfraser_bugs) → review+
Comment 19•20 years ago
|
||
Checked in. Sorry I couldn't make the cutoff for the morningly.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•