Closed
Bug 73848
Opened 24 years ago
Closed 24 years ago
Image blocking no longer works
Categories
(Core :: Graphics: ImageLib, defect, P4)
Core
Graphics: ImageLib
Tracking
()
mozilla0.9.2
People
(Reporter: morse, Assigned: pavlov)
References
(Blocks 1 open bug)
Details
(Keywords: regression, Whiteboard: will be fixed by 84162)
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
Go to any page that has an image
Rightclick on the image and select block-image from the context menu
Reload the page
The image still loads.
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Comment 1•24 years ago
|
||
Actually, if you go to the Image Manager (Tasks | Privacy and Security | Image
manager | View sites that can/cannot display images), any site you have
attempted to block images from is listed as "site cannot set cookies".
This is with build 2001033121
Reporter | ||
Comment 2•24 years ago
|
||
The mis-wording of cookies instead of images is covered in bug 74089. Patch is
available and it is currently awaiting super-review.
Comment 3•24 years ago
|
||
I'm also seeing this on Linux build 2001040505.
Is the patch mentioned in the previous comment one that fixes this bug or bug 74089?
Reporter | ||
Comment 4•24 years ago
|
||
Sorry, I wasn't clear in my comment. I was referring to bug 74089 and its
patch. And it now has been checked in.
Comment 6•24 years ago
|
||
I'm seeing this on Linux build 2001040908. In fact, it's not limited to
context-menu image blocking; I have "Do not load any images" enabled and still
get new images downloaded.
At least banner-style images (like at mozilla.org and mozillazine.org) no longer
crash the browser.
Comment 8•24 years ago
|
||
This also happens in Linux (which I hinted at in my last comment). Should "OS"
be set to "All"?
Updated•24 years ago
|
Whiteboard: [imglib]
Comment 11•24 years ago
|
||
*** Bug 75394 has been marked as a duplicate of this bug. ***
Comment 12•24 years ago
|
||
It can get even worse.
As of 2001041214 (Linux sea from mozillazine), I can reliably (i.e. I do
reproduce it at will) crash mozilla at phoenix.cyril.com when I have
image/cookie warning enabled. If I turn both warnings off it works (and no
cookies appear in cookie manager, so it's image blocking). Turn both back on and
try to load site, instant SEGV. The name of the function I can see at gdb is
something image-related (and after something at 0x6... Looks hyperspace to me.
Looks like it's jumped to the void). I can post the entire backtrace here if you
want.
If someone else reproduces this, it means we have a crasher...
Reporter | ||
Comment 13•24 years ago
|
||
The crashing that you are observing is bug 75661
Comment 14•24 years ago
|
||
*** Bug 76113 has been marked as a duplicate of this bug. ***
Comment 15•24 years ago
|
||
*** Bug 74213 has been marked as a duplicate of this bug. ***
Comment 16•24 years ago
|
||
*** Bug 73303 has been marked as a duplicate of this bug. ***
Updated•24 years ago
|
Keywords: nsbeta1,
regression
Assignee | ||
Updated•24 years ago
|
Target Milestone: --- → mozilla0.9.2
Comment 17•24 years ago
|
||
*** Bug 76348 has been marked as a duplicate of this bug. ***
Comment 18•24 years ago
|
||
*** Bug 76341 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 19•24 years ago
|
||
The symptoms here were strange in that at some sites this appears to be working
but at other sites not. Finally bug 77331 explained the dispcrepency. If the
images are coming from stylesheets image blocking will work. Otherwise it will
not. The url sited in bug 77331 which demonstrates this is
http://www.w3.org/Style/CSS/Test/current/sec533.htm
Comment 20•24 years ago
|
||
*** Bug 77367 has been marked as a duplicate of this bug. ***
Updated•24 years ago
|
Keywords: mozilla0.9.1
Comment 21•24 years ago
|
||
morse: Now you've fixed bug 77331, do you know offhand if this is still
happening?
Gerv
Reporter | ||
Comment 22•24 years ago
|
||
Bug 77331 has nothing to do with this bug. That bug dealt with a file
destruction that was occuring in the case that image block actually worked.
What wasn't clear at first is to why it was even working well enough to trigger
bug 77331 but now we know. Image blocking works in the case of style-sheet
images but not for normal html images. And the fact that it doesn't work for
normal html images is what this bug is about.
Comment 23•24 years ago
|
||
*** Bug 79330 has been marked as a duplicate of this bug. ***
Comment 24•24 years ago
|
||
*** Bug 79401 has been marked as a duplicate of this bug. ***
Comment 25•24 years ago
|
||
*** Bug 80578 has been marked as a duplicate of this bug. ***
Comment 26•24 years ago
|
||
*** Bug 81199 has been marked as a duplicate of this bug. ***
Comment 27•24 years ago
|
||
*** Bug 81501 has been marked as a duplicate of this bug. ***
Updated•24 years ago
|
Blocks: LoadImages
Assignee | ||
Comment 28•24 years ago
|
||
Assignee | ||
Comment 29•24 years ago
|
||
This should work, although I haven't fully tested it. Some null checks here and
there would probably be smart too.
Keywords: patch
Comment 30•24 years ago
|
||
The 'block image from loading' context menu option has also disappeared,
or at least it never appears now in my random sample of images it used to
appear for. (There are some images that it never appeared for,
see bug #78617)
I'm using 2001052308 trunk build.
Comment 31•24 years ago
|
||
Correction to my previous comment.
The image block option still exists. The problem I was having is that
sometimes when you right click on an image you get the context menu for the
page-in-general instead of the one for an image. This seems to have something
to do with the nature of the image and the HTML that loaded it, and I can't
figure out when it works and when it doesn't. In any case, it's a separate
bug.
Try right clicking in different parts of the mozilla.org banner; I can reliably
get the image menu in the left two thirds and the page menu in the right third.
Comment 32•24 years ago
|
||
*** Bug 83461 has been marked as a duplicate of this bug. ***
Comment 33•24 years ago
|
||
Right-clicking on the right-hand side of the mozilla.org banner *should* give
the page menu, since that's not an image. The image ends shortly after the
"mozilla.org" text, and the rest is a table background. That's not a bug.
On the other hand, after a server is on the image blocking list, "block images
from this server" no longer appears on the image menu for images from that
server. That also doesn't seem like a bug to me, but because of *this* bug
(that images don't get blocked) it's just confusing.
Comment 34•24 years ago
|
||
Thanks for the clarifications. Sounds like there isn't a second
user-interface bug.
Comment 35•24 years ago
|
||
Just confirming:
Image blocking doesn't work in
0.9.1 latest build id 2001-06-01-16 windows zipped version
Reproduce after setting block or don't accept images in pref:
Open menu Debug + View Demos + #2 images
While your there check out bug
http://bugzilla.mozilla.org/show_bug.cgi?id=77914
black background on transparent gifs.
This 0.9.1 latest should come much later IMO
Comment 36•24 years ago
|
||
We either need to get this patch finished, reviewed and super-reviewed for 0.9.1
or remove the image blocking UI. Which is it to be?
Gerv
Comment 37•24 years ago
|
||
There will be lots of negative reaction to a release of the browser that makes
it impossible to control what content you receive from a site. Those whose
phone calls are per-minute charges when they dial up will be particularly
hesitant to try it out until they can force it to get only the text content of a
page they're visiting. That's what's pushed me back to Netscape 4.77 or
Konqueror [only 2.1.1] for the moment, for instance.
B
Assignee | ||
Comment 38•24 years ago
|
||
the patch is ready to go i think.
Priority: -- → P4
Whiteboard: [imglib] → needs r=, sr= and a=
Comment 39•24 years ago
|
||
OK, let's try and get the patch in, then.
(Pav: hope you don't mind me messing with your bug.)
Gerv
Target Milestone: mozilla0.9.2 → mozilla0.9.1
Assignee | ||
Updated•24 years ago
|
Whiteboard: needs r=, sr= and a= → r=valeski, sr= and a=
Comment 40•24 years ago
|
||
we may want to consider going w/ the patch in
http://bugzilla.mozilla.org/show_bug.cgi?id=84162 instead.
Assignee | ||
Comment 41•24 years ago
|
||
adding dependancy on 84162. lets check that in instead. moving back to 0.9.2
since there is no way netscape will let this get checked in for 0.9.1... mozilla
might however, so if you want to get an a= from mozilla, go for it.
Reporter | ||
Comment 42•24 years ago
|
||
I don't understand how the patch in bug 81462 will magically make image blocking
start to work again. I thought the problem was that at image loadtime we
weren't making the calls to check if we shouldn't load. Seems like we will
still be missing those calls even after the patch in bug 81462 gets in.
Has anyone tested that the patch in 81462 actually makes image blocking work
again?
Comment 43•24 years ago
|
||
Morse: You certainly mean bug 84162, not 81462. I was really surprised that
"Missing OS/HW in default distro" can block anything ;-)
Comment 44•24 years ago
|
||
Note: this patch has r=valeski from IRC.
Gerv
Comment 45•24 years ago
|
||
we should snuff this bug out (dupe it?) in favor of 84162.
Comment 46•24 years ago
|
||
valeski: That assumes bug 81462 fixes the problem. Morse doesn't seem too sure
about that. Can you confirm it does?
Gerv
Comment 47•24 years ago
|
||
84162 fixes the problem w/ a tweak I'm waiting on pavlov to comment on. it's
also more architecturally sound, uses an existing callpath (won't impact
performance at all, as this patch will), and uses a more prolific load blocking
model.
after some thought and further inspection, I'm actually going to have to pull my
r= on this one because I don't think it covers all the image loading cases (like
DOM element src attribute loads), which 84162 does (by virtue of using
nsIContentPolicy).
If we want to persue this patch, we'll probably need to add blocking to these
sites as well
http://lxr.mozilla.org/seamonkey/search?string=nsIContentPolicy%3A%3AIMAGE%2C .
Assignee | ||
Comment 48•24 years ago
|
||
this patch is pointless if you make nsIContentPolicy check cookie/wallet stuff.
Updated•24 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Comment 49•24 years ago
|
||
Comment 50•23 years ago
|
||
*** Bug 84601 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•