Images disappear after loading

VERIFIED FIXED in mozilla0.8

Status

()

defect
P1
critical
VERIFIED FIXED
19 years ago
19 years ago

People

(Reporter: tarahim, Assigned: gordon)

Tracking

({regression})

Trunk
mozilla0.8
PowerPC
Mac System 9.x
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

()

Attachments

(1 attachment)

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.
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
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: 19 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. ***
Marking verified per last comments.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.