Closed
Bug 252200
Opened 21 years ago
Closed 21 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)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: eepstein, Unassigned)
References
()
Details
(Keywords: regression)
Attachments
(1 file)
|
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.
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
|
||
Comment 4•21 years ago
|
||
worksforme on current trunk as well. Didn't roc fix something like this recently?
|
||
Comment 5•21 years ago
|
||
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.
|
|
||
Comment 6•21 years ago
|
||
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
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.
|
|
||
Comment 7•21 years ago
|
||
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
|
|
||
Comment 8•21 years ago
|
||
Regression Timeframe 1 day
BuildId 2004053108 working, BuildId 2004060108 regressed
|
|
||
Comment 9•21 years ago
|
||
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.
|
||
Comment 10•21 years ago
|
||
The testcase WFM using Mozilla nightly 2004091804 on Windows XP
|
|
||
Comment 11•21 years ago
|
||
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: 21 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•