13341 - [PP]Horizontal lines drawn on-screen on first load of an image

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[Eli Goldberg]

* TITLE/SUMMARY
Horizontal lines drawn on-screen on first load of an image

* STEPS TO REPRODUCE
0) Launch Apprunner
1) View http://slip/projects/marvin/html/img_width_percent.html. (Will attach
relevant files to this bug report as a test case)

* RESULT
 - What happened

As each image loads, replacing the ALT text with the actual image, the page
reflows.

When these reflows occur, a line of black pixels --- the width of each image
that's drawn --- is left on-screen. It's a bit hard to explain, so I'll attach a
screen shot.

If you try to reload or resize the page (in which point the images are available
in cache, ne?), the ALT text is not displayed, and the page displays correctly.

 - What was expected

Bitgunk not to be left on-screen during page reflows.

* REGRESSION

 - Occurs On
        Mac OS Apprunner (19990808 optimized build)
        Win32 Apprunner (19990808 optimized build [NT 4, Service Pack 3])

 - Doesn't Occur On
        Linux Apprunner (1999082316 [busted] build date; probably this morning's
build.)

* CONFIGURATIONS TESTED

- [Mac] Beige Power Mac G3 (266 MHz PowerPC 750), 96 MB RAM (VM on; 1 MB of VM
used), 1024x768 (Thousands of Colors), Mac OS 8.6

- [Win32] Vectra VL (233 MHz P2), 96 MB RAM, 800x600 (True Color), NT 4.0 SP3.

- [Linux] Vectra VL (266 MHz P2), 96 MB RAM. Red Hat Linux 6.0 (GNOME).

Comment 1

[Eli Goldberg]

[QA Assigning to self; petersen, if you truly wish to be the QA assigned on this
bug, please feel free to reassign back. ;-]

Comment 2

[Eli Goldberg]

Attachment: Test Case (file 1 of 2)

Comment 3

[Eli Goldberg]

Attachment: Test Case (file 2/2)

Comment 4

[Eli Goldberg]

Attachment: Screen shot of bug on Mac OS (PICT format)

Comment 5

[Eli Goldberg]

<Included screen shot of bug; used PICT format assuming that Patrick is probably
on a Mac and wouldn't mind. ;->

Comment 6

[Patrick C. Beard]

This entire page is rendered inside a single view, so I don't believe this is a
view manager problem. More likely inside the code that manages reflow of images.

Comment 7

[leger]

Putting on [PP] radar

Comment 8

[troy]

I don't think this is a Mac specific problem. If it is it certainly shouldn't be
assigned to me.

Please test this on the major platforms so we can determine whether it is in
fact platform specific

Comment 9

[troy]

Fixed. The problem was that the image frame code was rendering the image loading
feedback outside of the image frame's bounds

Comment 10

[Eli Goldberg]

Using the 1999092208, this appears fixed on Mac OS & Linux. However, the
additional bitgunk from the screen shot (from the 100%, 50%, etc text) is now
being drawn on Win32 [NT 4.0 SP3, True Color].

Troy, I'm re-opening the bug; if this is a different issue, please insert your
$.02, and I'll break it into a separate bug report. Thanks!

Comment 11

[troy]

I develop on NT, and so I verified that it was fixed on NT. It looks fine for me
now.

I'm wondering if what you're seeing is a known image library bug that gray
(usually) is sometimes displayed in the parts of an image that haven't yet been
loaded. That is bug #1248

Comment 12

[Eli Goldberg]

Attachment: Current behavior

Comment 13

[Eli Goldberg]

Hey, Troy ---

Weird. I've enclosed a screen shot (8-bit BMP) so that you can see the behavior
that I'm seeing; it's actually different from what's described in 1248.

If this isn't appearing on your system, I can poke around and try to isolate it.

Comment 14

[troy]

Hmmm. Do you see the problem in viewer.exe as well, or only when you're running
apprunner.exe (the screenshot shows apprunner)

Comment 15

[troy]

I don't see that problem. At least not in using viewer.exe

Comment 16

[Eli Goldberg]

viewer.exe is no longer being packaged with the current builds. I'm going to poke
around...

Comment 17

[Eli Goldberg]

(got viewer.exe from the public mozilla build)

Using the 9.22.99 AM build, I'm still seeing the same behavior. Will poke around
a bit further for reproducibility...

Comment 18

[troy]

Looking at your screen shot, I agree it doesn't look like the image library bug.
It looks like an incremental painting bug where layout just didn't repaint
properly

Comment 19

[Eli Goldberg]

Now, I can no longer reproduce this problem on any of the 1999.9.27 AM optimized
builds (Mac/Win/Linux). I'm happy to call it fixed, if it's okay with you.

Comment 20

[troy]

I'm happy to have it marked FIXED. If my current fixe wasn't working I was sort
out of options for what to do. :-)

Comment 21

[Eli Goldberg]

WORKSFORME. Err, fixed. Thanks!