Closed Bug 121084 (Heidi) Opened 23 years ago Closed 21 years ago

cache: Images requested twice -> "The image cannot be displayed, because it contains errors." message [when "Compare the page in cache ..." set to "every time I view the page"]

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.4beta

People

(Reporter: caillon, Assigned: jdunn)

References

(Regressed 1 open bug,
URL
)

Details

(6 keywords, Whiteboard: [Hixie-P3] (py8ieh:202), needs r=, needs sr=)

Attachments

(4 files, 5 obsolete files)

stack trace showing LoadImage being called after LoadImageWithChannel
9.60 KB, text/plain
Details
shows an external link, bug showed up on linux
188 bytes, text/html
Details
Use URI and not OriginalURI (which could be a referrer)
556 bytes, patch
pavlov
: review+
darin.moz
: superreview+
Details | Diff | Splinter Review
oops, that had one small problem...
13.52 KB, patch
pavlov
: review+
jst
: superreview+
Details | Diff | Splinter Review 
Using linux 2002012021:

0) set "Compare the page in cache to the page on the network" 
   to "Every time I view the page".
1) Visit the URL.

Actual Results: Heidi Klum appears for a second then turns into the text of the
image's location.

Expected Results: Heidi Klum portals through my monitor, we do lunch, buy our
own private island, and live happily ever after together.  Failing that, her
image should at the least not dissapear.
Okay they block sites with outside referrers.  Get to the URL from here:
http://www.celebrityy.com/heidiklum/heidiklum17.htm
URL: http://www.celebrityy.com/heidiklum/6...
(warning.  above link may be offensive to some and not suitable for minors)
Target Milestone: --- → Future
I also see this bug on Win98, 2002021503, so it's not a Linux-only bug. I'm
seeing this on other sites that have small thumbnails and larger pictures (on
clicking the thumbnails). I'd say this is almost blocker-status. How come this
bug is Future'd???
Nominating on behalf of trusted2mozilla.org@slater.ch

<sl8r> matti: i'm saying that at least for me this is a highly visible bug. i
can't believe that nobody else is seeing it. there are no dupes etc.
<sl8r> caillon: yeah... and i can't nominate it for anything, i'm not
"sufficiently empowered" ... *sigh*
Keywords: mozilla1.0, nsbeta1
Seen on WinXP 2002040303, setting OS/Plat All
OS: Linux → All
Hardware: PC → All
Hmmm... this is interesting. For whatever reason (the bug) we are sending a
second request right after the first one is done. The second request does not
have the referer header that the first one does which makes the server reply
back with a complaint redirect (to go to / etc.)and hence we land up showing
just the URL for the image.

So the real bug is probably just that we are issuing a second request after the
image loads the first time. Why? cc'ing darin and gordon here.

Considering the fact that I couldn't get this to reproduce behaviour on other
sites I think this is low visibility (wrt the other bugs on pav's plate) hence
marking a nsbeta1-
Keywords: nsbeta1 → nsbeta1-
bug 137805 is probably a dup of this (or the other way round)
*** Bug 134766 has been marked as a duplicate of this bug. ***
*** Bug 137805 has been marked as a duplicate of this bug. ***
Priority: -- → P3
Target Milestone: Future → mozilla1.1alpha
*** Bug 140347 has been marked as a duplicate of this bug. ***
*** Bug 140871 has been marked as a duplicate of this bug. ***
Summary: Heidi Klum doesn't like being compared to the cache → Heidi Klum doesn't like being compared to the cache: Images requested twice -> "The image cannot be displayed, because it contains errors." message
*** Bug 141233 has been marked as a duplicate of this bug. ***
I had seen this bug for ages - and thought it was bug 88054 - but I've now found
that I don't ever get the URL anymore.  What I'm seeing for a little while now
is things like

The image " <insert image url here> " cannot be displayed, because it contains
errors.

Aside from the fact that this is poor grammer (unnecessary comma) - is this a
new bug or a morph of the old one?

BTW, it still has the same problems that the bug with the URL had... reloading
will sometimes work, sometimes not and it appears that the image is trying to
load twice because it will appear for a second before it gives this new error.
This bug is highly reproducable and visible gagan. Very annoying when viewing
many pictures. I'm on Linux here with the 1.0 rc1. This must get high priority
cause awfull. Never seen this with Netscape <= 6.2.2.
Guy.
*** Bug 142944 has been marked as a duplicate of this bug. ***
If this is not fixed by 1.0 it needs to be release noted. Adding relnote keyword.

Changing the cache settings to "When the page is out of date" fixes the problem
for me and is a satisfactory workaround, does anyone still see this with the
workaround?
Keywords: relnote
*** Bug 141106 has been marked as a duplicate of this bug. ***
Blocks: 143488
*** Bug 143884 has been marked as a duplicate of this bug. ***
*** Bug 143906 has been marked as a duplicate of this bug. ***
*** Bug 144277 has been marked as a duplicate of this bug. ***
as brett denny mentioned before (#13)... i've seen this bug for ages, too. since
the very first version i ever tested. and that was an early 0.8.x one. :o(

just taking it into relnote is not a good idea (in my opinion). it should be
fixed for 1.0 final.
I'm frequently seeing this bug on www.versiontracker.com/macosx/ as well, when I
click on a file link. After see the 'image cannot be displayed' message, i hit
the back button, try clicking the same link again, and crash every time.
*** Bug 144529 has been marked as a duplicate of this bug. ***
*** Bug 144519 has been marked as a duplicate of this bug. ***
I see this bug on Win NT4 (1.0 RC 1) and on Linux (I believe it is 0.9.8?).  It
happens on any site with images; even Google.  Hitting Shift/Reload ALWAYS fixes
the problem.  The page initially displays with image place-holders.  Right
clicking and selecting "View Image" produces the "cannot be displayed, because
it contains errors" message.  So I Shift/Reload and all is well.  It is meerly
anoying.
Hmm,I had set my Preferences>Advanced>Cache>"Compare the page in cache to the
page on the network"  to "when the page is out of date" because of the frequency
I was seeing the bug with it set to "Every time I view the page."  

The day before last, I had the same problem seeing broken gifs again- WITH it
set to "When the page is out of date."  I thought that setting that would be a
work-around, but apparently not always.  If anybody else sees this, please say
so.  I hit "Clear Disk Cache" and then "Clear Memory Cache" and then I could
reload the page correctly, so I do believe this is part of the same problem.
I think its probably a recent regression, possibly related here but maybe not. 
Either that or the image you're viewing is really not able to be displayed
because it really does contain errors...

In any case, I can reproduce that here:
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=83697

...even with the cache setting
Windows 2000:
I've run into this sort of problem with images a lot lately.  Also, if opening
images in new tabs or windows a fair amount of them will not load completely, if
at all.
*** Bug 143488 has been marked as a duplicate of this bug. ***
*** Bug 145993 has been marked as a duplicate of this bug. ***
*** Bug 146114 has been marked as a duplicate of this bug. ***
A note from the previous duplicate - it happens in my case when I hit a submit
button that calls a script to dynamically generate an image.  Shift-reload
doesn't help in that case - the only thing that does is changing the cache
settings to "when page is out of date".
*** Bug 146906 has been marked as a duplicate of this bug. ***
*** Bug 123850 has been marked as a duplicate of this bug. ***
*** Bug 145868 has been marked as a duplicate of this bug. ***
*** Bug 147450 has been marked as a duplicate of this bug. ***
I am also seeing this bug on Win98 / RC3. It has been present at least since
0.8.6 in all release versions.
It should be fixed for 1.0 as it is really annoying (specially when you try to
show some pictures with the best browser to your friend).
*** Bug 147771 has been marked as a duplicate of this bug. ***
*** Bug 147879 has been marked as a duplicate of this bug. ***
occurs on WinXP with RC3, please fix for 1.0, it's very annoying as it occurs
dozens of times per day, it's almost enough to make me switch browsers
*** Bug 148042 has been marked as a duplicate of this bug. ***
*** Bug 147674 has been marked as a duplicate of this bug. ***
Hi guys,

I've been experiencing this bug to but I've made a little research. This bug not
only affects images, it also affects CSS. I use a Win Me PC with 4 browsers: IE
5.5, Netscape 4.75, Netscape 6.2.1 and Mozilla 1.0 RC3. I noticed that when you
install Mozilla, the configuration of N6.2 is affected to and the images and CSS
aren't interpreted correctly, as in Mozilla. If you Shift+Reload it works again
as you guys already noticed. If you uninstall Mozilla, N6.2 starts working fine
again.

I have a little web server on my PC and the first time I load the page in the
morning all the images and styles (from an external CSS file) colapse. If I use
Shift+Reload it works fine until the next day. Any configuration change that you
can made on the Preferences won't fix this problem. I've experienced this
problem with sites like eBay, Half, Amazon and Google.

I'm only guessing but I think that this bug must be something related with some
kind of external file interpretation, so it affects images and CSS as well.

Bye,

Esteban Mora (Costa Rica)
*** Bug 135597 has been marked as a duplicate of this bug. ***
*** Bug 140684 has been marked as a duplicate of this bug. ***
*** Bug 149688 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0) Gecko/20020530

I was having the same problem loading images.

I tried the workaround and changed my cache setting

It works fine now will follow up if I run into more of the same error
This sounds much more like a networking bug (plus Stuart seems busy with other
things).  This is a frequently duped bug; someone should at least get a handle
on what's occuring.

Adding perf, since it causes refetches it appears (IRC conversation)
Assignee: pavlov → darin
Component: ImageLib → Networking: HTTP
Keywords: mozilla1.0 → mozilla1.1, perf
QA Contact: tpreston → tever
Here is an non-adult testcase:
http://gamma.gavert.net/~erik/testcase/test.html

It seems to compare always way to early .. 
It should ofcourse only check the network if the page was actually fetched from
cache. 
*** Bug 149970 has been marked as a duplicate of this bug. ***
*** Bug 150369 has been marked as a duplicate of this bug. ***
*** Bug 150534 has been marked as a duplicate of this bug. ***
*** Bug 139430 has been marked as a duplicate of this bug. ***
I believe this belongs in this bug (refer me to the right bug # if it doesn't)

Test URL:
http://animecity.nu/Mozilla/IMGTest/AlternatingImage.asp

The URL alternates between returning one of two images (non porn :P) 
Mime Type is set to "image/jpeg" 

Steps:
1) Go to URL

Expected Results:
- 1 image displayed

Actual Results:
- 1st image is displayed and then replaced by the second image.

In case someone out there is ASP savy, here's the ASP script:
<%
Response.ContentType = "image/jpeg"

Application.Lock
if Application("FlipFile") = "km_neko_017.jpg" then
  Application("FlipFile") = "km_neko_016.jpg"
else
  Application("FlipFile") = "km_neko_017.jpg"
end if
Application.Unlock

Set objBinFile = Server.CreateObject("ASPBinFile.clsASPBinFile")
mStream = objBinFile.BinFileRead(Server.MapPath(Application("FlipFile")))
Response.binarywrite mstream

Set objBinFile = Nothing
Set mStream = Nothing
%>

Requesting confirmation that the test belongs on this bug.
Comment 54 "requesting image twice" problem confirmed: build 2002061304/win2000.
Comment 54:
On Mozilla 1.1 alpha image1 loads first, than for a short time the error meesage
is displayed and then image2 starts to load.

I don't know which image should be displayed, since I've tried that in NS and
image1 was shown, but in IE image2 was shown.
URL: http://animecity.nu/Mozilla/IMGTest/A...
Summary: Heidi Klum doesn't like being compared to the cache: Images requested twice -> "The image cannot be displayed, because it contains errors." message → cache: Images requested twice -> "The image cannot be displayed, because it contains errors." message [when "Compare the page in cache ..." set to "every time I view the page"]
Miha: Either image is supposed to be displayed.. just not both.
Alias: Heidi
just to present feedback...

Build 20020607: Image 1 is shown, then image 2 is shown. no error message.

this bug is very vigorous. :o(
Yes we already noted back in comment #6 that we are requesting the images twice.
 Please read the whole bug before posting comments.  There is valuable
information  in the comments :)
(removing dependency, it was marked dup of this bug)

ok, we have two issues here:
1) The broken images, which occur both in the page itself and if the image is
opened "on its own". This is no surprise, because for displaying an image "on
its own", we create a HTML page containing an <img> tag for the image. Neil
suggested that maybe this is the reason for
2) requesting images twice if cache is disabled.
No longer blocks: 143488
This bug is intermitent, I have recieved the problem with both version 1.0 and
1.1 but only sometimes.  Sometimes the pages load fine.  I have also gotten this
error in Netscape 6.2.2 since I installed Mozilla (never before).  I'm on a
Win2000 box and sometimes the mmc console will kill my Java apps but I tried it
without running it after a reboot with no change.  The all the sudden it started
working again, didn't close the browser or anything.
I've had this bug for a very very long time (at least since 0.9.4). And there
are certain sites that ALWAYS give this bug. The images are loaded as thumbnails
there so when I click them the image loads full-size. Then I see the image load
and as soon as it has finished loading the error occurs.

