Closed Bug 276104 Opened 20 years ago Closed 19 years ago

{incr} fieldset barfs on content insert

Categories

(Core :: Layout: Form Controls, defect)

x86
All
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: e7online, Assigned: MatsPalmgren_bugz)

References

Details

(Keywords: testcase)

Attachments

(4 files, 2 obsolete files)

Here is a simple HTML formular, and you can add more upload fields if you need
more. The first click can be done, but after this I can't click on the link anymore.

<html><head></head><body>
<h1>Example HTML</h1>
<script type="text/javascript">
function adduploadform() {
	var a;
	a = document.getElementById('e_fileupload').innerHTML;
	a = a + "<input type=\"file\" name=\"u_upload[]\"/><br/>";
	document.getElementById('e_fileupload').innerHTML = a;
}
</script>
<fieldset id="e_fileupload"><legend>Attatchment</legend><br/>
	<a href="javascript:adduploadform();">New file</a><br/>
</fieldset>
</form>
</body></html>
Severity: normal → minor
This is not a JavaScript Engine bug.  That bugzilla component is for bugs in the
core ECMA-262 language implementation, not in the DOM or HTML engines.

/be
Assignee: general → general
Component: JavaScript Engine → DOM: Level 0
QA Contact: pschwartau → ian
Attached file Testcase from reporter
I'm seeing the bug, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041224
Firefox/1.0+
Replacing the fieldset with a div fixes the testcase. The incr. reflow for the
fieldset is somehow broken. It does not properly invalidate the upper border
neither does it paint the content at the right place. Please note that one can
click the link just at the lower edge of that link. Loading the testcase into
the DOM inspector reveals where mozilla thinks the parts should be.
Assignee: general → nobody
Status: UNCONFIRMED → NEW
Component: DOM: Level 0 → Layout: Form Controls
Ever confirmed: true
Keywords: testcase
QA Contact: ian → core.layout.form-controls
Summary: Link cannot be clicked after inserting HTML by javascript → {incr} fieldset barfs on content insert
Depends on: 70648, 236071
This causes a crash using the testcase:
1. load testcase and click on the "New file" link
2. resize the window wildly - make it very narrow and then wider again.

Taking bug - I have a patch that fixes this and it also fixes the assertion
in bug 70648 comment 20.
Assignee: nobody → mats.palmgren
Severity: minor → critical
Blocks: 212887
Blocks: 276043
Attached file Testcase #2
Attached patch Patch rev. 1 (obsolete) — Splinter Review
There were many bugs in there...
(make sure you have bug 236071 before you run this patch)
Attached patch Patch rev. 1 (diff -w) (obsolete) — Splinter Review
Attachment #170075 - Flags: superreview?(dbaron)
Attachment #170075 - Flags: review?(bzbarsky)
Comment on attachment 170075 [details] [diff] [review]
Patch rev. 1

> nsFieldSetFrame::AppendFrames(nsPresContext* aPresContext,

> nsFieldSetFrame::InsertFrames(nsPresContext* aPresContext,

I think the duplicated code here should be factored out somehow.

All the methods operating on mLegendFrame when munging frame lists probably
need to assert that aListName is null, no?

Other than those, looks fine.  r=bzbarsky
Attachment #170075 - Flags: review?(bzbarsky) → review+
Blocks: 271419
Attached patch Patch rev. 2Splinter Review
Addressing Boris' comment 8:
Added new method to share the common legend code in Insert/AppendFrames.
Assert that aListName is null when manipulating 'mFrames'.

Also, return the result of 'mContentFrame->AppendFrames()'.
Attachment #170075 - Attachment is obsolete: true
Attachment #170076 - Attachment is obsolete: true
Attachment #171427 - Flags: superreview?(dbaron)
Attachment #170075 - Flags: superreview?(dbaron)
Flags: blocking1.8b?
Comment on attachment 171427 [details] [diff] [review]
Patch rev. 2

rubber-stamp sr=dbaron
Attachment #171427 - Flags: superreview?(dbaron) → superreview+
Checked in 2005-01-24 16:06 PDT.

-> FIXED
Status: NEW → RESOLVED
Closed: 19 years ago
Flags: blocking1.8b?
Resolution: --- → FIXED
*** Bug 280020 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: