[HtmlUnit] [htmlunit:bugs] #1630 form_owner incorrect when <form> are malformed
RBRi via HtmlUnit-develop <[email protected]> Thu, 02 Feb 2023 06:17:54 -0000
| Newsgroups | gmane.comp.java.htmlunit.devel |
|---|---|
| Message-ID | </p/htmlunit/bugs/1630/041d19b8fe0687fbf4ebaf19cbbd2d4a6aaf637a.bugs@htmlunit.p.sourceforge.net> |
This is a multi-part message in MIME format.
--===============2590339141887791516==
Content-Type: multipart/related; boundary="===============7372693961769026039=="
This is a multi-part message in MIME format.
--===============7372693961769026039==
Content-Type: multipart/alternative; boundary="===============2084412974335940483=="
MIME-Version: 1.0
--===============2084412974335940483==
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Fixed in 2.71.0
---
** [bugs:#1630] form_owner incorrect when <form> are malformed**
**Status:** open
**Group:** Latest SVN
**Created:** Mon Aug 04, 2014 09:16 AM UTC by Atsushi Nakagawa
**Last Updated:** Sat Sep 06, 2014 06:50 PM UTC
**Owner:** nobody
**Attachments:**
- [consumed1-div.html](https://sourceforge.net/p/htmlunit/bugs/1630/attachment/consumed1-div.html) (308 Bytes; text/html)
- [consumed1.html](https://sourceforge.net/p/htmlunit/bugs/1630/attachment/consumed1.html) (312 Bytes; text/html)
- [consumed2.html](https://sourceforge.net/p/htmlunit/bugs/1630/attachment/consumed2.html) (398 Bytes; text/html)
- [doc-order1-div.html](https://sourceforge.net/p/htmlunit/bugs/1630/attachment/doc-order1-div.html) (308 Bytes; text/html)
- [doc-order1.html](https://sourceforge.net/p/htmlunit/bugs/1630/attachment/doc-order1.html) (312 Bytes; text/html)
- [dom-tree1.html](https://sourceforge.net/p/htmlunit/bugs/1630/attachment/dom-tree1.html) (619 Bytes; text/html)
- [dom-tree2.html](https://sourceforge.net/p/htmlunit/bugs/1630/attachment/dom-tree2.html) (700 Bytes; text/html)
- [f1.html](https://sourceforge.net/p/htmlunit/bugs/1630/attachment/f1.html) (40 Bytes; text/html)
- [f2.html](https://sourceforge.net/p/htmlunit/bugs/1630/attachment/f2.html) (40 Bytes; text/html)
Unlike the recently closed [#1621], this problem isn't a regression and has existed at least as far back as 2.12.
**Summary:**
Owner forms returned by HtmlUnit do not match conventional browsers in certain cases when `<form></form>`s aren't aligned with the DOM tree.
For example, the following incorrectly returns `"f1"` when `HtmlElement.getEnclosingForm()` is called on the `f2_submit` element. Chrome/IE11/Firefox returns `"f2"`:
~~~~~~
<html>
<body>
<div>
<form name="f1" action="f1.html" method="GET">
<table>
<input type="submit" name="f1_submit" value="expect f1"/>
</form>
<form name="f2" action="f2.html" method="GET">
</table>
</div>
<input type="submit" name="f2_submit" value="expect f2"/>
</form>
</body>
</html>
~~~~~~
---
After some testing in Chrome/IE11/Firefox, owner forms seem to be determined by these three rules:
**1. Document order pure and simple. (Completely ignoring the DOM heirachy):**
~~~~~~
<html>
...
<form name="f1">
... everything in between belongs to f1 ...
</form>
...
<form name="f2">
... everything here and belongs to f2 ... (missing </form> so until the end of document)
~~~~~~
**2. Anything not encompassed between `<form>...</form>`, in document order, belong to the closest DOM-tree ancestor if any.**
~~~~~~
<html>
...
<form name="f1">
... everything here belongs to f1 ...
<div>
... everything here belongs to f1 ...
</form>
... things here belong to f1 because DOM-tree is `<form><div></div></form>` ...
</div>
...
~~~~~~
**3. `<form>`s within `<form>`s simply cease to exist. (This is also determined by document order pure and simple.)**
~~~~~~
<html>
...
<form name="f1">
... everything in between belongs to f1 ...
<form name="f2">
... everything in between belongs to f1 ...
</form><!--This actually closed f1's document-order enclosure-->
... things here belong to no one ...
</form>
... things here belong to no one ...
~~~~~~
---
**Conclusion:** 1 and 3 seem to happen with no regards to the DOM tree and it doesn't seem to matter how whacky and nested the surrounding `<element>` and `</element>` placements are. Even though `<form>` nesting is not allowed *in document order*, it can be nested in the resulting DOM tree.
---
Sent from sourceforge.net because [email protected] is subscribed to https://sourceforge.net/p/htmlunit/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/htmlunit/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
--===============2084412974335940483==
MIME-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit
<div class="markdown_content"><p>Fixed in 2.71.0</p>
<hr/>
<p><strong> <a class="alink" href="https://sourceforge.net/p/htmlunit/bugs/1630/">[bugs:#1630]</a> form_owner incorrect when <form> are malformed</strong></p>
<p><strong>Status:</strong> open<br/>
<strong>Group:</strong> Latest SVN<br/>
<strong>Created:</strong> Mon Aug 04, 2014 09:16 AM UTC by Atsushi Nakagawa<br/>
<strong>Last Updated:</strong> Sat Sep 06, 2014 06:50 PM UTC<br/>
<strong>Owner:</strong> nobody<br/>
<strong>Attachments:</strong></p>
<ul>
<li><a class="" href="https://sourceforge.net/p/htmlunit/bugs/1630/attachment/consumed1-div.html">consumed1-div.html</a> (308 Bytes; text/html)</li>
<li><a class="" href="https://sourceforge.net/p/htmlunit/bugs/1630/attachment/consumed1.html">consumed1.html</a> (312 Bytes; text/html)</li>
<li><a class="" href="https://sourceforge.net/p/htmlunit/bugs/1630/attachment/consumed2.html">consumed2.html</a> (398 Bytes; text/html)</li>
<li><a class="" href="https://sourceforge.net/p/htmlunit/bugs/1630/attachment/doc-order1-div.html">doc-order1-div.html</a> (308 Bytes; text/html)</li>
<li><a class="" href="https://sourceforge.net/p/htmlunit/bugs/1630/attachment/doc-order1.html">doc-order1.html</a> (312 Bytes; text/html)</li>
<li><a class="" href="https://sourceforge.net/p/htmlunit/bugs/1630/attachment/dom-tree1.html">dom-tree1.html</a> (619 Bytes; text/html)</li>
<li><a class="" href="https://sourceforge.net/p/htmlunit/bugs/1630/attachment/dom-tree2.html">dom-tree2.html</a> (700 Bytes; text/html)</li>
<li><a class="" href="https://sourceforge.net/p/htmlunit/bugs/1630/attachment/f1.html">f1.html</a> (40 Bytes; text/html)</li>
<li><a class="" href="https://sourceforge.net/p/htmlunit/bugs/1630/attachment/f2.html">f2.html</a> (40 Bytes; text/html)</li>
</ul>
<p>Unlike the recently closed <a class="alink strikethrough" href="https://sourceforge.net/p/htmlunit/bugs/1621/">[#1621]</a>, this problem isn't a regression and has existed at least as far back as 2.12.</p>
<p><strong>Summary:</strong><br/>
Owner forms returned by HtmlUnit do not match conventional browsers in certain cases when <code><form></form></code>s aren't aligned with the DOM tree.</p>
<p>For example, the following incorrectly returns <code>"f1"</code> when <code>HtmlElement.getEnclosingForm()</code> is called on the <code>f2_submit</code> element. Chrome/IE11/Firefox returns <code>"f2"</code>:</p>
<div class="codehilite"><pre><span></span><code><span class="nt"><html></span>
<span class="nt"><body></span>
<span class="w"> </span><span class="nt"><div></span>
<span class="nt"><form</span><span class="w"> </span><span class="na">name=</span><span class="s">"f1"</span><span class="w"> </span><span class="na">action=</span><span class="s">"f1.html"</span><span class="w"> </span><span class="na">method=</span><span class="s">"GET"</span><span class="nt">></span>
<span class="w"> </span><span class="nt"><table></span>
<span class="w"> </span><span class="nt"><input</span><span class="w"> </span><span class="na">type=</span><span class="s">"submit"</span><span class="w"> </span><span class="na">name=</span><span class="s">"f1_submit"</span><span class="w"> </span><span class="na">value=</span><span class="s">"expect f1"</span><span class="nt">/></span>
<span class="nt"></form></span>
<span class="nt"><form</span><span class="w"> </span><span class="na">name=</span><span class="s">"f2"</span><span class="w"> </span><span class="na">action=</span><span class="s">"f2.html"</span><span class="w"> </span><span class="na">method=</span><span class="s">"GET"</span><span class="nt">></span>
<span class="w"> </span><span class="nt"></table></span>
<span class="w"> </span><span class="nt"></div></span>
<span class="w"> </span><span class="nt"><input</span><span class="w"> </span><span class="na">type=</span><span class="s">"submit"</span><span class="w"> </span><span class="na">name=</span><span class="s">"f2_submit"</span><span class="w"> </span><span class="na">value=</span><span class="s">"expect f2"</span><span class="nt">/></span>
<span class="nt"></form></span>
<span class="nt"></body></span>
<span class="nt"></html></span>
</code></pre></div>
<hr/>
<p>After some testing in Chrome/IE11/Firefox, owner forms seem to be determined by these three rules:</p>
<p><strong>1. Document order pure and simple. (Completely ignoring the DOM heirachy):</strong></p>
<div class="codehilite"><pre><span></span><code><span class="nt"><html></span>
...
<span class="nt"><form</span><span class="w"> </span><span class="na">name=</span><span class="s">"f1"</span><span class="nt">></span>
...<span class="w"> </span>everything<span class="w"> </span>in<span class="w"> </span>between<span class="w"> </span>belongs<span class="w"> </span>to<span class="w"> </span>f1<span class="w"> </span>...
<span class="nt"></form></span>
...
<span class="nt"><form</span><span class="w"> </span><span class="na">name=</span><span class="s">"f2"</span><span class="nt">></span>
...<span class="w"> </span>everything<span class="w"> </span>here<span class="w"> </span>and<span class="w"> </span>belongs<span class="w"> </span>to<span class="w"> </span>f2<span class="w"> </span>...<span class="w"> </span>(missing<span class="w"> </span><span class="nt"></form></span><span class="w"> </span>so<span class="w"> </span>until<span class="w"> </span>the<span class="w"> </span>end<span class="w"> </span>of<span class="w"> </span>document)
</code></pre></div>
<p><strong>2. Anything not encompassed between <code><form>...</form></code>, in document order, belong to the closest DOM-tree ancestor if any.</strong></p>
<div class="codehilite"><pre><span></span><code><span class="nt"><html></span>
...
<span class="nt"><form</span><span class="w"> </span><span class="na">name=</span><span class="s">"f1"</span><span class="nt">></span>
...<span class="w"> </span>everything<span class="w"> </span>here<span class="w"> </span>belongs<span class="w"> </span>to<span class="w"> </span>f1<span class="w"> </span>...
<span class="nt"><div></span>
...<span class="w"> </span>everything<span class="w"> </span>here<span class="w"> </span>belongs<span class="w"> </span>to<span class="w"> </span>f1<span class="w"> </span>...
<span class="nt"></form></span>
...<span class="w"> </span>things<span class="w"> </span>here<span class="w"> </span>belong<span class="w"> </span>to<span class="w"> </span>f1<span class="w"> </span>because<span class="w"> </span>DOM-tree<span class="w"> </span>is<span class="w"> </span>`<span class="nt"><form><div></div></form></span>`<span class="w"> </span>...
<span class="nt"></div></span>
...
</code></pre></div>
<p><strong>3. <code><form></code>s within <code><form></code>s simply cease to exist. (This is also determined by document order pure and simple.)</strong></p>
<div class="codehilite"><pre><span></span><code><span class="nt"><html></span>
...
<span class="nt"><form</span><span class="w"> </span><span class="na">name=</span><span class="s">"f1"</span><span class="nt">></span>
...<span class="w"> </span>everything<span class="w"> </span>in<span class="w"> </span>between<span class="w"> </span>belongs<span class="w"> </span>to<span class="w"> </span>f1<span class="w"> </span>...
<span class="nt"><form</span><span class="w"> </span><span class="na">name=</span><span class="s">"f2"</span><span class="nt">></span>
...<span class="w"> </span>everything<span class="w"> </span>in<span class="w"> </span>between<span class="w"> </span>belongs<span class="w"> </span>to<span class="w"> </span>f1<span class="w"> </span>...
<span class="nt"></form></span><span class="cm"><!--This actually closed f1's document-order enclosure--></span>
...<span class="w"> </span>things<span class="w"> </span>here<span class="w"> </span>belong<span class="w"> </span>to<span class="w"> </span>no<span class="w"> </span>one<span class="w"> </span>...
<span class="nt"></form></span>
...<span class="w"> </span>things<span class="w"> </span>here<span class="w"> </span>belong<span class="w"> </span>to<span class="w"> </span>no<span class="w"> </span>one<span class="w"> </span>...
</code></pre></div>
<hr/>
<p><strong>Conclusion:</strong> 1 and 3 seem to happen with no regards to the DOM tree and it doesn't seem to matter how whacky and nested the surrounding <code><element></code> and <code></element></code> placements are. Even though <code><form></code> nesting is not allowed <em>in document order</em>, it can be nested in the resulting DOM tree.</p>
<hr/>
<p>Sent from sourceforge.net because [email protected] is subscribed to <a href="https://sourceforge.net/p/htmlunit/bugs/">https://sourceforge.net/p/htmlunit/bugs/</a></p>
<p>To unsubscribe from further messages, a project admin can change settings at <a href="https://sourceforge.net/p/htmlunit/admin/bugs/options.">https://sourceforge.net/p/htmlunit/admin/bugs/options.</a> Or, if this is a mailing list, you can unsubscribe from the mailing list.</p></div>
--===============2084412974335940483==--
--===============7372693961769026039==--
--===============2590339141887791516==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
--===============2590339141887791516==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
HtmlUnit-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/htmlunit-develop
--===============2590339141887791516==--