Closed Bug 49810 Opened 25 years ago Closed 23 years ago

Proxy: no auth for inline images <IMG>

Categories

(Core :: Graphics: ImageLib, defect, P3)

Product:
Core
Component:
Graphics: ImageLib
Platform:
x86
Windows 95
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 62108
Milestone:
mozilla0.9.4

People

(Reporter: Matt.Behrens, Assigned: gagan)

Details

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20000817 BuildID: 2000081708 If a proxy server needs authentication to work, and you are opening a local page that includes images on hosts that you need the proxy server's assistance to get to, Mozilla will display nothing (i.e. 0px x 0px) in the image's place. Reproducible: Always Steps to Reproduce: 1. Find a friendly neighborhood password-authenticating proxy. 2. Open the following code up in Mozilla: <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN"> <html> <head> <title>Untitled</title> </head> <body> <p><a href="http://validator.w3.org/check/referer"><img src="http://validator.w3.org/images/vh401.gif"></a></p> </body> </html> 3. Note the link border is drawn, but there is no image. 4. Now go to a page that will force Moz to ask you for a username/password for your proxy (i.e. www.mozilla.org). 5. Go back to your previous page and reload. The image should now display. Actual Results: Expected Results:
Correction to the reproduction instructions: you don't need to reload in step 5.
'Tis true... 2000103004 on Win2k
Status: UNCONFIRMED → NEW
Ever confirmed: true
This is most likely related to bug 56031
I tend to agree; the behavior in bug 56031 sounds identical to me. I don't *think* it's a duplicate (though those with more experience are certainly welcome to disagree). Can someone confirm this is a dependency?
Depends on: 56031
Proxy auth and normal server auth go through the same code path. This is almost definitely a dupe of bug 56031. The problem is that HTTP cannot prompt the user for authentication because the code that creates the HTTP channel does not implement the nsIPrompt interface. This is not a necko bug; rather, it is a bug in the code that uses necko. *** This bug has been marked as a duplicate of 56031 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Verify dupe. Also removing dependency
Status: RESOLVED → VERIFIED
No longer depends on: 56031
REOPENING: The original duplicate is actually bug 62108, but since Proxy needs to be tested separately, I'm un-duping this.
Status: VERIFIED → REOPENED
QA Contact: tever → benc
Resolution: DUPLICATE → ---
Summary: no attempt to load img if proxy password blocks → Proxy: no auth for inline images <IMG>
Hmmm... Pavlov didn't you fix this yet? (a dup of your bugs?) I thought the problem was just that imglib was not handing over the loadgrp correctly for auth to take place. I will continue to hold this till the dup is found...
Target Milestone: --- → mozilla0.9.3
gagan: its a dup of 62108
Doesn't look like this is getting fixed before the freeze tomorrow night. Pushing out a milestone. Please correct if I'm mistaken.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
*** This bug has been marked as a duplicate of 62108 ***
Status: REOPENED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → DUPLICATE
Is fixing that bug going to automatically fix this one?
yes and that is why its marked dup.
just checking. I think there was one or two cases where there was some separation...
opps. there.
Status: RESOLVED → VERIFIED
Hmm, this means that ImageLib is also going to need to add some proxy testing to their test cases...
Component: Networking → ImageLib
QA Contact: benc → tpreston
You need to log in before you can comment on or make changes to this bug.