274556 - {inc}Page layout changes when clicking on form buttons

Status: RESOLVED FIXED

(Core :: Layout: Tables, defect)

Description

[r.navalinskas]

Sometimes when clicking on "submit" button on some web form, it doesn't work at
once, instead page layout is slightly changed and only next or further next
click on the same button "works". Example:

1. go to http://www.miestai.net
2. On the left side there is some kind of "poll", i.e. web form.
3. Try clicking on buttons "balsuoti" or "rezultatai" and see what happens.

This bug is not new.

Comment 1

[Martijn Wargers (dead)]

I can see the bug, using:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20041213
Firefox/1.0+
Reporter, did you see this bug also with a 1.8a build, or with a 1.7 build?
If this is not happening in a 1.7 build (and I can't see it happening) then this
should be blocking bug 261196. (and this bug needs a minimal testcase).

Comment 2

[r.navalinskas]

Can't say regarding 1.7. It was so long ago... About test case - I already
mentioned how to reproduce the problem, is it sufficient ?

Comment 3

[Martijn Wargers (dead)]

With a simplified testcase, I can confirm the bug. It makes it for developers
easy to see where Mozilla is doing something wrong (codewise). I'll try to make
a testcase.

Comment 4

[Martijn Wargers (dead)]

Attachment: Testcase

Comment 5

[Martijn Wargers (dead)]

Confirming, although this could be a duplicate, I haven't really looked.
I guess the right component would be Layout->Tables

Comment 6

[Vincent Lefevre]

Same problem (using the testcase) under Linux/PPC, using Mozilla (CVS checkout
and compiled a few hours ago). Hardware/OS should be set to All/All.

Comment 7

[Blake Kaplan (:mrbkap) (inactive)]

Taking because I'm trying to investigate this. At least one interesting portion
of the reflow log is:
       rowG 03894534 d=1650,840
       rowG 03894534 r=2 a=1575,UC c=1575,UC cnt=310

Note that this is from the incremental reflow and that 1650 is the initial size
desired (the one gained from the initial reflow).

Comment 8

[Bernd]

       rowG 03894534 d=1650,840
       rowG 03894534 r=2 a=1575,UC c=1575,UC cnt=310
There are some things that are not written in the reflow log....
namely after the initial reflow the layout strategy happens see
http://www.mozilla.org/newlayout/doc/table-layout.html

Comment 9

[Bernd]

1650 * 0.95 = 1567.5 that makes pixel aligned 1575 twips

Comment 10

[Bernd]

so what happens here is some sort of recursion

give a content desired width  take 0.95 of that if you start on the next cycle
with the current width as the desired width and take again 0.95 of that the
table shrinks. One should look at the maximumWidth (m) in the reflow log.

Comment 11

[Bernd]

and looking again at the testcase I am wondering whether the behaviour changes
if the float:left is removed from the inner table. In theory there should be no
difference in the rendering.

Comment 12

[Bernd]

Blake could you attach the full reflow log (may be splitted as what happens on
load and what happens as a response to pressing the button)?

Comment 13

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: The reflow log

There are 3 reflows in the log, the initial reflow, the reflow on mousedown and
the reflow on mouseup.

Comment 14

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Reflow log of a nonshrinking case (testcase with float: removed)

Comment 15

[Steve England [:stevee]]

Doesn't work:
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006120606 Minefield/3.0a1 [pre-reflow branch landing]
(clicking button results in page layout changing; not expected)

Does work:
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006120804 Minefield/3.0a1 [post-reflow branch landing]
(clicking button results in page layout not changing; expected)

--> RESOLVED FIXED

Comment 16

[Ryan VanderMeulen [:RyanVM]]

Adding in-testsuite? nomination per bz's request in m.d.t.l. Sorry for the bugspam.