*due to the nature of that site I will not post a link ;)
1.1alpha is no more -> 1.1beta
Target Milestone: mozilla1.1alpha → mozilla1.1beta
*** Bug 152933 has been marked as a duplicate of this bug. ***
I went to preferences/advanced and clean the disk cache. Everything came
afterwards normal. Anyhow, still a bug
When the cache is corrupted, it seems that a default template for the rendering
of a page is set : Fonts are big size, frames are not displayed properly,
updated information is not displayed ( only the old one on cache) and the whole
page is distorted (not to mention about pictures and gifs ). An indication is
when the mozilla/1.0/start page is not displayed; at this time a clean up of the
disk cache is needed...
Wow this one sucks.  Setting your cache to compare automatically is not a
sufficient work-around.  You must clear the cache to make things work again.
*** Bug 150689 has been marked as a duplicate of this bug. ***
Blocks: 153633
*** Bug 153105 has been marked as a duplicate of this bug. ***
Clearing cache fixed this for me. Noticed this affecting Flash as well as Gifs.
Feels like a bad bug to me, surely a P2 or even a P1? Joe Bloggs is just going
to think the browser is broken...
Here's my experience with this bug:

Running WinME, running Mozilla 1.0 since it's release, with no problems (except
recurring Acrobat issues, but that's another thread)

Today I ran Netscape 6.2 for the first time since installing Mozilla.  After
this, image loading was extremely unreliable on every web page I visited with
Mozilla.  Slashdot's title graphic wouldn't load.  Not a single image at CNN.com
would load.  Picking the context menu item "View Image" just gets me "The image
[url] cannot be displayed, because it contains errors."

My cache IS set to "When the page is out of date", and the problem persists. 
Rebooting did not help either.

Shift-Reload fixed the problem for a single page, and clearing the cache fixed
the problem permanently.

So my conclusion is that running Netscape 6.2 corrupted Mozilla's cache.  This
is NOT good.
I believe that clearing the cache only helps if a broken image is already cached
somehow, but it does not prevent images from being requested twice. 

Using BuildID 2002061018 (trunk) on Red Hat Linux 7.2 I've just cleared the
cache (both memory and disk), then went to
http://animecity.nu/Mozilla/IMGTest/AlternatingImage.asp and saw two images...
RE:Additional Comment #71 From bdcairns@hotmail.com

"Today I ran Netscape 6.2 for the first time since installing Mozilla.  After
this, image loading was extremely unreliable on every web page I visited with
Mozilla."

Very interesting. I run NN6.2 here myself (to test websites in). I wonder if
this is the root of the problem? How many of the people who are experencing this
bug are running 6.2? I am going to uninstall 6.2 and see if that fixes it.
I see this problem on my Linux box too, but i don't have Netscape installed. 
Bug is here, too.
Running Win 2k, no Netscape at all (never installed on this system).

Additional:
 Testsite from above (the one with the cats)...
 Appearing 1. cat with wood, 2. cat with water
 Setting: Compare cache everytime ...
 Clearing mem cache doesn't fix it.
 Clearing disk cache doesn't fix it.
 Clearing both at the same time doesn't fix it.

Very interesting:
 Shift-Reload "fixes the problem" (only the cat on water is shown)
 cilck reload... the problem reappears!
With cache setting "once per session" the image is requested twice.
With "when the page is out of date", only once.
This is on build id 2002053012/winNT, no netscape installed.
Blocks: 151432
*** Bug 156117 has been marked as a duplicate of this bug. ***
*** Bug 156310 has been marked as a duplicate of this bug. ***
*** Bug 156148 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of 98890 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Dude, don't dupe this bug to the other just because it has a lower number.  This
one has more people on it that care about the bug.  It's been triaged already
and people know how to find this bug and not the other. If the other is the same
as this, then dupe that one to this one.  Re-opening.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** Bug 98890 has been marked as a duplicate of this bug. ***
Fair enough - unless the reporter of bug 98890 now wants to object. <grin> 
There was a fair amount of work done on that one too.
Using Mozilla 1.0 on w2k, no Netscape installed ever on this pc
The problem only occurs when "Compare the page in the cache to the page on the
network" is set to "Every time I view the page".

If I visit http://www.sharding.org/outgoing/temp/testim.html (build by Sean
Harding) and click on "Image here", I first get the image and then the message:
'The image "http://www.sharding.org/outgoing/temp/testimg3.jpg" cannot be
displayed, because it contains errors.'
(Actually, the image does *not* contain errors)

