79.38 KB, image/png
603 bytes, patch
|Details | Diff | Splinter Review|
51.70 KB, image/png
106.71 KB, image/png
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020320 BuildID: 20020321 On some pages, when I first visit it, the page is loaded correctly. Then I click on some link and then Back button, the page is loaded, but some images are missing (looking like there is a broken link to images). When I hit "RELOAD", the page is loaded correctly again. I can see this on http://www.ihned.cz/ for example. Visit it, click on some link on it and then hit back. Reproducible: Always Steps to Reproduce: 1. Visit http://slovnik.seznam.cz/ 2. type some word ("test") into the form input field and hit Enter. 3. Hit Back button. Actual Results: I see almost all images are "broken" there like they're missing on the server or their src= is broken. Reload "fixes" that. Screenshot is at http://Xtrmntr.org/ORBman/tmp/slovnik.seznam.cz.after-back.png Screenshot if http://www.ihned.cz/ is at http://Xtrmntr.org/ORBman/tmp/ihned.cz.after-back.png I'm using current trunk (synced 3 hours ago) on Mandrake 8.2 Linux. This doesn't happen with branch 0.9.9 nor older releases.
Changing QA contact
WFM: Using 2002032203 build on WinXP.
still reproducible with 20020323 on Mandrake 8.2 Linux
this also happens with galeon-1.2 compiled against trunk.
I have performed the binary search of nightbuilds (i686-linux.tar.gz) to find when this bug first appeared. It was introduced in 2002-03-10-21-trunk. All newer and current has it. The bug was NOT in 2002-03-09-21-trunk and older. (Mandrake 8.2 Linux)
checkins between 03/09/2002 18:00:00 and 03/10/2002 22:00:00 : http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Change+Size&hours=2&date=explicit&mindate=03%2F09%2F2002+18%3A00%3A00&maxdate=03%2F10%2F2002+22%3A00%3A00&cvsroot=%2Fcvsroot (unfortunately, it's not clear to me what could cause this regression)
It also happens on google images search: http://www.google.com/imghp Visit it, search some picture (say "bush" or "coke"), then click on the first one. After the page is loaded, hit the "Back" button. You're back on the search results with images missing.
WFM with Linux build 20020323. have you tried a clean profile? I see similar things sometimes when my cache gets corrupted, and clearing the cache fixes it. You might try that instead of reload.
So, I have more information: Cleaning the Cache directory -> doesn't help. New Profile -> WFM! So I have tested more and found that: If you set Disk Cache to 0 (zero) or Disable Disk Cache in Prefs/Debug/Networking the bug happens. If you set the Disk Cache to non-zero and turn on [x] Enable Disk Cache the bug is over (WFM). So I still think this is a bug. The browser should work good when Disk Cache disabled. (I have squid locally, no need for another disk cache in browser).
pavlov's patch to bug #42224 is between 03/09/2002 18:00:00 and 03/10/2002 22:00:00, doesnt show in martin's query becouse it is in libpr0n (not part of SeaMonkeyAll)
I tryed to backout pavlovs patch and bug seems to go away cvs diff -r1.16 -r1.15 modules/libpr0n/src/imgRequestProxy.h > /tmp/temp cvs diff -r1.36 -r1.35 modules/libpr0n/src/imgRequestProxy.cpp >> /tmp/temp cvs diff -r1.64 -r1.63 modules/libpr0n/src/imgRequest.cpp >> /tmp/temp patch --posix -p0 < /tmp/temp
Comment on attachment 78115 [details] [diff] [review] This patch seems to fix this this patch will break the cancelation of multipart mixed images which would result in them loading until you exit the browser...
Excuse me for butting in, but I have been hitting this for some time. Why does this bug have priority=minor and target=future? This bug can make Mozilla look really bad. If a power user disables his/her disk cache, every time back pressed the resulting page will have broken images. This affects a substantial percentage of sites and makes pages display very badly. See attachment for an example; if the images have alt text it gets even worse. The workaround, enabling the disk cache and restarting mozilla, seems to fix the problem, but it is not obvious. I found it by finding this bug, but an average user,or even a power user, would not know where to look. This could make 1.0 look pretty bad. If it's not fixed by 1.0, I think it should go in the release notes...
*** Bug 138476 has been marked as a duplicate of this bug. ***
WFM with 1.0.0 branch build 2002050406 WinME. Reporter, do you still see this with a recent nightly?
Confirming, WFM too with branch 20020504 Linux.
*** Bug 138559 has been marked as a duplicate of this bug. ***
*** Bug 142217 has been marked as a duplicate of this bug. ***