65708 - only 2-3 lines of a picture is displayed

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[Jens-Uwe]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14 i586; en-US; m18) Gecko/20010117
BuildID:    20010117

on this website some of the pictures are not displayed correctly. one can only
see 2-3 lines of each picture, and and seems it overwrites older lines when
displaying a new one. 
If one stores the picture to disk and opens this picture via "open files" the
picture is displayed correctly!

Reproducible: Sometimes
Steps to Reproduce:
1. go to www.binichsexy.de
2. press "reload" until a wrong displayed appears

please not, that not all pictures are displayed wrong!

Actual Results:  one can see a wrongly displayed picture

Expected Results:  the picture should be displayed correctly

haven't tried it on a non linux system, will do so today
this is a fun page someone in our company found, so please don't think I
regulary visit this page ;-)

Comment 1

[Fabian Guisset]

Could not reproduce on mozilla0.7 win32.

Comment 2

[[e-mail]]

I saw this once but couldn't reproduce it because the page isn't static :-(

The image in question was wider than the space available, could that be a clue?

Comment 3

[Matthias Versen [:Matti]]

I can reproduce this with w2k build 1011308, 0122320.
If you can´t see this, try to reload this page (Shift+Reload).
Thje picture is changing. 
Change OS from Linux -=> All

Comment 4

[Matthias Versen [:Matti]]

Attachment: scrennshot with only 2-3 lines of the picture

Comment 5

[pnunn]

All pnunn bugs reassigned to Pav, who is taking over
the imglib.

Comment 6

[Aleksander Adamowski]

Attachment: When opened locally this image gets corrupted when displayed for the first time

Comment 7

[Aleksander Adamowski]

I've got a way to reproduce it with 100% certainty on W2K (Build ID: 2001032604):
1. take this picture from the Web: http://office.altkom.com.pl/mozilla/logo.png
or from the attachment (id=28808)
2. Place it locally on your HDD (when opening it remotely doesn't work every time)
3. Try to open it with File->Open
It should display corrupted. However, if you switch to another window and switch
back to mozilla, the image will display correctly without even having to reload!
Immediate following reloads of the image don't show the corruption. However, if
you wait a considerable amount of time (a couple of minutes maybe) then, after
reloading, it will display corrupted again.
This problem occurs not only with PNGs, I've also seen it happen with JPGs and
GIFs (the one on Google's frontpage for example), but couldn't reproduce it on
remote pics - they don't corrupt the second time, sometimes even never again...
I also experienced crashes when displaying the corrupting pic (Talkback IDs:
TB28277471E
TB28276985E
), but those may be unrelated, I noticed similar crashes with this build elsewhere.

Comment 8

[Aleksander Adamowski]

One additional note: I didn't see it on any of latest Linux builds (gcc-295-i686
nor i686 sea nor i686-sea)

Comment 9

[Aleksander Adamowski]

Ooops it seems that I misunderstood the problem. One described here is seemingly
unrelated. My reports apply to temporary image corruption when displaying (the
image's size is preserved, not reduced to 3 pixels).
Do you know of any bug that matches my description? I couldn't find any with
Bugzilla query...

Comment 10

[Aleksander Adamowski]

There's something funny about this: I was led to believe this is the same
problem because when I opened  the attachment 22767 [details], it displayed corrupted on
my screen. I thought that was the screenshot of image being displayed in a
corrupted state...

Comment 11

[Aleksander Adamowski]

I opened a separate bug, 73475 if anyone is interested.

Comment 12

[Stuart Parmenter]

not imagelib related.  the html imageframe is being sized to really small

Comment 13

[karnaze (gone)]

Petersen, can you please develop a test case. Reassigning to attinasi.

Comment 14

[Marc Attinasi]

Moving out to Mozilla 1.0 - does not seem critical for 0.9

Comment 15

[Marc Attinasi]

Attachment: Minimal testcase: image with width only specified.

Comment 16

[Marc Attinasi]

I've attached a testcase that shows the problem. I may need to attach another as 
the image URL will likely change sometime..

Anyway, the problem appears to be when only one dimension on the IMG is 
specified, in this case the width. The calculation of the height gets all 
whacked-out. I think you may have seen this, Pavlov, so, not to be a jerk, but 
I'm sending it back to you. If this is not your deal, then I'll gladly take it 
back and investigate the size computation code in the ImageFrame when I can.

Comment 17

[Marc Attinasi]

Attachment: Image for new testcase

Comment 18

[Marc Attinasi]

Attachment: Testcase using same image served from Bugzilla. Seems to work?

Comment 19

[Marc Attinasi]

I added two testcases. One gets the image from the www.binichsexy.de site and it 
seems to fail sometimes. The other gets the same image from bugzilla and I 
cannot get it to fail. Could the server be messing up the image?

Comment 20

[Stuart Parmenter]

i'll investigate this one carefully.  it is possible that there is some bug
going on.  there were some comments about sizes in tables screwing things up
that I may have not gotten right.

Comment 21

[Dave]

Is this the same bug people are seeing at http://www.amihotornot.com?

Comment 22

[Jens-Uwe]

I think so. Atleast the german edition of amihot seems to use a software very
similar to binichsexy.de, so I would expect both suffer the same bug in Mozilla.

Comment 23

[Stuart Parmenter]

hmm, after going to about 40 pictures, i got it to not draw part of one...   
i'll see if i can figure this out...  I don't think it is width or height 
related.... but maybe i'm a fool or someone else has fixed this bug?

Comment 24

[Stuart Parmenter]

Attachment: fix. subtract border and padding from the size we give back on image.width and image.height

Comment 25

[Brian Ryner (not reading)]

r=bryner

Comment 26

[Johnny Stenback (:jst)]

sr=jst

Comment 27

[Stuart Parmenter]

fix checked in

Comment 28

[Keyser Sose]

*** Bug 79011 has been marked as a duplicate of this bug. ***

Comment 29

[Chris Petersen]

Marking verified in the May 30th build.