- Mozilla gets the page from the network, with correct referrer
- the server returns the image
- Mozilla shows the image
- Mozilla gets the page again from the network, but this time the referrer is
left out and telling to only give it "If-Modified-Since: Fri, 15 Mar 2002
23:31:17 GMT"
- the server doesn't like that the referrer is missing and returns a 302
forbidden response telling the browser to go to
http://www.sharding.org/outgoing/temp/nono.html (for the explanation)
- Mozilla gets http://www.sharding.org/outgoing/temp/nono.html from the network
- the server returns this text/html-content page
- Mozilla apparantly still expects an image but gets the html-content and
responds with "The image cannot be displayed, because it contains errors."

Reload or Shift+Reload don't help.
What does help is left-mouseclick in the addressbar after
"http://www.sharding.org/outgoing/temp/testimg3.jpg" and hitting enter. Once
I've seen the "http://www.sharding.org/outgoing/temp/nono.html" page with text
"You can't have that.", it *seems* to work fine.

- Mozilla gets the page from the network, with correct referrer
- the server returns the image
- Mozilla shows the image
- Mozilla gets the page again from the network, but this time the referrer is
left out and telling to only give it "If-Modified-Since: Fri, 15 Mar 2002
23:31:17 GMT"
- the server doesn't like that the referrer is missing and returns a 302
forbidden response telling the browser to go to
http://www.sharding.org/outgoing/temp/nono.html (for the explanation)
- Mozilla gets http://www.sharding.org/outgoing/temp/nono.html from the network,
telling to only give it "If-Modified-Since: Wed, 06 Mar 2002 23:25:34 GMT"
- the server says it has not been modified since then
- Mozilla doesn't change anything, everything is fine

When I clear the Memory and Disk caches, the page is at its erratic behaviour again.
Status: REOPENED → ASSIGNED
In my previous comment (#84):
"the server doesn't like that the referrer is missing and returns a 302
forbidden response telling the browser to go to
http://www.sharding.org/outgoing/temp/nono.html (for the explanation)"
should be:
"the server doesn't like that the referrer is missing and returns a 302 found
response refering to http://www.sharding.org/outgoing/temp/nono.html"

Ok, we have lots of reports of people seeing the problem now.

The way I look upon it is that there are two problems.

The First One; 

When Mozilla does a cache validation update it does not submit a proper referer
      
 with the request which means that it will fail on some sites. 

If the cache update request fails it's also questionable if the data already   
 in the cache should be invalidated.


The Second Problem;

When set to "compare page in cache to network": "Everytime I view the page", the
page will be compared to the network even when it was not fetched from the cache. 

This bug is also very bad since it leads to double requests of very many pages.
I came to similar findings:

issue 1: Images get requested twice when "Compare the page in the cache to the
page on the network" is set to "Every time I view the page" This results in the
reported animation-like behavior in bug 153633

issue 2: If the image is requested the second time and also in a reload, the
referer is not included in the get-command. Some sites (esp. those of erotic
nature) don't like this and respond with a "302 found" referring to another uri.
(I think they should respond with a "303 see other")

issue 3: When Mozilla receives a 302 return, it gets the supplied uri. If this
is not of the same content type as the originally asked for content type,
Mozilla doesn't render. This results in the reported "The image  cannot be
displayed, because it contains errors."
According to http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3
many sites return a "302 found" while they should return a "303 see other".
Other browsers incorrectly treat those 302 as 303. 
I wonder if this is also an issue with 303 responses...
Is Mozilla correct here while the others are at fault? Is Mozilla 'too
correct/strict'?

FWIW, here's a version of my test page that sends a 303 instead of a 302:

http://www.sharding.org/outgoing/temp/testim303.html
here's a revision:

step 1: Images get requested twice when "Compare the page in the cache to the
page on the network" is set to "Every time I view the page" This results in the
reported animation-like behavior in bug 153633
First Mozilla just gets the image without checking the cache.
Then Mozilla gets the image again, telling the server to only actually give it
if it has been modified after the date+time of the cached version (which is
ofcourse brand-new). The referer is left out.
I guess only the second should remain but with referer.

step 2: If the image is requested this second time, the referer is not included
in the get-command. Some sites (esp. those of erotic nature) don't like this and
respond with a "302 found" or "303 see other" refering to another uri.

step 3: When Mozilla receives the 302/303 response, it gets the supplied uri.
The location bar never changes to this uri.
* If this uri is not already in Mozilla's cache:
The server returns the content. Mozilla seems to see this as a response to the
second get of the image. If this is not of the same content type as the
originally asked for content type, Mozilla doesn't render. This results in the
reported "The image  cannot be displayed, because it contains errors."
* If this uri is already in Mozilla's cache Mozilla tells the server to only
actually give it if it has been modified after the date+time of the cached version.
- If the server replies with "304 Not modified" Mozilla seems to see this as a
response to the second get of the image and all seems fine.
- If the server sees the content has modified since the given If-Modified-Since
it returns the 302/303 content. Mozilla seems to see this as a response to the
second get of the image. If this is not of the same content type as the
originally asked for content type, Mozilla doesn't render. This results in the
reported "The image  cannot be displayed, because it contains errors."

Problems that get fixed after clearing the cache do not fit in this scenario, do
they?
Wim Borghs: Please don't change the status to "assigned" if you are not the
assigned developer.
Status: ASSIGNED → NEW
Matti: That was not Wim's doing, I'm afraid I was the culprit.  I was trying to
revert everything back to the way it had been prior to having been marked as a
dupe and then re-opened.  I obviously didn't scan the Bug Activity log closely
enough.  (This was not the first bug on this problem, it was originally reported
several months earlier elsewhere - but neither noticed the other and this and
the original were developed in parallel.  The reporter of the original bug has
agreed to avoid any "duping duel" and allow his to be duped to this one
instead.)  My fault for foobaring the status from Reopened to Assigned.
*** Bug 156828 has been marked as a duplicate of this bug. ***
*** Bug 156850 has been marked as a duplicate of this bug. ***
I get this error as well. I'm running 2002061104 on a Win98 machine and a WinXP
machine. Both have Netscape 6.2 installed (Win98 has 6.2.1, not sure about the
other right now) continuing the pattern others mentioned. I don't remember
Netscape having problems before installing Mozilla, but now they both have the
same problems. I may try uninstalling one and seeing if the other works, and
then vice versa. 

The cat image flipping test from Comment #54 showed both images (so it requested
the image twice), no error. Other tests on this and duplicate bugs come up with
supposed errors in images, not always loading images in pages, etc. Changing
cache settings has not seemed to help, but clearing cache will usually work for
most pages, and forcing refresh works sometimes. Someone mentioned CSS problems
similar to the image problems, and I've noticed that as well: CSS doesn't always
load properly... you know there's a problem when Mozilla can't display
mozilla.org properly (no CSS + no images sometimes, CSS but no images sometimes,
correctly the other 66% of the time) 
*** Bug 158085 has been marked as a duplicate of this bug. ***
*** Bug 158161 has been marked as a duplicate of this bug. ***
Note: (I'm currently using 2002072204 trunk / Windows XP)  This bug is
preventing me from seeing the following bug 150317 attachment:

http://bugzilla.mozilla.org/attachment.cgi?id=86980&action=view

In order to view this image I had to use IE. (How's that for irony.)  Even a
Shift-Reload doesn't work on this one.
Jason: that image is really corrupt :
libpng error: Too much data in IDAT chunks
LoadImage is called in frame 3, and LoadImageWithChannel is called in frame 27
just before the call to StartLayout.  i don't know why LoadImage is being
called again, but perhaps someone more familiar with the way layout works would
know.
i spoke to waterson a bit about this one and it seems that layout wasn't
designed with this situation in mind.  initial frame construction is meant to
fire off image loads.  therefore, it seems like we need to add some kind of flag
to indicate that _the_ image is already loading or something like that.

-> layout
Assignee: darin → attinasi
Component: Networking: HTTP → Layout
QA Contact: tever → petersen
-> McCluskey
Assignee: attinasi → kmcclusk
*** Bug 152931 has been marked as a duplicate of this bug. ***
After I installed the Mozilla 1.1b this proplem appeared also on Netscape 6.2.3
and 7.0 pr1. After I cleared the disk cache (the same directory for all these
programs) the problem didn't occur anymore on 6.2.3 or 7.0. 
I had Netscape 6.2.1 already installed on my XP system. Installed Mozilla 1.0...
Problems began when I opened my server (running IIS) in NS6 when I had it opened
already in Mozilla. From that point in BOTH Mozilla and NS6 no images nor CSS's
would load for the whole domain, even if the sub domain is located on another
physical server. 

Clearing the cache worked. I checked the path to the Mozilla cache folder, which
is a Mozilla folder (so, not shared with NS6, afaik).

(The site does have a favicon.ico btw)
Addition to comment #104: It just happened to me while posting the bug. I
clicked "Back" several times in Mozilla (to go back to this page after I
submitted), until I noticed that the pages all were blank. Since that moment,
the images for bugzilla won't load anymore. No NS6 loaded at this time.

The contents of the blnak pages was: 
<html><body></body></html>

Which is exactly the same contents of CSS's that i tried to load when the
problem was active.
*** Bug 162524 has been marked as a duplicate of this bug. ***
*** Bug 162521 has been marked as a duplicate of this bug. ***
*** Bug 163508 has been marked as a duplicate of this bug. ***
*** Bug 157898 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
My experience of this bug is slightly different to that described so far in the
comments so I thought I'd add this. I think this might help cut through what's a
cache issue and what's not; it also adds the new information that the
double-loading behaviour can depend on whether you view the image "on it's own"
or within an HTML page.

I have a CGI-generated PNG image, http://www.srcf.ucam.org/~saw27/mozilla-test.cgi
The image contains a number which increments every time the script is run.

If I enter this URL directly to view the image "on its own", the image is
erroneously fetched and displayed twice (e.g. you see the number "6", rapidly
replaced by "7"). If I press reload or shift-reload, it displays the image two
more times ("8" followed by "9"). The setting of 'compare this page to the page
on the network' in preferences doesn't make any difference, presumably because
it's not cached at all because it's CGI.

However, contrary to the behaviour I would expect if comment #60 is right, if I
view the image from within an HTML page, such as
http://www.srcf.ucam.org/~saw27/mozilla-test.html , the double-loading behaviour
does not occur when you load/refresh the HTML page.

I'm using 2002060700 on linux, but I get the same behaviour in w2k.

to comment #110 i'd like to add something that's a little bit surprising to me...

he's right. only the image-only version loads twice here (win2k, cache: compare
every time, build 20020728). not the version within the html-page.

but i recognized that reloading the page displays the frist, then the second
image. but hitting shift-reload onlys displays the second one. reproducible
every time. it don't think that rendering speed depends on reload and
shift-reload, does it? perhaps that's another piece of the puzzle, don't know.
just wanted you to know 'bout that.


this bug isn't fixed in mozilla 1.1 beta! whats about the target milestone?
*** Bug 164397 has been marked as a duplicate of this bug. ***
The bug is still here in Mozilla 1.1.

*** Bug 163842 has been marked as a duplicate of this bug. ***
*** Bug 166075 has been marked as a duplicate of this bug. ***
*** Bug 167099 has been marked as a duplicate of this bug. ***
nsbeta1+.
Keywords: nsbeta1 → nsbeta1+
Target Milestone: mozilla1.1beta → mozilla1.2beta
*** Bug 167066 has been marked as a duplicate of this bug. ***
Shouldn't this be sent to the Necko folk? (Do we know _why_ we are fetching the
images twice?)
Whiteboard: [Hixie-P3]
content/html/document/src/nsImageDocument.cpp line 74f:
// 1. hookup the original stream to the image library directly so that we
//    don't have to load the image twice.

