Closed Bug 121084 (Heidi) Opened 23 years ago Closed 22 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: 23 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: 23 years ago → 22 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: