195770 - {inc}Submission form inside table wiggles (moves) making it hard to click on submit button

Status: RESOLVED FIXED

(Core :: Layout: Tables, defect, P3)

Description

[Dave]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030301
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030301

2003030105/Linux-trunk

Whenever I try to click on "Show my bikes" on the page below, the form (which is
inside a table, AFAICT) wriggles out from under my mouse pointer and I have to
be very quick in order to click it... it's almost like the web developer that
made that page made some kind of sick joke, except that I doubt that's the case.

http://www.giant-bicycles.com/us/030.000.000/030.000.099.asp?answerid=8757

The html on the page seems kind of messy and appears to include some overlapping
tables, which might be a problem. However, I don't know enough about what's
valid in html to diagnose myself.



Reproducible: Always

Steps to Reproduce:
1. Go to listed
http://www.giant-bicycles.com/us/030.000.000/030.000.099.asp?answerid=8757 and
try to clik on "Show my bikes"
2. Notice that it's very hard to click on button with form wiggling around.


Actual Results:  
Form wiggles and writhes to keep from being submitted.

Expected Results:  
Form should be good and cooperative and let me submit it with minimal ado.

Comment 1

[Andrew Schultz]

Attachment: testcase

testcase exhibits the problem with linux trunk 20030302
originally, all 4 "foobar"s are on one line.
after clicking the button, all 4 "foobar"s are on separate lines
after mouseup, there are 2 "foobar"s on each of two lines.

Comment 2

[Andrew Schultz]

this seems to actually be a tables bug

==> layout/tables

Comment 3

[:deanis74]

This sounds like 183756 to me.

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

Comment 4

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

Nope.  That bug is definitely specific to positioning.

Comment 5

[:deanis74]

Sorry, my bad.

Comment 6

[Marc Boullet]

http://www.mozilla.org/search.html and clicking the submit button exhibits a
similar behaviour.

Comment 7

[Hermann Schwab]

seeing bug on testcase, so marking OS: ALL
Mozilla Trunk BuildID 2003091704 on Win98

Replacing Original URL, as it doesn´t show the bug,
new URL shows it clearly. Don´t fill anything in, just click 'Search' ;-)

New URL is: http://www.mozilla.org/search.html

Original URL was:
http://www.giant-bicycles.com/us/030.000.000/030.000.099.asp?answerid=8757
doesn´t show the bug, but if I select 'Men's Frame', on submitting I get:

Microsoft OLE DB Provider for SQL Server error '80040e14'

Line 1: Incorrect syntax near 's'.

/general/dbase.asp, line 330

Comment 8

[Hermann Schwab]

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

Comment 9

[Scott Gifford]

Added (moves) to summary.  Users wanting to report this bug aren't likely to
search for "wiggles".

Comment 10

[Bob Hutzel]

I have a cleaned up example of this behavior. Will attach buttonRelocate.html.
I've discovered that removing either width: 50% from the table's style or
leaving the cell font size to the default corrects things. Hope this is helpful.

Testing on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007.

Comment 11

[Bob Hutzel]

Attachment: Cleaned up example of behavior

See my 2003-11-20 12pm EST comment below.

Comment 12

[Hideo Saito]

Attachment: patch

For the testcase, the ReflowChild at nsTableRowFrame::IR_Target gets
cellMet.mMaximumWidth from the width of the submit button, however the
mMaximumWidth of the cellFrame has right value. I think that the value should
be exchanged.

Comment 13

[Hideo Saito]

> I think that the value should be exchanged.
I think that the value should not be exchanged.

Comment 14

[Bernd]

If the block code returns a a wrong cellMet.mMaximumWidth why should the cell
overwrite it? Shouldn't that fixed be in the block code.

Comment 15

[Hideo Saito]

Attachment: patch

With the following code and flow, if the table has percent width and the cell's
colspan is larger than one, the prefWidth is not right value.

nsTableFrame::BalanceColumnWidths(...)
{
  ...
  mTableLayoutStrategy->BalanceColumnWidths(aReflowState);
  ...
  CalcMinAndPreferredWidths(aReflowState, PR_FALSE, minWidth, prefWidth);
  ...
}

nsTableFrame::BalanceColumnWidths
 |
 +-->BasicTableLayoutStrategy::BalanceColumnWidths
 |    |
 |    +-->BasicTableLayoutStrategy::AssignPctColumnWidths
 |    |    |
 |    |    +-->BasicTableLayoutStrategy::ComputeNonPctColspanWidths
 |    | 	|
 |    | 	+-->colFrame->SetWidth(DES_ADJ, WIDTH_NOT_SET);
 |    | 	    (colFrame->mWidth[DES_ADJ] is set to -1)
 |    +-->mTableFrame->SetPreferredWidth(perAdjTableWidth);
 |	  (perAdjTableWidth is right preferred width)
 +-->nsTableFrame::CalcMinAndPreferredWidths
      |
      +-->width = colFrame->GetDesWidth();
	  (width is not right value)

Comment 16

[Bernd]

Can you please attach a reflow log and a analysis what goes wrong there? I
suspect stronlgy that we get a wrong cellMet.mMaximumWidth from the block code.
I know the structure of table reflow so these diagrams lead to nowhere.

Comment 17

[Hideo Saito]

Comment on attachment 166573 [details] [diff] [review]
patch

Sorry, I do not know how to run a reflow log.
My posted patch (attachment 167743 [details] [diff] [review]) to Bug 103582 includes the fix of this
problem.

Comment 18

[Bernd]

I moved and updated the docs for it today
http://www.mozilla.org/newlayout/doc/frame_reflow_debug.html. If you have
problems with the steps in Getting the log just contact me.

Comment 19

[Steve England [:stevee]]

I see no change to the layout of "Cleaned up example of behaviour" 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)

However, with the original testcase, with
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006120606 Minefield/3.0a (pre-reflow branch)
I click the button and the layout changes

With:
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006120804 Minefield/3.0a1 (post-reflow branch)
I click the button and the layout does not change.

Comment 20

[Andrew Schultz]

Indeed.  The cleaned up testcase was apparently a different bug.

Resolving fixed-by-reflow-branch