237775 - {inc} Page containing many <select>'s malformed after initial paint...

Status: VERIFIED WORKSFORME

(Core :: Layout: Tables, defect)

Description

[u81239]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

The attached page shows incorrectly if it is still loading after the initial
paint delay. All of the <select> inputs should be evenly spaced vertically.  The
last column should end with a 9:20pm timeslot. However, Mozilla leaves gaps at
unpredictable places, and there are overlaps and simply incorrectly rendered
items. Also see the attached screen shot.

If the page is taken from cache, from a local file or loaded into another tab,
and only show when it's done loading, the initial paint is done after the page
is loaded in its entirity and everything looks fine. So in order to reproduce it
again you'll have to reload without cache (CTRL-F5). Also, I think if the
connection to bugzilla is too fast, and the entire page is loaded before the
paint delay, setting a lower paint delay would help.

This problem appears both in Mozilla 1.7a as in Firefox 0.8 and a build from the
latest CVS. Even Galeon does seem to have it. Also, the original reported was
working on a Linux machine, and I am using Windows 98, and someone else who
tried was using Windows 2000. So it's clearly a problem with the Gecko engine,
and OS-independant.

It does seem to have 'some' resemblance to another bug of mine, bug 237728. This
one, however, is reproducible on other systems :).


~Grauw

Reproducible: Always
Steps to Reproduce:
1. Clear cache (or ctrl-reload)
2. Set nglayout.initialpaint.delay to a low value if needed
3. View attached page

Actual Results:  
Mozilla leaves gaps at unpredictable places, and there are overlaps and simply
incorrectly rendered items. Also see the attached screen shot.

Expected Results:  
All of the <select> inputs should be evenly spaced vertically.  The last column
should end with a 9:20pm timeslot.

Comment 1

[u81239]

Attachment: Test case

Comment 2

[u81239]

Attachment: Output

Comment 3

[u81239]

p.s. I am not sure about the initial paint delay having something to do with
this in particular, it is just my guess and also based on experiences with that
other mentioned bug I er... 'suffer' from.

Comment 4

[Pascal Chevrel:pascalc]

confirmed with build 2004031508 WinXP

Comment 5

[u81239]

Attachment: Test case v2

Slightly cleaned up code, removed javascript and validating now except for
ill-placed <form> tags...

~Grauw

Comment 6

[u81239]

Attachment: Test case v3

Properly placed the <form> tags so the document now fully validates. Added
style: form { margin: 0 } because form puts margin at the bottom, apparantly.

Troubles are gone now.

I don't know if the setting of the margin made the problem disappear, or that
the forms trying to have margins in places where they weren't supposed to
(between table cells) caused the problem. I think it is the latter.

Dunno what to do with it now... WONTFIX?


~Grauw

Comment 7

[[e-mail]]

The correct resolution for a bug that goes away when the page is corrected so
that it validates is probably INVALID.

Comment 8

[u81239]

Well, it's not that it just displays wrong... It is showing unpredictable
results, and messes up drawing some select items (as you can see at the bottom
of the screenshot). So I think it definately is a bug, while 'invalid' would
claim it's not a bug. Right? If that is the case, wontfix seems more appropriate
to me.

~Grauw

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Who says it shouldn't be fixed?

That said, a testcase that reliably shows the bug would be nice.

Comment 10

[Steve Kirkendall]

(In reply to comment #6)
> Created an attachment (id=144129)
> Test case v3
> 
> Properly placed the <form> tags so the document now fully validates. Added
> style: form { margin: 0 } because form puts margin at the bottom, apparantly.
> 
> Troubles are gone now.
> 
> I don't know if the setting of the margin made the problem disappear, or that
> the forms trying to have margins in places where they weren't supposed to
> (between table cells) caused the problem. I think it is the latter.

I'm the person who first encountered the bug.  The odd placement of the
<form> tags was intended to work around a quirk of MSIE -- it likes to
add a blank line after each form, which can be a real space-waster when
a column contains 100 forms.  Putting the <form> tags outside the <td>
tags, instead of inside, prevents that.  Mozilla renders it compactly
either way.

But your "sample3.html" example renders nicely on MSIE, so I'm happy.
The style specification is exactly the kind of workaround I was hoping
for, to solve my immediate problem.

But I still think of this as a workaround.  The bug is still there.  If
other browsers can render the page correctly, then Mozilla should too.

I suspect the variation in the rendering (i.e., the gaps aren't always
in the same place) is due to Mozilla rendering a partially-received
version of the page, and then INCORRECTLY trying to adjust the rendered
page as more of it is received.

My scheduling application generates pages like this in response to forms
submitted by the user.  The pages aren't cached.  Each time I hit the
[Reload] key, the gaps are likely to shift around, but they rarely
disappear completely.

Comment 11

[u81239]

Attachment: 'nother test case... (v4)

Ok David :). Well, I tried coming op with a 'cleaner' example of Test case v2,
but well... it came out only so-so. v2 is, if you ask me, still the best
example of the problem.

