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

RESOLVED DUPLICATE of bug 22480

Status

()

Core
HTML: Parser
RESOLVED DUPLICATE of bug 22480
13 years ago
10 years ago

People

(Reporter: thomas, Assigned: mrbkap)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

13 years ago
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.
(Reporter)

Comment 1

13 years ago
Created attachment 200468 [details]
HTML file.
(Reporter)

Comment 2

13 years ago
Created attachment 200469 [details]
The CSS filed used.

 ... 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

Comment 5

12 years ago
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

Comment 6

12 years ago
Created attachment 239401 [details]
Testcase incorrect form closing when unclosed <p>'s are nested

The test case

Comment 7

10 years ago
<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
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 22480
You need to log in before you can comment on or make changes to this bug.