Closed Bug 313418 Opened 19 years ago Closed 17 years ago

Wrong DOM-tree with <form> and <button> elements.

Categories

(Core :: DOM: HTML Parser, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 22480

People

(Reporter: thomas, Assigned: mrbkap)

Details

Attachments

(3 files)

User-Agent: Mozilla/5.0 (X11; U; Linux i686; pt-BR; rv:1.8b5) Gecko/20051006 Firefox/1.4.1 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; pt-BR; rv:1.8b5) Gecko/20051006 Firefox/1.4.1 There are three forms with <form ...> <input .../> . . <button type="submit" class="DummyButton"/> </form>. Only the first form is shown in the browser window. Inspecting the DOM-tree shows, that the two other forms are child elements of the button of the first form. The Page info displays the first form alright, the other two forms have only there names displayed. Reproducible: Always Steps to Reproduce: 1. Open the file I'll send in an attachment. 2. Look into DOM-Inspector and Page info. Actual Results: Only the forms without <button ../> and the first form with the <button ...> is displayed. Expected Results: Display all forms. In the DOM-tree, the other forms should also be connected to the parent of the first form, not to the <button ..>. Mozilla 1.8b Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050217 and Firefox/1.0.6 Mozilla/5.0 (X11; U; Linux i686; es-AR; rv:1.7.10) Gecko/20050717 reacts in the same way.
Attached file HTML file. (deleted) —
Attached file The CSS filed used. (deleted) —
... but it's the same without this CSS file.
Could this bug be related/duplicate to bug 313327 ??
Could a bug the reporter says he sees in 1.0.6 be a duplicate of an hours-old trunk-only regression? I sure don't think so. Thomas: if you are doing that for anything other than testing error-recovery in parsers, don't do that. Unless you are serving XHTML as application/xhtml+xml you don't get XML parsing, and /> doesn't close an element. In HTML, <input> is an empty element, but <button> is not, and must have a </button> to close it. Whether we should be closing it, I dunno. IE6 apparently closes <button> when it sees another <button>: it shows only two forms, but both buttons. Opera 8.5 looks to be closing it with the </form>: it shows all three forms and both buttons.
Assignee: nobody → mrbkap
Component: General → HTML: Parser
Product: Firefox → Core
QA Contact: general → parser
Version: unspecified → Trunk
I'm not sure how this bug system works, but I ran into a comparable bug today. When using an implicitly closed <p> tag within a form it will not be closed by the </form> tag. Instead the form will get expanded 'till the point firefox thinks the <p> should close. In my case the form incorporated another form, messing up functionality. Since this happens on documents that pass the W3C validator for HTML4.01 I think this is bug. The quick workaround is to close the <p> tag explicitly within the form (but before you've figured that out....) FF: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6 (Debian-1.5.dfsg+1.5.0.6-4) I'll add a test case
The test case
<button/> part of this bug is invalid. The <p>/<form> thing is Bug 22480. Sadly some HTML4.01 just isn't defined clearly enough. Gladly, HTML5 will change this situation.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: