65614 - Scaled images with width or height by % endlessly redisplay

Status: VERIFIED DUPLICATE of bug 52798

(Core :: Layout, defect)

Description

[Deven Corzine]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17 i686; en-US; m18) Gecko/20010114
BuildID:    2001011421

I've often noticed a flickering line at the bottom of the comment screens on
Slashdot when using Mozilla.  The status line at the bottom of the window keep
alternating between "Resolving host images.slashdot.org", "Sending request to
images.slashdot.org" (especially) and "Document: Done" as the line flickers.

I've finally gotten around to investigating this bug, and stripped down the HTML
as far as possible to make a test case.  (I increased the height for visibility;
it has no bearing on the bug.)  The bug manifests with an IMG tag scaled with a
percentage width or height.  HTML tables are not needed to exhibit the bug, and
are not in the test case.  While the IMG tag exhibits the bug, it seems to be
specific to using percentages for the width and/or height, and the image can be
seen (displayed properly) for small fractions of a second before flickering again.

My speculation is that there's some sort of reflow being triggered after the
image is loaded, and that the reflow is in turn triggering a potential resizing
of the image, which is triggering a reload of the image (usually from the cache,
it seems), which is causing a reflow...

Someone with more understanding of the layout engine will have to tell me if my
speculation is plausible or wildly off the mark, but for now I've selected
Layout as the component, since it seems more appropriate than ImageLib (if my
speculation is correct)...

Reproducible: Always
Steps to Reproduce:
1. Load the testcase.  (Or load a Slashdot comment page and scroll to the end
and look just before the "Search" box and pithy quote.)
2. Notice flickering of image area and status line information.

Actual Results:  The browser window ends up in a seemingly endless loop,
repeatedly redisplaying the image in a flickering manner.  (This is why I
suspect an infinite reflow loop of some sort.)

Expected Results:  The image should load once, and not keep redisplaying.

If the specified width and height are each set to a fixed number of pixels, this
flickering will not occur, and the scaled image will load properly.  If the
width, height, or both are set by percentage, the bug manifests itself.

Comment 1

[Deven Corzine]

Attachment: simple testcase with 80% width, 100 pixel height

Comment 2

[Bernd]

I think this is a dupe of bug 46910

Comment 3

[Deven Corzine]

Bug 46910 seems like it may be related, but that one is using CSS to set the
width, while my test case is just using width="80%" in the IMG tag.  Moreover,
that bug doesn't discuss this looping behavior, and here the image here is
getting sized correctly.  It just flickers as it keeps reflowing the page.

If you don't see flickering when loading the testcase, try hitting the reload
button once or twice to see if that gets it going.  It seems to sometimes have
long random pauses, which might be another bug altogether...  (But I never see
the testcase go to "Document: Done" and stay there.)

Comment 4

[Fabian Guisset]

Hmm this is flashy, it almost blinded me ;) (put a red image that takes the
whole screen and you cause a lot of infarctus!).
Marking new. Reproduced in mozilla0.7 and build 2001011404 win32.
Note : I had to hit reload to see the problem.
OS to all.

Comment 5

[tenthumbs]

Could this be related to bug 63750 ?

Comment 6

[Deven Corzine]

Yes, bug 63750 looks like basically the same issue, though perhaps searching in
a different direction for the answer.  Maybe it's not reflow-related; that's
just how it seems to me.  (Has anyone investigated the possibility?)

Comment 7

[Bernd]

set GECKO_BLOCK_DEBUG_FLAGS=reflow

load testcase

reload testcase and the reflow messages will never end.

Comment 8

[Deven Corzine]

Nice to have some confirmation of my speculations.  Where do you do that set? 
It doesn't seem to work as an environment variable.  Do you have to do it in
gdb, or in Javascript, or what?

So, what's causing the reflow loop?

Comment 9

[Jesse Ruderman]

I think this is a dup of bug 52798 by way of bug 58645.

Comment 10

[Karl Ove Hufthammer]

Note: At least in the latest builds, height specified using percentages are
completely ignored in strict mode.

Comment 11

[Deven Corzine]

Wow, this page REALLY shows the reflow problem -- the images shrink before your
eyes, as multiple scaled-by-percentage images flicker in and out.  Look at the
rows in the bottom half of the second table on this page, in the right column:

http://www.nichia.co.jp/lamp-e.htm

Comment 12

[HJ]

Attachment: Testcase

Comment 13

[HJ]

Attachment: Testcase

Comment 14

[HJ]

Please take attachment 25548 [details] because that's the correct one. This testcase shows
that it keeps reloading the images time after time. It seems that after each
reload width is recalculated, and so the images are getting smaller and smaller.

If it doesn't trigger the bug after the initial load, just use reload to trigger
the bug.

Comment 15

[HJ]

Oh, and only the first two images should trigger this bug.

Comment 16

[HJ]

I belief this is a dup of bug 52798 "gif img in table with width=100% blinks
rapidly (flashes, flickers)" The same problem here, the images keep reloading
time after time.

Comment 17

[HJ]

Attachment: Another testcase

Comment 18

[HJ]

The first time you load that last testcase, the first image should be 100% of
your screen size. After you reload this image it's also smaller. So when you
reload this testcase, the size of that first image not used, but the image size
itself is used.

Comment 19

[HJ]

Also note that I have set <table width="100%"> (or try any other value) for the
first table and you see that it doesn't flash nor does it reload the image. But
the second one keep reloading, and is getting smaller and smaller after each reload.

Comment 20

[Stephan Niemz]

I also agree that this is a dup. Other bugs about the slashdot flickering
have been marked as dups of that mostfreq bug, too.

*** This bug has been marked as a duplicate of 52798 ***