39209 - Table reflows, shrinks on form input (page reflows on login at Slashdot)

Status: VERIFIED FIXED

(Core :: Layout, defect, P2)

Description

[Jeffrey Baker]

Using the i686-pc-linux-gnu Build 2000051308 at slashdot.org, I can make Moz do
a lot of gratuitous page reflowing.  To reproduce:

1) Start Moz
2) Go to http://slashdot.org/article.pl?sid=00/05/13/1847242&mode=thread
3) Mouseover the "userlogin" button.  Page reflows for no reason.
4) Focus the "Nickname" input.  Page reflows again.
5) Focus the "Password" input.  Page reflows again (not always).
6) Click the "userlogin" button.  Page reflows again.
7) Move the focus between the modal dialog and the main Moz window.  Page
reflows many times, always shifting to the left.

This is 100% reproducible on this build, platform, and URL.  I haven't found
another page that trigger the problem yet.

Comment 1

[karnaze (gone)]

Triage duty calls. Reassinging to pierre.

Comment 2

[Pierre Saslawsky]

I confirm the bug. Problem: the testcase is fairly large and when I try to 
simplify using the 4x Editor, the bug goes away.

Adding 'helpwanted' for the next couple of days: a simpler testcase would be 
nice.

Comment 3

[Pierre Saslawsky]

Btw, the bug is very easy to reproduce by clicking on the "userlogin" button, 
keeping the mouse button pressed and mousing over - in and out - the "userlogin" 
button.

Comment 4

[Jeffrey Baker]

Attachment: Minimal testcase for this bug

Comment 5

[Jeffrey Baker]

I created a minimal testcase to reproduce this bug.  Removing anything from the
testcase makes the bug go away.  In particular, note the interaction between the
fixed width and the alignment of the nested table.

In this testcase, the problem only happens once.  It happens the first time you
mouseover the button.  In the original document, the problem happens repeatedly
as described by Pierre.

Comment 6

[Jeffrey Baker]

Attachment: Slightly more minimal testcase

Comment 7

[Jeffrey Baker]

Silly me.  You can actually remove the fixed width of the nested table, and the
bug is still present.  Even more minimal testcase is attached.

Comment 8

[Blake Ross]

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

Comment 9

[Marc Attinasi]

Blake's testcase is awesome. This really looks like another table reflow bug. 
Chris, can you take another look?

Comment 10

[Pierre Saslawsky]

(That was Jeff's testcase, not Blake's)

I'm going to attach yet another version of that minimal testcase which shows that 
after the mouseover reflow the TABLE containing the FORM has a width of twice 
what would be necessary to display the FORM.

You can also see that the 'left' value of the inner TABLE is (rightfully) used to 
calculate the width of its cell during the initial reflow but *not* after the 
spurious reflow generated by the mouseover.

Comment 11

[Pierre Saslawsky]

Attachment: one more testcase

Comment 12

[karnaze (gone)]

I filed bug 44730 to handle the 3rd attachment and moved it to "future" since it 
deals with relative positioning.

Comment 13

[karnaze (gone)]

Attachment: patch to fix the bug

Comment 14

[karnaze (gone)]

I'm nominating this for beta2 since it will affect any page that has a nested 
table with align=center or a left or right auto margin.

Comment 15

[Jay Patel [:jay]]

Putting on [NEED INFO] radar. PDT needs to know impact to user and risk of fix 
to make a call on this bug. Any top100 sites that show this behavior?  We need 
to know if this is going to be highly visible or not.

Comment 16

[Jay Patel [:jay]]

Putting on [nsbeta2-] radar. Not critical to beta2. 

Comment 17

[jlarsen]

