Closed Bug 252200 Opened 20 years ago Closed 20 years ago

clicking the submit button causes the entire form's layout to resize ... makes it wider, breaks visual page layout.

Categories

(Core :: Layout: Form Controls, defect)

Product:
Core
Component:
Layout: Form Controls
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: eepstein, Unassigned)

References

(
URL
)

Details

(Keywords: regression)

Attachments

(1 file)

Testcase
340 bytes, text/html
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1

Go to the mentioned URL.  click the "submit request" button.  See the form be
resized!  Note the upper nav bar now gets wider!  To see this more dramatically
click, but do not release on the "submit" button.  While clicked drag the mouse
back-and-forth over the button... the page grows wider and wider!

Reproducible: Always
Steps to Reproduce:
1.  Go to URL.
2.  Click on submit button but do not release (or do release... but the problem
is more dramatic if you don't release and go to step #3).
3.  Drag mouse back-and-forth over "submit" button.

Actual Results:  
Form gets visually wider. 

Expected Results:  
Form should not change size.
Attached file Testcase — 
Removing this makes it work:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
   "http://www.w3.org/TR/html4/loose.dtd">

Also, removing 'style="width:100%;"' makes it work.
-> layout
Assignee: form-submission → nobody
Component: HTML: Form Submission → Layout: Form Controls
QA Contact: core.layout.form-controls
Status: UNCONFIRMED → NEW
Ever confirmed: true
WFM, current trunk CVS, Linux.
worksforme on current trunk as well.  Didn't roc fix something like this recently?
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a3) Gecko/20040720
seeing this on testcase in browser and DOM-Inspector

textarea visually grows 4px on mousedown and 4px on mouseup,
afterwards seen as 8px growth in width in DOM-Inspectors Object - Box Model

width of
table       : 317 325 333 341 ..
tbody,tr,td : 313 321 329 337 ..
div,textarea: 315 323 331 339 ..

TD       : box width: 313px; padding-left: 1px;      padding-right: 1px;
TEXTAREA : box width: 315px; border-left:  2px inset; border-right: 2px inset;

I then tried to change the border from 2px to 1px in forms.css using
DOM-Inspector, but I gat an Exclamation mark and no display of edit results, so
i reloaded testcase in inspector (inspect) and saw the submit button only, not
the textarea as it didn´t show a border.

width of TD was 313 as before, width of DIV and TEXTAREA shrinked to 311px, and
didn´t grow on submitting.
wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a1) Gecko/20040520
so must have regressed after 1.8a1 release

Re: DOM-Inspector
I don´t feel fit to file a bug on that.
I´ve got an exe Release installed, and use nightlies from zip directories, also
for investigating here.
Is the reason the edit window of DOMinspector broke when I tried to edit the CSS
rule for textarea, that I´m using zip builds?

replacing URL
http://testing.veritablevegetable.com/Our%20Services/Customers/CurrentCustomers/DonationRequest.php
with testcase
URL: http://testing.veritablevegetable.com... → http://bugzilla.mozilla.org/attachmen...
Summary: clicking the sumbit button causes the entire form's layout to resize ... makes it wider, breaks visual page layout. → clicking the submit button causes the entire form's layout to resize ... makes it wider, breaks visual page layout.
wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a2) Gecko/20040529
wfm BuildID 2004052921 
regressed 2004060217

regression seems to be a sign error
DIV is in a TD width 313px + padding left/right 1 px
DIV has in working builds a width of 311, in the failing builds a width of 315
Keywords: regression
Regression Timeframe 1 day
BuildId 2004053108 working, BuildId 2004060108 regressed 
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-05-31+06%3A00&maxdate=2004-06-01+10%3A00&cvsroot=%2Fcvsroot

just an uneducated guess: Bug 217527 

2004-05-31 10:41 dbaron%dbaron.org
mozilla/layout/html/base/src/nsBlockFrame.cpp 	3.625
When we do two passes on an incremental reflow in order to update maximum width,
do max-element-width calculation on the second pass too so that floats have
their max-element-width cached for state recovery. b=217527 r+sr=roc

but there are more candidates in the list.
The testcase WFM using Mozilla nightly 2004091804 on Windows XP
wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a4) Gecko/20040914

feel free to reopen if you still see the bug on a current nightly.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: