Bug 121084 (Heidi)

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"]

VERIFIED FIXED in mozilla1.4beta

Status

()

Core
Layout
P3
major
VERIFIED FIXED
16 years ago
12 years ago

People

(Reporter: Christopher Aillon (sabbatical, not receiving bugmail), Assigned: Jim Dunn)

Tracking

(6 keywords)

Trunk
mozilla1.4beta
perf, regression, relnote, testcase, top100, topembed+
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.4a -

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(4 attachments, 5 obsolete attachments)

9.60 KB, text/plain
Details
188 bytes, text/html
Details
556 bytes, patch
Stuart Parmenter
: review+
Darin Fisher
: superreview+
Details | Diff | Splinter Review
13.52 KB, patch
Stuart Parmenter
: review+
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
(warning.  above link may be offensive to some and not suitable for minors)

Updated

16 years ago
Target Milestone: --- → Future

Comment 3

16 years ago
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

Comment 5

15 years ago
Seen on WinXP 2002040303, setting OS/Plat All
OS: Linux → All
Hardware: PC → All

Comment 6

15 years ago
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)

Comment 8

15 years ago
*** Bug 134766 has been marked as a duplicate of this bug. ***
*** Bug 137805 has been marked as a duplicate of this bug. ***

Updated

15 years ago
Priority: -- → P3
Target Milestone: Future → mozilla1.1alpha

Comment 10

15 years ago
*** 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

Comment 12

15 years ago
*** Bug 141233 has been marked as a duplicate of this bug. ***

Comment 13

15 years ago
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.

Comment 14

15 years ago
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.
Keywords: nsbeta1- → nsbeta1, regression

Comment 15

15 years ago
*** Bug 142944 has been marked as a duplicate of this bug. ***

Comment 16

15 years ago
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

Comment 17

15 years ago
*** Bug 141106 has been marked as a duplicate of this bug. ***
Blocks: 143488

Comment 18

15 years ago
*** Bug 143884 has been marked as a duplicate of this bug. ***

Comment 19

15 years ago
*** Bug 143906 has been marked as a duplicate of this bug. ***

Comment 20

15 years ago
*** Bug 144277 has been marked as a duplicate of this bug. ***

Comment 21

15 years ago
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.

Comment 22

15 years ago
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.

Comment 23

15 years ago
*** Bug 144529 has been marked as a duplicate of this bug. ***

Comment 24

15 years ago
*** Bug 144519 has been marked as a duplicate of this bug. ***

Comment 25

15 years ago
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.

Comment 26

15 years ago
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

Comment 28

15 years ago
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. ***

Comment 30

15 years ago
*** Bug 145993 has been marked as a duplicate of this bug. ***
*** Bug 146114 has been marked as a duplicate of this bug. ***

Comment 32

15 years ago
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. ***

Comment 34

15 years ago
*** Bug 123850 has been marked as a duplicate of this bug. ***

Comment 35

15 years ago
*** Bug 145868 has been marked as a duplicate of this bug. ***

Comment 36

15 years ago
*** Bug 147450 has been marked as a duplicate of this bug. ***

Comment 37

15 years ago
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).

Comment 38

15 years ago
*** Bug 147771 has been marked as a duplicate of this bug. ***

Comment 39

15 years ago
*** Bug 147879 has been marked as a duplicate of this bug. ***

Comment 40

15 years ago
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. ***

Comment 42

15 years ago
*** Bug 147674 has been marked as a duplicate of this bug. ***

Comment 43

15 years ago
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)

Comment 44

15 years ago
*** Bug 135597 has been marked as a duplicate of this bug. ***

Comment 45

15 years ago
*** Bug 140684 has been marked as a duplicate of this bug. ***
*** Bug 149688 has been marked as a duplicate of this bug. ***

Comment 47

15 years ago
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

Comment 49

15 years ago
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. ***

Comment 52

15 years ago
*** Bug 150534 has been marked as a duplicate of this bug. ***

Comment 53

15 years ago
*** Bug 139430 has been marked as a duplicate of this bug. ***

Comment 54

15 years ago
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 55

15 years ago
Comment 54 "requesting image twice" problem confirmed: build 2002061304/win2000.

Comment 56

15 years ago
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.

Updated

15 years ago
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"]

Comment 57

15 years ago
Miha: Either image is supposed to be displayed.. just not both.
Alias: Heidi

Comment 58

