Closed Bug 66508 Opened 25 years ago Closed 25 years ago

Images disappear after loading

Categories

(Core :: Networking, defect, P1)

Product:
Core
Component:
Networking
Platform:
PowerPC
Mac System 9.x
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.8

People

(Reporter: tarahim, Assigned: gordon)

References

(
URL
)

Details

(Keywords: regression)

Attachments

(1 file)

Unified diffs updated to the NSPR tip
2.19 KB, patch
Details | Diff | Splinter Review
I do not think this is the same as 63091, because it started in 20010124 build. Lots of sites with tables show images while loading, and then those images diappear after loading is complete. View Page Info list those images as width=0 height=0. The images in the source have no width or eight specified in the HTML.
This may be a dupe of 58935, but it certainly got tremendously worse in 20010124 build, since 0122 build can display the images in most of the sites I visit. Additional note: if the source has ALT text defined for an image, the ALT text is displayed in its place.
Could you give an URL in the status so We can test it please ?
Sorry about not entering the URL. The bug is so obvious that I was not sure which URL to put here. If you are not seeing any problem in this very page, you are not seeing the bug.
URL: http://bugzilla.mozilla.org/show_bug....
I modified the summary because I have realized that some images have width and height defined and View Page Info displays those information correcctly while the image itself is not displayed.
Summary: Images disappear after loading (treated as width=0, height=0) → Images disappear after loading
Does this bug occur for you at http://www.cnn.com/ ? (It doesn't for me.) If not, please give an example URL where you see the bug.
The bug is well and alive in 012504 build. cnn or abc, lots of images just disappear. URL is provided above: The banner at the top of this page does not show up either.
I have seen this bug in the builds from 1/24/01 and 1/25/01 on the Mac. Here is what I seen happening: I click on a url link to an image, but the image does not display as expected. Instead the image is dispalyed and then replaced with the text of the "alt". I wonder if the problem is caused by the wrong download order of image and "alt" text. If the "alt" text displayed first and then the image the link would work. (?)
*** Bug 66778 has been marked as a duplicate of this bug. ***
To bring over from bug #66778, http://news.bbc.co.uk/ was horked. Screenshots should be over there.
*** Bug 67114 has been marked as a duplicate of this bug. ***
Nominating for 0.8
Target Milestone: --- → mozilla0.8
fixing nomination
Keywords: mozilla0.8
Target Milestone: mozilla0.8 → ---
*** Bug 67386 has been marked as a duplicate of this bug. ***
*** Bug 67436 has been marked as a duplicate of this bug. ***
*** Bug 67650 has been marked as a duplicate of this bug. ***
http://www.hififorless.com/acatalog/hififorless_on_line_SENNHEISER_19.html is a good place to see this. adding mostfreq keyword. this really makes the product unusable. someone other than clayton should own this, but since buster is leaving...?
Assignee: clayton → buster
Keywords: dogfood, mostfreq, regression
I saw this on www.eetimes.com too. Can we get a Mozilla 0.8 on this one please?
I'm not seeing this in a fresh pull from today on windows. Since all of the image frame code in layout is XP, I seriously doubt that this is a layout regression. Could anything have changed in the image lib or netlib notifications for Mac and not Win?
Priority: -- → P1
what leads me to believe that it is layout is that you see the images start to draw, then one by one just vanish as the page continues loading.
FWIW, I don't think this is a new problem, but it might have gotten worse recently.
I'm out of the office tomorrow and wednesday, so someone else will have to look into this. I haven't seen a recent mac build running, but I stand by what I said about the platform differences: image frames don't know anything about platform, so I suspect the problem is elsewhere. To see what's going on in layout, the interesting method is nsHTMLImageLoader::GetDesiredSize(). You can print some debug gunk to stdout by #define'ing NOISY_IMAGE_LOADING in mozilla/layout/html/base/src/nsHTMLImageLoader.cpp I'll log tonight before I leave for LA, and if anybody has been able to get any useful information off a misbehaving Mac I'll do what I can to help. In the meanwhile, I'm assigning this to Karnaze to find a home.
Assignee: buster → karnaze
Assignee: karnaze → waqar
Reassigning to Waqar.
Images disappear because necko sends back an error code from the OnStopRequest, calling NetReaderImpl::StreamAbort with a value of -201. So this looks like a necko problem.
I eventually tracked this down to some kind of NSPR problem in its Open Transport calls. A call to OTRcv is returning -3155 (call issued in wrong state). Definately a bug for gordon.
Assignee: waqar → gordon
Component: Layout → Networking
I think this assertion will catch the time where we get an error calling OTRcv. It seems that we're calling this after we've got an orderly release request. Index: mozilla/nsprpub/pr/src/md/mac/macsockotpt.c =================================================================== RCS file: /cvsroot/mozilla/nsprpub/pr/src/md/mac/macsockotpt.c,v retrieving revision 3.15.2.6 diff -b -u -2 -r3.15.2.6 macsockotpt.c --- macsockotpt.c 2000/10/12 22:39:16 3.15.2.6 +++ macsockotpt.c 2001/02/06 03:04:28 @@ -1421,4 +1421,5 @@ fd->secret->md.read.thread = me; fd->secret->md.readReady = PR_FALSE; // expect the worst + PR_ASSERT(fd->secret->md.connectionOpen); result = OTRcv(endpoint, buf, bytesLeft, NULL); if (fd->secret->nonblocking) {
This bug was caused by the fix for 56170, in version 3.25 of macsockopt.c: <http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show& file=macsockotpt.c&root=/cvsroot&subdir=mozilla/nsprpub/pr/src/md/mac&command= DIFF_FRAMESET&rev1=3.24&rev2=3.25>
well, gordon's fix (IIRC) was to return an error in a case where we weren't before (other NSPR impl's seem to report an error if this case occurs as well). If something else was introduced afterwards that would trigger this error, it's probably not gordon's fault. Can we narrow down when this bug was introduced?
according to sdagley, this isn't a problem in the nscp branch. if it was simply gordon's problem, caused by his checkin in October 2000, the branch would have this problem too. Since it doesn't, something else has certainly aggrivated this error condition. maybe it is still gordon's, but something changed more recently...
nsIChannel::AsyncWrite interface needs to be revised bug 62566 came up when mozilla/netwerk was searched between 01/22 and 01/24. Could it be related?
I am beginning to wonder if 66527 is caused by the same bug. The two satrted in 01/24 build, and both involve losing once-loaded content.
hirata: good catch. The assertion I pasted above is hit for the testcase in bug 66527 too, so you're right.
When I tested mac-Mtrunk-2001020104, it seemed that the list of URLs in this page looked fine in my system(for example, news.bbc.co.uk and www.eetimes.com looked fine). However, I reported to Bugzilla-J(Japanized Bugzilla, http:// bugzilla.mozilla.gr.jp/show_bug.cgi?id=630), there is an another page to which images disapper too. Mtrunk-2001020604 is the same. Then, I have the impression to which images disappear also in image counter(e.g. wwwcount2.x). (My system: B&W G3/450, 192MB, MacOS8.6-J(Japanese system), Open Transport 2.0.3.)
a very critical site is this: http://www.ibazar.fr images disappear very fast, it seems to watch a fire-show! I'm on a PB G3 bronze keyboard, 128MB OS8.6 vm on.
These are the patches I landed to on the 6.0 branch to fix a similar problem. The bug was somehow prematurely closed, and I never landed the changes on the trunk. Index: mozilla/nsprpub/pr/include/md/_macos.h =================================================================== RCS file: /cvsroot/mozilla/nsprpub/pr/include/md/_macos.h,v retrieving revision 3.22.2.1 retrieving revision 3.22.2.1.20.1 diff -r3.22.2.1 -r3.22.2.1.20.1 94c94 < PRBool connectionOpen; --- > PRBool orderlyDisconnect; Index: mozilla/nsprpub/pr/src/md/mac/macsockotpt.c =================================================================== RCS file: /cvsroot/mozilla/nsprpub/pr/src/md/mac/macsockotpt.c,v retrieving revision 3.15.2.4.20.1 retrieving revision 3.15.2.4.14.3 diff -r3.15.2.4.20.1 -r3.15.2.4.14.3 328d327 < secret->md.connectionOpen = PR_TRUE; 350d348 < secret->md.connectionOpen = PR_FALSE; 383c381 < secret->md.connectionOpen = PR_FALSE; --- > secret->md.orderlyDisconnect = PR_TRUE; 1487c1485,1487 < case kOTOutStateErr: // it has been closed, fall through for error --- > case kOTOutStateErr: // if provider already closed, fall through to handle error > if (fd->secret->md.orderlyDisconnect) > return 0; 1780c1780 < fd->secret->md.connectionOpen = PR_FALSE; // starts out closed --- > fd->secret->md.orderlyDisconnect = PR_FALSE;
Target Milestone: --- → mozilla0.8
*** Bug 66527 has been marked as a duplicate of this bug. ***
This patch certainly fixes this bug, and bug 66527. We need it tested for the IMAP sleep case. Pink?
r=pinkerton. applied the patch and imap is still ok.
pink sez that with the patch, the IMAP sleep problem is still fixed, so life is good. sr=sfraser. Side notes: Probably better to use PRPackedBool in structs in NSPR. Also, those NSPR files are seriously whacked in terms of spacing/tabs. They need mass cleanup there.
It's not just the spacing and tabs that need to be cleaned up...
Fix checked into NSPRPUB_CLIENT_BRANCH and NSPR tip.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
*** Bug 58935 has been marked as a duplicate of this bug. ***
*** Bug 63091 has been marked as a duplicate of this bug. ***
Keywords: dogfood, mozilla0.8 → nsdogfood
Marking verified per last comments.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: