Closed Bug 136091 Opened 22 years ago Closed 22 years ago

Port number in image source disables image blocking

Categories

(Core :: Graphics: Image Blocking, defect)

Product:
Core
Component:
Graphics: Image Blocking
Platform:
x86
Windows 98
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED DUPLICATE of bug 69486
Milestone:
mozilla1.1beta

People

(Reporter: svl-bmo, Assigned: morse)

Details

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.9) Gecko/20020311
BuildID:    2002031104

If the url of the image src includes a portnumber, the image will always
display, even after "block images from this server"

Reproducible: Always
Steps to Reproduce:
1. find a site showing an image whose url includes a port number
2. block images from this server
3. reload the page

Actual Results:  The image is still showing, even though images from the server
are listed as blocked (right clicking gives "unblock images from this server").

Expected Results:  The image shouldn't be showing.

I've noticed this happening occasionally for quite a while, but since most sites
rotate between many banners, and most don't use ports, 't took some time before
I reproduced this. Finally caught the code today, at http://trekbbs.com
Here's the (simplified) code of one banner using this

<html>
<body>
<img
src="http://mediamgr.ugo.com:80/image.ng/params.richmedia=no&UID=mpixWg,Rlbwajbnluy&size=468x60&affiliate=treknation&channel=filmtv&subchannel=scifi&Network=affiliates&rating=g"
border=0>
</body>
</html>

Copy/paste to a local html file and loading that should allow you to reproduce
the problem. I don't know if the port use to get around image blocking here is
deliberate, but if it is, that is not a good thing - soon all banners might use
this to circumvent Mozilla's image blocking.
Really a dupe of bug 84776, which was closed as WONT-FIX.  However, it was
closed for what I believe is the wrong reason.

Morse: my original intent for bug 84776 wasn't that the port number should be
ignored for image blocking.  I meant that when a port number was specified, then
blocking didn't work at all for that image.  For example, I pasted the HTML code
given by the reporter in this bug into a local file and tried blocking the image
when viewing that file.  After I select "Block this image" from the context
menu, if I reload the file, I see the context menu now contains "Unblock image".
 However, the image itself is NOT being blocked;  it still appears.

Therefore, CONFIRMING.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → mozilla1.1beta
I have updated myself on this discussion.  Maybe Morse or someone knows where
the buggy code lives (i.e., the code that decides whether or not to load an
image based on the image management prefs).  My best guesses are
(extensions/cookies/) nsImages.cpp, nsImgManager.cpp or nsPermissions.cpp.  I am
not familiar enough with this stuff to really help.
I have observed this bug on _every_ Win98 and Linux build I have ever used (I
only go back to 0.9.6 or so).  Would very much like this bug fixed.
This bug is a dup of the incorrectly named bug 69486. A patch which fixes this
problem is attached to that bug.
Neat, thanks.  Should this bug then be marked as a dupe of Bug 69486?  If that
happens, it would probably be a good idea to change the summary of 69486, no?  I
don't know about the rules on doing that, but like you said, it is currently
mis-named (summarized incorrectly).

*** This bug has been marked as a duplicate of 69486 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
QA Contact: tever → nobody
V/dupe.
Status: RESOLVED → VERIFIED
QA Contact: nobody → benc
You need to log in before you can comment on or make changes to this bug.