so apparently this _is_ known :)
hixie: see comment #99 ... layout is requesting the images twice.  imagelib and
necko are simply following layout's request.
*** Bug 169939 has been marked as a duplicate of this bug. ***
*** Bug 170943 has been marked as a duplicate of this bug. ***
*** Bug 173873 has been marked as a duplicate of this bug. ***
*** Bug 174881 has been marked as a duplicate of this bug. ***
QA Contact: petersen → praveenqa
tested on linux 2002093010
u may not get the bug repeatedly, clearing the cache helps..
Keywords: testcase
"You don't have permission to access /~erik/testcase/images/mozilla2.gif on this
server."

File permissions on the server need to be fixed.
*** Bug 171289 has been marked as a duplicate of this bug. ***
*** Bug 177095 has been marked as a duplicate of this bug. ***
*** Bug 143566 has been marked as a duplicate of this bug. ***
*** Bug 163956 has been marked as a duplicate of this bug. ***
doing a little investigation.

with an optimized, windows, trunk build I can reproduce the problem with:
http://bugzilla.mozilla.org/attachment.cgi?id=83697&action=view
(thanks callion)

I first get the broken image icon, replaced with:

The image “http://bugzilla.mozilla.org/attachment.cgi?id=83697&action=view”
cannot be displayed, because it contains errors.

note, on IE, I just see the text:  "904.44"  (Is that correct?  not sure yet)

I'll continue to investigate...
This bug also affects the downloading of attachments in Hotmail when using
Mozilla and other Gecko based browsers. Adding top100 and topembed to get some
loving on this bug.
Keywords: top100, topembed
With NS 7.0 RTM, I can reproduce the *original* problem with ease.  (I haven't 
tried 7.01 [Blackbird] yet.)

But I was having problems reproducing the *original* problem with the trunk.

The *original* problem appears to be fixed on the trunk.  But I don't want to 
say it's fixed until we find the checkin that made it go away.  (It might just 
be some unintented side effect of another change, that might be undone.)

If I can figure out what fixed it, it would be a good thing for the 1.0x branch.

Chris (caillon@returnzero.com, formerly caillon@netscape.com) and I talked 
tonight, and we had some ideas about the problem, if it comes back.

short summary:

1) in imgLoader::LoadImage(), we check the image cache for the image, and we 
find it (in the cases we are talking about)
2) since we can tell that it is being loaded (request->mLoading) we might be 
able to use that info to decide when to merge requests.  (I'm new to this code, 
so forgive my ignorance here.)

Note, I saw a lot of chrome urls (like for btn1.gif, the toolbar button image 
map).  It might be that there is a performance optimization we could make, 
using the mLoading boolean.

Also, there are still some related problems on the trunk.  

For example, if you do <img src="http://foo.com/bar.gif"> and bar.gif is a bad 
image, get the image icon while it loads, and then it "goes away" when the load 
is complete. (replaced with nothing, and this behaviour differs from what IE 
does.)

I am able to reproduce the hotmail.com problem on the trunk, which appears to 
be something slightly different.  (thanks to bclary for the help).

I'm working on that problem now.

taking from kevin (at least for now).
Assignee: kmcclusk → sspitzer
as mentioned previously, in imgLoader::LoadImage()

after we ask the imgCache for the uri, we frequently get requests that are 
loading.  (request->mLoading is PR_TRUE).

In addition to chrome:// urls, I see this with some images on webpages:
 
XXX loading(1) http://207.68.162.24/menu0.off.off.separator.gif
XXX loading(1) http://207.68.162.24/spacer.gif
XXX loading(1) http://207.68.162.24/spacer.gif
XXX loading(1) http://207.68.162.24/spacer.gif
XXX loading(1) http://207.68.162.24/spacer.gif
XXX loading(1) http://207.68.162.24/spacer.gif
XXX loading(1) http://207.68.162.24/spacer.gif
XXX loading(1) http://207.68.162.24/mini.bullet.gif
XXX loading(1) http://207.68.162.24/mini.bullet.gif
XXX loading(1) http://207.68.162.24/mini.bullet.gif
XXX loading(1) http://207.68.162.24/mini.bullet.gif
XXX loading(1) http://207.68.162.24/mini.bullet.gif
XXX loading(1) http://207.68.162.24/mini.bullet.gif
XXX loading(1) http://207.68.162.24/spacer.gif
XXX loading(1) http://207.68.162.24/menu0.off.bg.gif
XXX loading(1) http://207.68.162.24/menu0.off.bg.gif
XXX loading(1) http://207.68.162.24/menu0.end.bg.gif
XXX loading(1) http://207.68.162.24/menu0.end.bg.gif
XXX loading(1) http://207.68.162.24/f.s.gif
XXX loading(1) http://207.68.162.24/f.s.gif

about the hotmail problem, we are getting to imgRequest::OnStopRequest() with 
an error status.  debugging that now...
Status: NEW → ASSIGNED
Target Milestone: mozilla1.2beta → mozilla1.3alpha
why is the target milestone additionaly changed to a higher major version? how 
often will this bug delayed? 2.0? i hate this! fix it NOW - for 1.2 final! we 
wait enought time!
Marc - comments like that aren't very productive and don't help in any way.
> comments like that aren't very productive and don't help in any way