Today's lesson:
"how to make Mozilla use 100% CPU and be slow as hell".

First of all, this attachment nearly hangs in Firefox 0.8, and in the latest
CVS Firefox is sloooooooow. Seems this difference has to do with getting rid of
nglayout.initialpaint.delay in the CVS version, at least I can't find it
anymore in about:config. This actually makes Test case v2 come out better :).

Anyways, about this test case. Aside from showing today's lesson, it doesn't do
a very good job at showing this bug. In Firefox 0.8 you can sometimes see it in
the right half of rows. Trying CTRL-F5 a few times helps (also in v2). But in
Firefox CVS it doesn't seem to work, nor in Mozilla 1.7a. Probably v2 works
better due to excessive bloat in the code, or something :). I tried putting in
additional input elements, but that doesn't seem to matter much... Maybe the
additional table nesting does. Anyways, once I do that I pretty much arrive
back at test case v2 again, so that wouldn't be worth the effort.

And Steve, thanks for commenting :). Note by the way that forms also put an
empty line below them (actually a bottom-margin) in Mozilla, so it's not an
IE-only thing, it's just the default style for forms, it seems. That's why I
put in the form{margin: 0;} style. Anyways, I think you're in the right
direction about what is exactly going wrong.

~Grauw

Comment 12

[Boris Zbarsky [:bzbarsky]]

Pascal, please don't confirm bugs without minimal testcases....

If someone could create a small testcase using hyatt's JS trick, that would be
great.

Comment 13

[u81239]

Comment on attachment 144127 [details]
Test case v2

de-obsoleted testcase v2

Comment 14

[Mats Palmgren (inactive)]

Attachment: Small testcase

Bug occurs in both Standard and Quirk mode -
see HTML source for additional comments

Comment 15

[Mats Palmgren (inactive)]

-> Tables

Comment 16

[u81239]

Comments from the latest testcase:

<!-- Bug only occurs when the FORM is misplaced -->

This is correct.


<!-- Bug only occurs when this text is longer than "LUNCH" -->
<!-- Bug only occurs when the "selected" attribute is present -->

Neither is the case in "v4", and yet I can reproduce the bug in Firefox 0.8. It
appears randomly there, and not always, but pressing CTRL-F5 a few times should
give you some occurrances. I don't think I can reproduce in Firefox CVS (guess I
have to try again to be sure), but that could be related to the removal of
nglayout.initialpaint.delay, and not the removal of the bug.

Anyways, with or without, fair chance that it's the same buggy code causing this
behaviour... :)


~Grauw

Comment 17

[u81239]

Also, note that the errors in the first test case also appear randomly. So
checking differences with test case 2 might be interesting...

And test case v4 also addresses another issue - one about huge slowdowns. Don't
forget it :).


~Grauw

Comment 18

[Boris Zbarsky [:bzbarsky]]

If there is another issue, file a bug on it.  One issue per bug and all.  Feel
free to cc me on that other bug.

Comment 19

[Steve England [:stevee]]

With "Small testcase" I can see no difference between its layout wrt reload/shift reload with both:
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006120606 Minefield/3.0a (pre-reflow branch)
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006120804 Minefield/3.0a1 (post-reflow branch)

Comment 20

[Andrew Schultz]

This got fixed sometime in January
resolving WFM (tested attachment 144150 [details] and attachment 144166 [details])

Comment 21

[Mats Palmgren (inactive)]

VERIFIED
Firefox 2006-01-05-05 Linux is broken
Firefox 2006-02-08-05 Linux works