15 years ago
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

Comment 61

15 years ago
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.

Comment 62

15 years ago
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 ;)

Comment 63

15 years ago
1.1alpha is no more -> 1.1beta
Target Milestone: mozilla1.1alpha → mozilla1.1beta
*** Bug 152933 has been marked as a duplicate of this bug. ***

Comment 65

15 years ago
I went to preferences/advanced and clean the disk cache. Everything came
afterwards normal. Anyhow, still a bug

Comment 66

15 years ago
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...

Comment 67

15 years ago
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.

Comment 68

15 years ago
*** Bug 150689 has been marked as a duplicate of this bug. ***
Blocks: 153633
*** Bug 153105 has been marked as a duplicate of this bug. ***

Comment 70

15 years ago
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...

Comment 71

15 years ago
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.

Comment 72

15 years ago
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...

Comment 73

15 years ago
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.

Comment 74

15 years ago
I see this problem on my Linux box too, but i don't have Netscape installed. 

Comment 75

15 years ago
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!

Comment 76

15 years ago
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.

Updated

15 years ago
Blocks: 151432

Comment 77

15 years ago
*** Bug 156117 has been marked as a duplicate of this bug. ***

Comment 78

15 years ago
*** Bug 156310 has been marked as a duplicate of this bug. ***
*** Bug 156148 has been marked as a duplicate of this bug. ***

Comment 80

15 years ago

*** This bug has been marked as a duplicate of 98890 ***
Status: NEW → RESOLVED
Last Resolved: 15 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. ***

Comment 83

15 years ago
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.

Comment 84

15 years ago
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.

Updated

15 years ago
Status: REOPENED → ASSIGNED

Comment 85

15 years ago
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"

Comment 86

15 years ago
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.

Comment 87

15 years ago
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'?

Comment 88

15 years ago
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

Comment 89

15 years ago
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

Comment 91

15 years ago
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.

Comment 92

15 years ago
*** Bug 156828 has been marked as a duplicate of this bug. ***

Comment 93

15 years ago
*** Bug 156850 has been marked as a duplicate of this bug. ***

Comment 94

15 years ago
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) 

Comment 95

15 years ago
*** Bug 158085 has been marked as a duplicate of this bug. ***

Comment 96

15 years ago
*** Bug 158161 has been marked as a duplicate of this bug. ***

Comment 97

15 years ago
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

Comment 99

15 years ago
Created attachment 92586 [details]
stack trace showing LoadImage being called after LoadImageWithChannel

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.

Comment 100

15 years ago
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

Comment 101

15 years ago
-> McCluskey
Assignee: attinasi → kmcclusk

Comment 102

15 years ago
*** Bug 152931 has been marked as a duplicate of this bug. ***

Comment 103

15 years ago
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. 

Comment 104

15 years ago
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)

Comment 105

15 years ago
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.

Comment 106

15 years ago
*** Bug 162524 has been marked as a duplicate of this bug. ***

Comment 107

15 years ago
*** Bug 162521 has been marked as a duplicate of this bug. ***

Comment 108

15 years ago
*** Bug 163508 has been marked as a duplicate of this bug. ***

Comment 109

15 years ago
*** Bug 157898 has been marked as a duplicate of this bug. ***

Updated

15 years ago
Blocks: 163993

Comment 110

15 years ago
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.

Comment 111

15 years ago
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.

Comment 112

15 years ago
this bug isn't fixed in mozilla 1.1 beta! whats about the target milestone?

Comment 113

15 years ago
*** Bug 164397 has been marked as a duplicate of this bug. ***

Comment 114

15 years ago
The bug is still here in Mozilla 1.1.

Comment 115

15 years ago
*** Bug 163842 has been marked as a duplicate of this bug. ***

Comment 116

15 years ago
*** 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 :)

Comment 122

15 years ago
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. ***

Comment 124

15 years ago
*** Bug 170943 has been marked as a duplicate of this bug. ***
*** Bug 173873 has been marked as a duplicate of this bug. ***

Comment 126

15 years ago
*** Bug 174881 has been marked as a duplicate of this bug. ***

Updated

15 years ago
QA Contact: petersen → praveenqa

Comment 127

15 years ago
Created attachment 103921 [details]
shows an external link, bug showed up on linux 

tested on linux 2002093010
u may not get the bug repeatedly, clearing the cache helps..

Updated