BTW: As far as I can tell this bug *IS* fixed. (And Marc's wait is effectively
over.)  At least, none of the test cases seem to be producing the error with the
latest trunk build for me any more.  (See comment 49.)  As per comment 135, the
bug is only open at this point because we can't determine what was checked in
that fixed things.
jasonb@dante.com:  the hotmail issue is still valid, and reproducable.
Agreed.  But the main point of this bug, the original reason it was filed, has
been "fixed" (somehow).  (I was mainly addressing Marc's comment about continual
delays.)  Sorry for the noise.
i'm not interrested in disscussions about - if something is productive or not. 
this bug need to be fixed quick - and not in months/years. about 140 comments 
are realy enough - i think so - to set up this bug to P1 version 1.1 *g*! i've 
realy got problems with this bug and i'm not interrested in making my 
customers telling - this is a netscape/mozilla bug. if you have a 1x1 pixel 
gif counting webpage hits and this will produce 2 hits - but this is real 1 
hit and you pay for pageviews this bug cost real money!
per the hotmail problem, the imgRequest:OnStopRequest() is being called with a
error.  (see the last argument, 2152988678, that's a failure code)

imgRequest::OnStopRequest(imgRequest * const 0x04f37148, nsIRequest *
0x0519ae68, nsISupports * 0x00000000, unsigned int 2152988678) line 651
ProxyListener::OnStopRequest(ProxyListener * const 0x04dc3830, nsIRequest *
0x0519ae68, nsISupports * 0x00000000, unsigned int 2152988678) line 875
nsStreamListenerTee::OnStopRequest(nsStreamListenerTee * const 0x03d6cf20,
nsIRequest * 0x0519ae68, nsISupports * 0x00000000, unsigned int 2152988678) line 66
nsHttpChannel::OnStopRequest(nsHttpChannel * const 0x0519ae6c, nsIRequest *
0x049db3ec, nsISupports * 0x00000000, unsigned int 2152988678) line 3008
nsOnStopRequestEvent::HandleEvent() line 213
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x04d1792c) line 116
PL_HandleEvent(PLEvent * 0x04d1792c) line 644 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x012672a0) line 574 + 9 bytes
nsEventQueueImpl::ProcessPendingEvents(nsEventQueueImpl * const 0x01269fc0) line
388 + 12 bytes
nsWindow::DispatchPendingEvents() line 3661
nsWindow::ProcessMessage(unsigned int 512, unsigned int 0, long 27787913, long *
0x0012fc48) line 4004
nsWindow::WindowProc(HWND__ * 0x00050234, unsigned int 512, unsigned int 0, long
27787913) line 1338 + 27 bytes
USER32! 77e11b60()
USER32! 77e11cca()
USER32! 77e11ddf()
nsAppShellService::Run(nsAppShellService * const 0x01860e98) line 472
main1(int 2, char * * 0x00277ba0, nsISupports * 0x00277c38) line 1541 + 32 bytes
main(int 2, char * * 0x00277ba0) line 1902 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e8d326()

it looks like we are canceling it due to a http redirect.

nsHttpTransaction::Cancel(nsHttpTransaction * const 0x050b7704, unsigned int
2152398851) line 787
nsHttpChannel::ProcessRedirection(unsigned int 302) line 1656
nsHttpChannel::ProcessResponse() line 623 + 12 bytes
nsHttpChannel::OnStartRequest(nsHttpChannel * const 0x04fcac54, nsIRequest *
0x050b7704, nsISupports * 0x00000000) line 2923 + 11 bytes
nsOnStartRequestEvent::HandleEvent() line 161 + 53 bytes
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x05041864) line 116
PL_HandleEvent(PLEvent * 0x05041864) line 644 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x012672a0) line 574 + 9 bytes
nsEventQueueImpl::ProcessPendingEvents(nsEventQueueImpl * const 0x01269fc0) line
388 + 12 bytes
nsWindow::DispatchPendingEvents() line 3661
nsWindow::ProcessMessage(unsigned int 512, unsigned int 0, long 327836, long *
0x0012fc48) line 4004
nsWindow::WindowProc(HWND__ * 0x00160336, unsigned int 512, unsigned int 0, long
327836) line 1338 + 27 bytes
USER32! 77e11b60()
USER32! 77e11cca()
USER32! 77e11ddf()
nsAppShellService::Run(nsAppShellService * const 0x01860e98) line 472
main1(int 2, char * * 0x00277ba0, nsISupports * 0x00277c38) line 1541 + 32 bytes
main(int 2, char * * 0x00277ba0) line 1902 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e8d326()

I'll talk to darin about this, see what he thinks.
about http://bugzilla.mozilla.org/show_bug.cgi?id=121084#c99

darin explained to me how in ImageListener::OnStartRequest(), we call
LoadImageWithChannel(), and then we call StartLayout() which will call LoadImage()

he also explained a possible, quick hack for this issue, and then he discussed
what the real problem is.

instead of me summarizing the real problem with layout, and him correcting me,
darin said he update the bug with his findings.



> he also explained a possible, quick hack for this issue

I'm trying it out now.

i've put together a simplified testcase for the hotmail-specific problem here:

  http://unagi.mcom.com/bugs/bug_121084/test.html

the hotmail problem is in a nutshell caused by Mozilla sending the wrong Referer
header when requesting the image attachment from the hotmail servers.  the wrong
Referer is sent when "loading a frame results in a redirect to a image that is
not cachable."

when a frame load is redirected, the document URL is updated to match the new
URL.  however, because the redirect results in an image, layout reloads the
image as an inline image, using a dummy HTML document as the container (because
it isn't smart enough to deal directly with image documents).  as a result
imagelib is asked to load the image a second time, and since the image is not
cachable, imagelib must ask necko for the image, and necko must ask the server.
 imagelib always uses the document's URL as the HTTP Referer (and that is always
correct for inline images, but not at all correct in this case).

the server is picky about the Referer sent, and if it is not the one expected it
returns a text/html document (presumably some sort of error page).  imageljb
bails on the HTML content, and the user sees an error generated from imagelib.

so, the hotmail problem is very much related to the original bug report, though
the original bug report appears to have been resolved (though that is just an
apparition).  the fix for bug 93015 (from rpotts) is what makes this bug seem
mostly fixed.  imagelib used to have the problem that it would not send a
Referer on "reload" network requests.  Rick fixed that particular problem, but
imagelib/layout still has the problem that it is requesting image documents twice.