Additional problem seems to have appeared (or I just didn't notice it before)

1. IN URL above if you focus inside the nickname: input box, and start to type
the page reflows on the same manor, except it continously shrinks the middle
column as you type or even as you backspace.

Comment 18

[Dan Mosedale (:dmosedale, :dmose)]

Nominating for nsbeta3 and adding the perf keyword; we are hurting on the perf
front.

Comment 19

[Marc Attinasi]

Approving for nsbeta3

Comment 20

[Jeffrey Baker]

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

Comment 21

[Jeffrey Baker]

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

Comment 22

[Jeffrey Baker]

Changed the description to make this bug easier to find.

Comment 23

[Jeffrey Baker]

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

Comment 24

[sentinel]

Same as bug 29511 ? They seem to have the same symptoms ...

Comment 25

[Jeffrey Baker]

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

Comment 26

[Asa Dotzler [:asa]]

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

Comment 27

[Daniel Veditz [:dveditz]]

Adding nsbeta2 keyword to bugs with nsbeta2 triage value in status field so the 
queries don't get screwed up

Comment 28

[Stephen Koren]

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

Comment 29

[Jeffrey Baker]

en fuego

Comment 30

[Tomer Brisker]

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

Comment 31

[Tomer Brisker]

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

Comment 32

[Asa Dotzler [:asa]]

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

Comment 33

[Blake Ross]

We've had a patch since July; could we please get it checked in?  This bug is 
getting duped daily...(updating summary to help catch some of them)

Comment 34

[Jeffrey Baker]

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

Comment 35

[Jeffrey Baker]

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

Comment 36

[Marc Attinasi]

Chris is on sabbatical: he'll check in the patch when he returns (it is BETA3+)

Comment 37

[buster]

I'll review the patch and if it's ok I'll check it in.

Comment 38

[buster]

the changes here are too big to check in without Chris' help.   Not a 
good use of my time right now.  So, Reassigning back to Chris.  Chris, when you 
get your feet back on the ground, I'll review these changes with you.

Comment 39

[leger]

PDT moving to P2...setting to [PDTP2]

Comment 40

[Blake Ross]

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

Comment 41

[Peter Lubczynski]

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

Comment 42

[karnaze (gone)]

cvs cannot apply the patch even on the versions from which it originally diffed.  

Comment 43

[karnaze (gone)]

This is fixed except for the problem with depressing the "userlogin" button on 
the url (depressing the button on the first two attachments is ok). So, I've 
marked this nsbeta3-. I need a new test case for the remaining problem. Most of 
the bugs marked as duplicates of this are fixed except for the few that mention 
the userlogin button on the slashdot page.

Comment 44

[Francis Fillion]

Hi all, with (2000101015 on linux redhat7.0), I have a little problem that look
like this.

When you enter 3 letter (at http://www.dejanews.com/), the table just go
down a little, maybe 1 millimeter. I isolate the html code for this, it's a
table in a table and then you have the form in the middle, by getting out the
first table it work OK, but with the two table in, it do the little move, all
the form is going down. By looking at the HTML, it didn't look to have any error
in it, so I decided to test it in a w3c html validator and nothing major was found.

So it look like this bug, this was post on an other bug
(http://bugzilla.mozilla.org/show_bug.cgi?id=52649) that I have found who was
corrected, but it still happen to have a little bug in the same form and
[e-mail] just said that maybe it was a duplicate of this one.

Go there to see a minimal test case on which I have send on one of my other bug
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=17607

- enter 3 letters and the form will go down a little.

Comment 45

[Bernd]

Chris, this bug worksforme on all testcases and URL under Win98. I think you can
close the bug. 

Comment 46

[Mike Palczewski]

I have noticed that this also happens on
http://www.google.com
Whenever text is typed into the search box, the text box moves. This is a fairly
small test case, happens on linuxppc,linux x86 and Mac as of 0.7.

Comment 47

[Mike Palczewski]

sorry for the spam

Comment 48

[kmike]

can't reproduce this on reported urls at slashdot.org and all testcases.
but i can confirm reflowing at www.dejanews.com as described by Francis.
not his testcase, though - everything is ok in it.

i've noticed the same reflows at
http://forum.hardware.ru/cgi-ubb/search.cgi?action=intro
type two letters in the first field, and table will move down a few millimeters.
delete them, and table will move back.

i'm using linux 20010128 nightly build.

Comment 49

[djoham]

Here's another example. I'm going to attach an almost (more on this later) HTML
4.01 strict compliant document with CSS compliant styles in a minute.

Notice that when you bring the page up in Mozilla and start clicking alternately
on the radio buttons, Mozilla will (*badly*) reflow the table. The first two or
three times is really bad. After that, we're talking chump change in comparison,
but by that time the layout of the page is completely gone.

The reflow goes away if you take the javascript out that disables the button. It
also goes away if you replace the button with a text box and disable/enable that
instead.

this is mozilla build 2001020108 on Linux kernel 2.2x.

On a side note. I couldn't get the silly HTML validator at w3.org to validate
this doc. It said something about ending the head tag that wasn't finished. I
looked for examples and found stuff on their site that was doing exactly what I
was doing. Anybody have any ideas?

also adding self to cc list

Comment 50

[djoham]

Attachment: test case

Comment 51

[Jeffrey Baker]

The test case is invalid becaue it lacks the mandatory TITLE element, which must
be in the HEAD element.

Comment 52

[djoham]

Cool. Thanks! I had the TITLE in there but figgrd it was not needed to 
demonstrate the test case and got rid of it. Learn something new every day.

Note that the test case is still perfectly valid for demonstrating the table 
reflow problem...

Comment 53

[djoham]

I just tried this bug in W2K build 2001020204 and see almost the same problem as
I do in Linux. The difference is that Linux will badly reflow the table as soon
as you toggle the radio buttons the first time. Windows doesn't reflow badly
until you toggle the radio buttons the second time.


The OS should be marked as all

Comment 54

[Gervase Markham [:gerv]]

Unsetting target milestone - M18 is long past.

Gerv

Comment 55

[karnaze (gone)]

Moving to m0.9

Comment 56

[karnaze (gone)]

I'm closing this bug because the original problem was fixed (as well as most of 
the additional urls mentioned). There are still some outstanding issues raised 
by this bug summarized as follows:

bug 75792 - remaining problem with attachment #2 [details] [diff] [review]
bug 44730 - remaining problem with attachment #3 [details] [diff] [review]
bug 75804 - remaining problem with attachment #5 [details]

Please do not reopen this bug with yet another url. Please file a new bug 
instead.

Comment 57

[Chris Petersen]

Marking verified in the May 30th build.