15 years ago
Keywords: testcase

Comment 128

15 years ago
"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. ***

Comment 131

15 years ago
*** Bug 143566 has been marked as a duplicate of this bug. ***

Comment 132

15 years ago
*** 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...

Comment 134

15 years ago
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

Comment 137

15 years ago
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!

Comment 138

15 years ago
Marc - comments like that aren't very productive and don't help in any way.

Comment 139

15 years ago
> 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.

Comment 141

15 years ago
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.

Comment 142

15 years ago
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.

Comment 146

15 years ago
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.

Comment 147

15 years ago
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?

Comment 149

15 years ago
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!

Comment 150

15 years ago
> 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?
Created attachment 105915 [details] [diff] [review]
HACK, proof of concept hack (suggested by darin)

this patch (not planning on checking this in) fixes the problem, as darin
predicted.

Comment 153

15 years ago
> 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.

Comment 158

15 years ago
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.

Comment 161

15 years ago
... 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.
Created attachment 108161 [details] [diff] [review]
patch, not pretty, but make sense (and works).  need some cleanup
Attachment #105915 - Attachment is obsolete: true
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.
Created attachment 108172 [details] [diff] [review]
cleaned up version of the patch (fixed an existing warning, too)
Attachment #108161 - Attachment is obsolete: true
> 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)
is my fix what bbaetz suggested back in
http://bugzilla.mozilla.org/show_bug.cgi?id=121084#c151?
> 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...
Created attachment 108219 [details] [diff] [review]
patch, use nsACString as function arg
Attachment #108172 - Attachment is obsolete: true
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-

Comment 179

15 years ago
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 181

15 years ago
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?

Comment 182

15 years ago
or does this just make it so that the Referer is the original URL instead of the
redirected URL?

Comment 183

15 years ago
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 186

15 years ago
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.

Comment 188

15 years ago
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.

Comment 191

15 years ago
daniel, wim: this bug has morphed somewhat (see comment #146).

Comment 192

15 years ago
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.

Comment 193

15 years ago
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.)

Comment 197

15 years ago
-> jdunn.

I beleive jdunn is already looking into this bug.
Assignee: suresh → jdunn

Updated

15 years ago
Blocks: 178882
(Assignee)

Comment 198

15 years ago
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
(Assignee)

Updated

15 years ago

Comment 199

15 years ago
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.
(Assignee)

Comment 201

15 years ago
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?

Updated

15 years ago
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)
(Assignee)

Comment 203

15 years ago
Setting target for 1.3final, if i can just get r= & approval
Target Milestone: --- → mozilla1.3final
(Assignee)

Comment 204

15 years ago
*** 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.
(Assignee)

Comment 206

15 years ago
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?

Updated

15 years ago
Flags: blocking1.4a?
*** Bug 197083 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 209

15 years ago
Created attachment 117111 [details] [diff] [review]
Use URI and not OriginalURI (which could be a referrer)

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

Comment 210

15 years ago
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)
(Assignee)

Comment 212

15 years ago
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 213

15 years ago
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 214

15 years ago
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-

Updated

15 years ago
Flags: blocking1.4a? → blocking1.4a-

Comment 215

14 years ago
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 216

14 years ago
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+

Comment 217

14 years ago
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
(Assignee)

Updated

14 years ago
Depends on: 83774

Comment 218

14 years ago
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.

Comment 219

14 years ago
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.

Comment 220

14 years ago
I also now crash every time after I get this message and reload
Blocks: 83774
No longer depends on: 83774
Blocks: 148896
Created attachment 119023 [details] [diff] [review]
patch to sort out some issues with LoadImageWithChannel being called too late
Created attachment 119027 [details] [diff] [review]
oops, that had one small problem...
Attachment #119023 - Attachment is obsolete: true
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: 34165
(Assignee)

Comment 225

14 years ago
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...

Updated

14 years ago
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?
(Assignee)

Comment 229

14 years ago
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
(Assignee)

Comment 230

14 years ago
marking fixed... (thank you everyone!)
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago14 years ago
Resolution: --- → FIXED

Comment 231

14 years ago
V fixed
Status: RESOLVED → VERIFIED

Comment 232

14 years ago
*** Bug 148896 has been marked as a duplicate of this bug. ***

Comment 233

13 years ago
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.

Updated

12 years ago
No longer blocks: 163993
You need to log in before you can comment on or make changes to this bug.