so, the real solution to this bug is to fix layout to not require a second image
load.  i suspect that will be tricky to accomplish.  a hack solution (the one
seth mentioned) is to set the VALIDATE_NEVER load flag on the load group after
loading an image document but before reloading it as an inline image (probably
inside ImageListener::OnStartRequest).  doing so should cause the second load to
be loaded out of the cache (despite the fact that the server said the image
should not be taken from the browser's cache), avoiding the Referer problem
altogether.
i should add that "the image not being cachable" is roughly equivalent to the
user having selected the "validate everytime i view the page" cache preference;
hence, the summary of this bug report.
What does this have ot do with redirects, though? Layout knows that a redirect
happens, but why does it need to do anything to the document in that case? IS
the case you mentioned iwth the image document only because the image is in a
<frame> rather than an <img>?

If a page redirects a->b, do we still send a's referrer when requesting b? Why
can't the same situation be used here?

bbaetz:

yes, the problem is caused by the image being loaded into a frame.  see comment
#100.  LoadImageWithChannel is called from ImageListener::OnStartRequest, and
after LoadImageWithChannel returns, StartLayout is called, which eventually
calls LoadImage to load the very same URL as an inline!  (see the stack trace.)

the redirect is critical because it causes the document's URL to change such
that when the image is reloaded as an inline image, its Referer is now equal to
its URL, which makes hotmail very unhappy!
> If a page redirects a->b, do we still send a's referrer when requesting b? Why
> can't the same situation be used here?

yes, we send a's referrer when requesting b.  however, when b is requested as an
inline image, we send the document's URL as the referrer, which in this case is b.  

the problem is caused by layout forcing image documents to reload as inline content.
Can layout's dummy document do

SetDocumentURI(GetOrigianalURI())

if its an image (by whoever creats the dummy document??) ? Images don't load
documents (well, until we have SVG support, but that won't be using an
imagedocument anyway, I'd imagine), so theres no problem with the referer being
wrong, is there? Or is that not possible?

Are tehre any wierd js/dom crossdomain exploits that would open up?
this patch (not planning on checking this in) fixes the problem, as darin
predicted.
> Can layout's dummy document do
> 
> SetDocumentURI(GetOrigianalURI())

i don't think this would help any.  the original URL for the frame is still the
wrong URL (in fact, i think changing the document URL in this way would have no
effect).  consider the hotmail example.  we need to send the frameset URL as the
referrer (as we do the first time the image is requested after the redirect). 
but, since the second load is treated like an inline load, we use the document's
URL as the referrer.

here's the sequence of events (to summarize things):

  C: GET http://foo.com/frameset.html
  S: 200 OK

page contains a frameset.  suppose one of the frames will result in an image
instead of a HTML document.  let's follow the href "/frame1.cgi"

empty document is created w/ http://foo.com/frame1.cgi as the URL.

  C: GET http://foo.com/frame1.cgi
     Referer: http://foo.com/frameset.html
  S: 302 Redirect
     Location: http://foo.com/frame2.cgi

http://foo.com/frame2.cgi becomes the new document URL.  we still don't know
that this will be an image.

  C: GET http://foo.com/frame2.cgi
     Referer: http://foo.com/frameset.html
  S: 200 OK
     Content-Type: image/gif
     <image data>

everything is cool up to this point, but...

now layout does its thing, and imagelib is given a new request for the image,
this time using LoadImage.

  C: GET http://foo.com/frame1.cgi
     Referer: http://foo.com/frame1.cgi
  S: 404 You Suck

server got an unexpected Referer.
So is there any way of keeping a pointer to the original image about when
creating our fake document? Then just pointing the new <img> (note: eventually
this will change to an <object>) to this existing pointer?

Or should the solution be to make gecko "know" how to render frames that are
image/*, by taking the image and wrapping it in a fake document? (i.e. moving
where we create the fake document).
>Or should the solution be to make gecko "know" how to render frames that are
>image/*, by taking the image and wrapping it in a fake document? (i.e. moving
>where we create the fake document).

from my conversations with darin (and his conversation with waterson, see
http://bugzilla.mozilla.org/show_bug.cgi?id=121084#c100), I think this is what
they think the right solution is.

from my conversations with darin, it sounds like layout doesn't properly handle
top level images properly.  (think http://foo.com/bar/cheese.gif,  or go to a
web page, click on a thumbnail, or right click on an image to do view image)

I'll start up a thread about how to go about making this fix.
Please cc me on such a thread. Thanks!
sorry, distracted by other bugs / projects.

I tried to get some background (from waterson's overview,  see
http://www.mozilla.org/newlayout/doc/gecko-overview.htm)

http://www.mozilla.org/newlayout/doc/gecko-overview_files/Slide0018.gif lead me
to look into nsImageDocument and nsHTMLDocument.

looks like kipp knew about this problem from day 1.

see
http://lxr.mozilla.org/mozilla/source/content/html/document/src/nsImageDocument.cpp#72


 72 // XXX TODO:
 73 
 74 // 1. hookup the original stream to the image library directly so that we
 75 //    don't have to load the image twice.

I'll start looking into that.
Marking Topembed+ as part of topembed triage
Keywords: topembed → topembed+
sorry for the delay.

I've been debugging on and off, trying to figure this one out, trying to come 
up with a cleaner solution than darin's suggested hack.

to restate the problem:

we start the http request, and determine that we have an image
so we create the synthentic image document with the img tag.

when we process the image frame for the img tag, we'll create a second http 
request for the image.

hixie suggested something along the lines of keeping the original image around, 
and then using it, instead of making a second request.

this is basically what darin's suggested hack does (see 
http://bugzilla.mozilla.org/attachment.cgi?id=105915&action=view).

it uses the image cache to keep the original image around, so that when we 
process the image frame, we find the image in the cache, and don't request it 
again.

I've been trying to figure out if there is a way we could re-use the initial 
image request, but it didn't look like I could make the image frame re-use 
the "already started" request from the image document.  

and if I could, it would be more of a hack then just using the image cache for 
this purpose.

all roads keep leading me back to darin's hack.

imgLoader::LoadImageWithChannel() is only used from ImageDocument

perhaps we'd feel better about darin's suggest fix if we made it more explict 
that LoadingImageWithChannel() is going to override the load flags, in order to 
work around this special case (the document is an image).

if we do proceed with darin's fix, we should:

1)  make sure that no matter what the user's cache settings, we do this trick
    when doing LoadImageWithChannel()
2)  verify that the load flags we use make it act like backward / forward, and
    that we don't re-use the image in the cache whne we shouldn't.
3)  update the comment in the imgILoader interface to explain what 
LoadImageWithChannel() does to the channel's loadgroup's load flags.

comments?
Whatever we do has to work with an image returned from a POST.
... as well as images served up with a 'cache-control: no-store' header =)

oh, and what about the case in which the cache is not present?  (relying on the
cache for correctness is always wrong.)
just met with stuart (pavlov) and picked his brain.

he's suggested an alternative fix to try out.

in LoadImageWithChannel(), we aren't setting the loadId on the image request.

he thinks that if we do that, the subsequent call to LoadImage() will use the
image we are loading from LoadImageWithChannel(), assuming it has the same load
id.  (the load id is the pres context)

here's why it might work:

if they have the same load id, it makes our scenario the same as if we had a
html with two img tags, to the same image.

see http://bugzilla.mozilla.org/show_bug.cgi?id=108161 for why this load id
stuff exists.

I'll try this out, and report back.
just met with stuart (pavlov) and picked his brain.

he's suggested an alternative fix to try out.

in LoadImageWithChannel(), we aren't setting the loadId on the image request.

he thinks that if we do that, the subsequent call to LoadImage() will use the
image we are loading from LoadImageWithChannel(), assuming it has the same load
id.  (the load id is the pres context)

here's why it might work:

if they have the same load id, it makes our scenario the same as if we had a
html with two img tags, to the same image.

see http://bugzilla.mozilla.org/show_bug.cgi?id=108161 for why this load id
stuff exists.

I'll try this out, and report back.
Testcase for the POST case:
   http://www.hixie.ch/tests/evil/page-loading/mixed/001.cgi


Something I don't understand is why we render the image _twice_. For example, if
you visit the testcase above, click the button, and then immediately visit this
page:

data:text/html,%3Cimg%20src=%22http://www.hixie.ch/tests/evil/page-loading/mixed/001.cgi%22%20alt=%22Image%20not%20shown%22%3E

...then we first show the image (!) and then replace it with the alt text (!).
What's going on here?
no luck yet with stuart's approach.

we are already setting the request's load id when we init the request in
LoadImageWithChannel()

from http://lxr.mozilla.org/mozilla/source/modules/libpr0n/src/imgLoader.cpp#610

request->Init(channel, entry, activeQ.get(), aCX);

and aCX is non null.

when we get back to the LoadImage() call, we have the same aCX, but we fail to 
find the entry in the image cache. 

debugging that now.  not sure if it is done (and removed) or if we are dooming 
it.
I think I know why we aren't finding the image in the image cache, even though 
the load id is correct.

the top level image document is really something like:

http://207.68.162.250/cgi-bin/saferd?_lang=EN&hm___tg=http%3a%2f%2f207%2e68%
2e162%2e250%2fcgi%2dbin%2fgetmsg&hm___qs=curmbox%3dF000000001%26a%
3db78645b825c7e3e23d6165fcdc1ce4aa%26msg%3dMSG1037054674%2e46%26start%3d10351%
26len%3d4989%26mimepart...

that's what we call LoadImageWithChannel() with.

but, when we create the synthetic document in ImageDocument, we set the src tag 
of the image to be:


http://207.68.162.250/cgi-bin/getmsg?
curmbox=F000000001&a=b78645b825c7e3e23d6165fcdc1ce4aa&msg=MSG1037054674.46&start
=10351&len=4989&mimepart...

so since the uri is different, it doesn't matter that they have the same load 
id.

I'm looking into why the img src attribute in the synthetic document has 
changed.
I think my fix works for hixie's test too, but not 100% sure yet.
The more I think about this, the more I get the feeling that Layout itself
should just Know how to render images natively, so that when we try to render
them we don't have to jump through hoops at all.
> The more I think about this, the more I get the feeling that Layout itself
> should just Know how to render images natively, so that when we try to render
> them we don't have to jump through hoops at all.

do you mean it won't need the synthetic document at all (and it would just
create the image frame?)
Attachment #108172 - Flags: superreview?(darin)
Attachment #108172 - Flags: review?(pavlov)
> do you mean [Layout] won't need the synthetic document at all (and it would just
> create the image frame?)

Something like that. Or, it would create the document itself, simply wrapping
the handle to the image, without talking to Necko again.
Comment on attachment 108172 [details] [diff] [review]
cleaned up version of the patch (fixed an existing warning, too)

I think this is what I suggested, but layout/imglib/etc interaction hasn't been
somethign I've really looked at much.

I do think that hixie's idea is probably the best if we can pull it off -
theres probably lots of stuff which does need the document.
+nsImageDocument::CreateSyntheticDocument(const nsCAutoString &aSpec)

er no. use nsACString&, not nsCAutoString&, in fucntion arguments.
thanks christian.

from http://www.mozilla.org/projects/xpcom/string-guide.html

"Use the most abstract string class that you can. Usually this is: 
nsAString for function parameters"

new patch coming...
Attachment #108219 - Flags: superreview?(darin)
Attachment #108219 - Flags: review?(pavlov)
Comment on attachment 108172 [details] [diff] [review]
cleaned up version of the patch (fixed an existing warning, too)

obsolete
Attachment #108172 - Flags: superreview?(darin)
Attachment #108172 - Flags: superreview-
Attachment #108172 - Flags: review?(pavlov)
Attachment #108172 - Flags: review-
You guys are doing great work.  I am not contributing as I had first intended so
I am removing myself from the CC list.  
in addition to fixing the hotmail problem, this fix stops the double request.
(I verified looking at my web server's access logs)

bbaetz / hixie:  I think this approach is worth taking for 1.3 (assuming the 
reviewers agree). 

If we choose to fix how layout handles images, imagedocument would just go 
away, and this hack with it.

one question:  if we remove image document, and made layout handle images, 
would be unable to do the image tricks (like IE) that are hinted to in the code:

http://lxr.mozilla.org/mozilla/source/content/html/document/src/nsImageDocument.
cpp#77

 77 // 2. have a synthetic document url that we load that has patterns in it
 78 //    that we replace with the image url (so that we can customize the
 79 //    the presentation of the image): we could add script code to set the
 80 //    width/height to provide scale buttons, we could show the image
 81 //    attributes; etc.; should we have a seperate style sheet?

Comment on attachment 108219 [details] [diff] [review]
patch, use nsACString as function arg

seth: i'm curious to understand how this actually works.  the
original URL should be the URL before the redirect.  does this
mean that we are storing the image in the imgCache using the
orginial URL instead of the resulting URL from the redirect?
can you check the memory cache to see what URL is being used
as a cache key, and does this patch fix my testcase in comment
#146?
or does this just make it so that the Referer is the original URL instead of the
redirected URL?
ok, so actually i tested out the patch, and it does indeed use the wrong cache
key w/ imagelib.  using the testcase in comment #146, i get these URLs cached in
the disk cache by HTTP:

  http://unagi/cgi-bin/bug_121084.cgi
  -> contains the 302 redirect

  http://unagi/cgi-bin/bug_121084.cgi?foo
  -> contains the image data

in the memory cache, however, i see this entry for the image:

  http://unagi/cgi-bin/bug_121084.cgi

now, this is definitely the wrong URL.  it should use the URL with the "?foo" at
the end of it.

of course, the bug appears to be fixed; however, the fact that we are storing
the image under the wrong URL may lead to some subtle bug/regression.  perhaps
it is a good trade :-/
darin:

the fix "works" because both URLs (the one on the img tag and the one in the
image cache) are the same.

but are you saying they are both wrong, and they should both be using the
redirected url?
> one question:  if we remove image document, and made layout handle images, 
> would be unable to do the image tricks (like IE) that are hinted to in the 
> code:

I wouldn't remove the document, merely move its creation to the part of the code
that receives the original image, and stick the image into this new document,
without returning to Necko or the cache or the network at any point.


> bbaetz / hixie:  I think this approach is worth taking for 1.3 (assuming the 
> reviewers agree). 

I disagree. In the past, "temporary" solutions like this have had an unnerving
tendency to become permanent solutions lasting many years. For example:

   http://lxr.mozilla.org/seamonkey/search?string=xxx+temporary
Comment on attachment 108219 [details] [diff] [review]
patch, use nsACString as function arg

sr=darin

i think this patch solves a bigger problem then the one it creates.  i'd like
to see this land so the hotmail problem can be solved.

i've asked seth to file a new bug about the fact that imagelib uses the wrong
URL as its cache key.  (this problem will break sites: e.g., consider a site
that uses redirects to track hits on a large cacheable image.)

thanks seth!!
Attachment #108219 - Flags: superreview?(darin) → superreview+
Regarding the URL in the bug report ( see comment 54 ) my version
of Mozilla doesn't produce the bug.

The testcase for POST request displays flawlessly ( comment 164 )

Even Heidi Klum materializes now (although only on my monitor, 
not in my room :-)

Seems the bug has been fixed in the 1.2.1 Release!

I am running :
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130

PS:
The Attachment "shows an external link, bug showed up on linux"
links to an image that is not available any more. Thus I couldn't
check this testcase.

What a surprise!
I verified with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2;
MultiZilla v1.1.32 final) Gecko/20021130
The testcase at http://www.sharding.org/outgoing/temp/testim.html also works as
it should.
Who knows what fixed it?

talking last night to darin, I'm going to look into if it is possible to leave
image document alone, and fix what url we stick in the image cache for load image.
Anything which relies on the cache to fix this is broken by design and should
not be checked in.
daniel, wim: this bug has morphed somewhat (see comment #146).
So, *this* bug "Images requested twice when 'Compare the page in cache ...' set
to 'every time I view the page'" is solved then? (When? How?)
But there is at least one other bug being handled in this bugzilla-record.
Bugs don't morph, do they? Any other problem than "Images requested twice when
'Compare the page in cache ...' set to 'every time I view the page'" should be
handled in other BugZilla-records, shouldn't they?
If I'm not mistaking there should be created a new BugZilla-record for "Wrong
referer is sent when loading a frame results in a redirect to a image that is
not cachable" if there is not already a one.
It seems to me great work is being done on this other bug but that doesn't
justify its efforts being commented in the wrong record.
wim: please we don't need more noise is this bug ;-)

the original problem is caused by the fact that we hit the networking code twice
in order to load "these" images.  it so happened that in past versions of
mozilla, imagelib would not set a Referer header when issuing a reload request
(this was fixed by the patch in bug 93015).  without a Referer, some sites would
send back a 404 error in place of the image.  however, the real problem is that
layout is loading these images twice.  seth is working to fix the real problem.
 i don't see any reason to open a new bug at this point.
handing over to suresh. 

(I'm back on mailnews / apps full time.)

clearing target milestone, leaving it for him to decide.

hixie writes:  "Anything which relies on the cache to fix this is broken by
design and should not be checked in."

the last patch I attach does rely on the image cache, and on top of that, the
image cache has an existing problem that needs fixing, too.  (we store
redirected images with the wrong key) 

ping me (or darin, who knows what I know) for a brain dump on this bug.
Assignee: sspitzer → suresh
Status: ASSIGNED → NEW
Target Milestone: mozilla1.3alpha → ---
Comment on attachment 108219 [details] [diff] [review]
patch, use nsACString as function arg

removing my request.

I'll let suresh take it from here.
Attachment #108219 - Flags: review?(pavlov)
here's the brain dump:

1)  the last patch "fixes" it, by it horks uri to match what we incorrectly put
into the image cache (from the initial request).  (the existing code relies on
the image cache to handle top level image documents.)

2)  we should fix the key for the initial request.  I think this might be enough
to fix this bug too.)  I don't know if there is a bug on this issue.

3)  then, log a new bug to not rely on the image cache to handle top level image
documents.  (see hixie's comments in this bug report.)
-> jdunn.

I beleive jdunn is already looking into this bug.
Assignee: suresh → jdunn
Blocks: 178882
Swapping the "url" from http://animecity.nu/Mozilla/IMGTest/AlternatingImage.asp
to http://unagi.mcom.com/bugs/bug_121084/test.html

Since apparently the AlternatingImage.asp no long shows the problem
do to: "the fix for bug 93015 (from rpotts) is what makes this bug 
seem mostly fixed" 

Also see "Comment #146 From Darin Fisher 2002-11-11 17:12"
(and related comments) for info on what still needs to be fixed
Status: NEW → ASSIGNED
unagi is internal to mcom.com?  Because it's not reachable by the public.  It
would be helpful if a test case were not private...
jason, yes, all hosts inside .mcom.com are accesible from netscape only.
Comment on attachment 108219 [details] [diff] [review]
patch, use nsACString as function arg

Ok guys, I would like to go with THIS patch for this bug and try to get it into
1.3.  We have a SR... but need a r=  (of course not sure if someone objects to
this fix) 
thoughts?
Depends on: 89419
Just out of interest, what is it that this patch doesn't solve, which bypassing
the cache, as we should do on the long term, _does_ solve?
Whiteboard: [Hixie-P3] → [Hixie-P3] (py8ieh:202)
Setting target for 1.3final, if i can just get r= & approval
Target Milestone: --- → mozilla1.3final
*** Bug 127168 has been marked as a duplicate of this bug. ***
jdunn: Could you answer my question in comment 202 before checking this in? Cheers.
ian, sorry for the late reply.  Just getting ones
hands around this bug is touch.  I think Darin's
comments sum up the issue with the current suggested patch
see bug 121084#c183

jdunn: Darin's comment 183 doesn't seem to give any explicit bug that still
exists with the current patch. Can you explicitly give anything that this patch
doesn't solve, which bypassing the cache _does_ solve?
Flags: blocking1.4a?
*** Bug 197083 has been marked as a duplicate of this bug. ***
Ok, went through this bug every which way...
what we were doing is storing the originaluri for the
image cache key which messed us up when there was a
referrer, since that went in as the cache key and then
when we got the actual image, that uri wouldn't match
with what we had in the cache so we would display error.

NOTE: this testcase showed another bug, that when clicking
reload with a referred top level image, we don't actually
re-request the referrer, but instead go straight to the 
image.	So if the referrer changed what it was referring to
we would load the old image.
After talking with Darin we think that is covered by bug 68423 
(and I think bug 89419, and others, might be  a dup of that as well)
Attachment #108219 - Attachment is obsolete: true
I have a related problem, the image is displayed, though the alternate text is
the error message, even when viewing an image only.

This happens with every image I've found on the net so far.
That is no problem : That is expected (unless you mean a image in a html document)
I am providing a description of what we found along with explanation of
the patch.  I am requesting r= & sr= for this.
(THANKS darin for all your help)

So the specific testcase, test.html, is just a simple html document
--------------
    <html>
    <frameset rows="100, 200">
     <frame src="about:blank">
     <frame src="/cgi-bin/bug_121084.cgi">
    </frameset>
   </html>
----------
bug_121084.cgi just refer'd to bug_121084.cgy?foo which is a image/png
Following is the http requests
  HTTP GET /bugs/bug_121084/test.html
  HTTP/1.1 200 OK

  HTTP GET /cgi-bin/bug_121084.cgi 
     Referer: http://unagi/bugs/bug_121084/test.html     
  HTTP/1.1 302
     location: /cgi-bin/bug_121084.cgi?foo

  HTTP GET /cgi-bin/bug_121084.cgi?foo  
     Referer: http://unagi/bugs/bug_121084/test.html
  HTTP/1.1 200

  HTTP GET /cgi-bin/bug_121084.cgi?foo 
     Referer: http://unagi/cgi-bin/bug_121084.cgi?foo
  HTTP/1.1 403

This is wrong... it should be :
  HTTP GET /bugs/bug_121084/test.html
  HTTP/1.1 200 OK

  HTTP GET /cgi-bin/bug_121084.cgi
     Referer: http://unagi/bugs/bug_121084/test.html
  HTTP/1.1 302
     Location: /cgi-bin/bug_121084.cgi?foo
 
  HTTP GET /cgi-bin/bug_121084.cgi?foo
     Referer: http://unagi/bugs/bug_121084/test.html
  HTTP/1.1 200 OK

What was happening is that when imageLib was told that
we had an image (url /cgi-bin/bug_121084.cgi?foo) we
would set an image cache-hey using the OriginalURI 
(/cgi-bin/bug_121084.cgi) and not the actually URI
(/cgi-bin/bug_121084.cgi?foo).  So when the image was
decoded (and put in our cache) we would go to display
it, but the url's didn't match up so we would request
it again.

So by actually storing the image under the correct
url cacheKey, everybody is happy.

NOTE: this specific bug does show a 2nd problem (as I
mentioned) but it is a general referrer issue and not
specific to imageLib and is currently being tracked by
at least 2 bugs.

looking for r= & sr= and lets put this baby to rest
Whiteboard: [Hixie-P3] (py8ieh:202) → [Hixie-P3] (py8ieh:202), needs r=, needs sr=
Target Milestone: mozilla1.3final → mozilla1.4alpha
Comment on attachment 117111 [details] [diff] [review]
Use URI and not OriginalURI (which could be a referrer)

sr=darin

yup, this seems right to me.  please run it by pavlov to make sure he can't
think of any ways this might cause problems for other things.
Attachment #117111 - Flags: superreview+
Comment on attachment 117111 [details] [diff] [review]
Use URI and not OriginalURI (which could be a referrer)

actually i take it back.  there's a lot of problems with this and it doesn't
even guarantee that we use the right URI for the image lib cache entries.  i
had a lengthy discussion with stuart, and we agreed that this isn't the right
thing to do.

the crux of the issue is that the necko channel can change due to a redirect,
so when imagelib gets OnStartRequest the result of GetURI will not necessarily
be the same as it was when LoadImage created a channel.  so, we'd still be
storing the image data under the wrong URI.
Attachment #117111 - Flags: superreview+ → superreview-
Flags: blocking1.4a? → blocking1.4a-
Comment on attachment 117111 [details] [diff] [review]
Use URI and not OriginalURI (which could be a referrer)

r='ing.. it doesn't look like this will make anything worse, and if it does
thats what you get for using redirects!
Attachment #117111 - Flags: review+
Comment on attachment 117111 [details] [diff] [review]
Use URI and not OriginalURI (which could be a referrer)

yup, let's give this a try.  the new problems are no worse (almost no
different) and this seems to fix a number of bugs. 

sr=darin
Attachment #117111 - Flags: superreview- → superreview+
we want this in the 1.4 alpha build...

Checking in imgLoader.cpp;
/cvsroot/mozilla/modules/libpr0n/src/imgLoader.cpp,v  <--  imgLoader.cpp
new revision: 1.65; previous revision: 1.64
Depends on: 83774
I don´t know, if bug 199462 is a dupe of this one, but it is easily reproducable
with current builds. When automatic resizing is enabled, and an image which must
be resized is loaded, you get the errormessage "The image cannot ..." while
loading, until the image is loaded and displayed. Is the image loaded logically
twice because of resizing, maybe while doing first load to cache 2nd load is
read from cache? I´ll stop speculating, I don´t know or understand much of it.
On viewing http://bugzilla.mozilla.org/show_bug.cgi?id=121084 and the attachment
http://bugzilla.mozilla.org/attachment.cgi?id=118707&action=view which is an
image, I got the error "the image cannot..." the first time around, and the
mozilla died (2003032708 - submitted talkback). On restarting and visiting the
link a couple times, it does show the image, but once it's displayed and if you
keep on the page for a few seconds, you see it refreshing, being repainted.
Thought it would be due to this bug. If it is not, say so and I will post
another bug for that.
I also now crash every time after I get this message and reload
Blocks: 83774
No longer depends on: 83774
Blocks: 148896
Comment on attachment 119027 [details] [diff] [review]
oops, that had one small problem...

pav?  jst?  What do you think?
Attachment #119027 - Flags: superreview?(jst)
Attachment #119027 - Flags: review?(pavlov)
Oh, that patch happens to fix bug 34165 too.
Blocks: viewblocked
Been testing this all morning and the patch seems to do the trick.  I am
also compiling a list of other bugs that this patch and 89419 fixes.
Comment on attachment 119027 [details] [diff] [review]
oops, that had one small problem...

- In nsImageDocument::CreateSyntheticDocument():

+  // use SetHTMLAttribute so that the call will not trigger an image load; the
+  // actual load is handled from over in ImageListener::OnStartRequest
   NS_ConvertUTF8toUCS2 srcString(src);
-
-  image->SetAttr(kNameSpaceID_None, nsHTMLAtoms::src, srcString, PR_FALSE);
+  nsHTMLValue val(srcString);
+  image->SetHTMLAttribute(nsHTMLAtoms::src, val, PR_FALSE);

This seems kinda lame to me, I don't like the fact that you use
SetHTMLAttribute() here to prevent the image from noticing that the src
changed, nor do I like the fact that changing the src with SetHTMLAttribute()
doesn't make the image change the src... And to add to that, I don't like the
fact that we have an SetHTMLAttribute() method in nsIHTMLContent in the first
place...

How about just wrapping this in calls to
nsIImageLoadingContent::SetLoadingEnabled() true/false in stead, and prevent
the image element from starting an image load when the attribute changes?

Other than that, sr=jst
Attachment #119027 - Flags: superreview?(jst) → superreview+
Of course!  I should have thought of just setting loadingEnabled there...
Attachment #119027 - Flags: review?(pavlov) → review+
Comment on attachment 119027 [details] [diff] [review]
oops, that had one small problem...

Checked this in.  I can't figure out what would make this bug "fixed", though. 
Jim?  Darin?  What's left to do here?
I believe this bug is now fixed.  We took care of the problem and I have
gone through most (if not all) of the dups trying to make sure we got
all of the instances.  

The "only" thing left is (IMHO) covered by bug 89419 which I am 
working on.  That issue is, with this "unagi" testcase, if you click
on reload, we fail to check the redirect and instead just issue
HTTP GET's on "test.html" and on the final image (foo).

Unless someone thinks otherwise, I think we can mark this fixed.
(I will wait to see if there are any dissenters before doing so)
Target Milestone: mozilla1.4alpha → mozilla1.4beta
marking fixed... (thank you everyone!)
Status: ASSIGNED → RESOLVED
Closed: 22 years ago → 21 years ago
Resolution: --- → FIXED
V fixed
Status: RESOLVED → VERIFIED
*** Bug 148896 has been marked as a duplicate of this bug. ***
This error message can happen if the picture is encoded differently
than the filetype. For example, if you uploaded a jpeg which is
encoded as a psd file, then this error will occur.

This has been verified, I used gimp (you can use that or another image
conversion program like paint shop pro) to resave the image as a jpg
and the picture displayed in Mozilla.
No longer blocks: majorbugs
Regressions: 1889840
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: