</form> element is being rendered in the wrong location or in some cases ignored and not rendered at all

RESOLVED INVALID

Status

()

Firefox
Untriaged
RESOLVED INVALID
10 months ago
10 months ago

People

(Reporter: itsme@iggit.com, Unassigned)

Tracking

55 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

10 months ago
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170814072924

Steps to reproduce:

Generating dynamically created form elements from Perl script. Form open action and method tag is rendering fine but the </form> element is being ignored in most cases or moved to inside the next <form> set making that one display </form></form>


Actual results:

</form> is being moved or ignored. In Chrome the </form> tag shows up exactly where it was placed.


Expected results:

HTML form elements should be exactly where they are placed.

Comment 1

10 months ago
Can you provide a standalone testcase (a static HTML file) that demonstrates the issue?
Flags: needinfo?(itsme)
(Reporter)

Comment 2

10 months ago
Created attachment 8900438 [details]
FF_V_CHROME.html

A/B comparison FF v Chrome
(Reporter)

Comment 3

10 months ago
(In reply to Tooru Fujisawa [:arai] from comment #1)
> Can you provide a standalone testcase (a static HTML file) that demonstrates
> the issue?

uploaded thank you

Comment 4

10 months ago
I don' see any notable difference when opening the attachment on both browsers.
"DELETE" button is shown on both Google Chrome 60.0.3112.101 and Firefox 55.0.2 (64-bit)

can you upload screenshot of the attachment?
also, does the issue happen on safe mode?
https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode
(Reporter)

Comment 5

10 months ago
(In reply to Tooru Fujisawa [:arai] from comment #4)
> I don' see any notable difference when opening the attachment on both
> browsers.
> "DELETE" button is shown on both Google Chrome 60.0.3112.101 and Firefox
> 55.0.2 (64-bit)
> 
> can you upload screenshot of the attachment?
> also, does the issue happen on safe mode?
> https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-
> mode

the delete button is not the problem it is the closing </form> which is the topic of this discussion
not the button
Flags: needinfo?(itsme)

Comment 6

10 months ago
can you explain how to interpret the testcase?
how can I observe the issue you're having, by opening the attachment?
Flags: needinfo?(itsme)
(Reporter)

Comment 7

10 months ago
(In reply to Tooru Fujisawa [:arai] from comment #6)
> can you explain how to interpret the testcase?
> how can I observe the issue you're having, by opening the attachment?

the attachment is an A/B comparison of html generated, one for chrome one for firefox
they are identical except for the missing </form> in the firefox section
open it in a text editor and you'll see the difference
Flags: needinfo?(itsme)

Comment 8

10 months ago
how do you create the attachment file?

according to the comment #0, the html is generated by Perl script,
where are those browsers related?

maybe you opened the generated html in browser and save it via some feature (like [Save Page As] menu)?
if not, can you explain where the difference is introduced, from the exact same output of the Perl script?
Flags: needinfo?(itsme)

Comment 9

10 months ago
in other words,
what's the output of the Perl script, and what are the steps to reproduce the issue, form the output of the Perl script?
(Reporter)

Comment 10

10 months ago
(In reply to Tooru Fujisawa [:arai] from comment #9)
> in other words,
> what's the output of the Perl script, and what are the steps to reproduce
> the issue, form the output of the Perl script?

these are the output of the perl script! if it was possible to put that script in the open i would but it would not work
the data and all elements are behind htaccess

nut shell: firefox either removes the </form> closing tag or moves it... i'm more concerned with removing it, chrome very same script same routine same data same output has the tag
Flags: needinfo?(itsme)

Comment 11

10 months ago
if the attachment is the raw output of Perl script, why there are 2 variant for Chrome and Firefox?
is the script generating different output for each browser?

I think, it's not the output of Perl script but you somehow opens the output in browsers and somehow retrieves the source, and observing the difference of the "</form>".
please describe the detailed reproduction steps.
Flags: needinfo?(itsme)
(Reporter)

Comment 12

10 months ago
(In reply to Tooru Fujisawa [:arai] from comment #11)
> if the attachment is the raw output of Perl script, why there are 2 variant
> for Chrome and Firefox?
> is the script generating different output for each browser?
> 
> I think, it's not the output of Perl script but you somehow opens the output
> in browsers and somehow retrieves the source, and observing the difference
> of the "</form>".
> please describe the detailed reproduction steps.

where did the variant concept come from? the output is identical there is no detection going on
so what you are saying is it has nothing to do with firefox it is my fault.

go away let someone who cares about this handle it or drop the topic i don't take insults well
Flags: needinfo?(itsme)

Comment 13

10 months ago
you've explained that you have observed the difference of the "</form>" between Firefox and Chrome,
and surely the position is different in the attachment you've posted above.

but if the attachment is the raw output of the Perl script, browsers have nothing to do with the difference.
that's why I think it's not the output of the Perl script.

please answer the following question:
  1. is the Perl script running on a web server?
  2. (if the script is running on web server) you opened the URL of the Perl script in browser, right?
  3. how do you observe the difference of "</form>"?
     if it's inside browser, which feature are you using?
(Reporter)

Comment 14

10 months ago
(In reply to Tooru Fujisawa [:arai] from comment #13)
> you've explained that you have observed the difference of the "</form>"
> between Firefox and Chrome,
> and surely the position is different in the attachment you've posted above.
> 
> but if the attachment is the raw output of the Perl script, browsers have
> nothing to do with the difference.
> that's why I think it's not the output of the Perl script.
> 
> please answer the following question:
>   1. is the Perl script running on a web server?
>   2. (if the script is running on web server) you opened the URL of the Perl
> script in browser, right?
>   3. how do you observe the difference of "</form>"?
>      if it's inside browser, which feature are you using?

by the inability to submit the correct data
1 form is fine doesn't need a close
2nd form submits 1 and 2
3rd form submits 1 2 and 3 and so on . no ending of a specific form all jumbled together because the </form> is permitted to exist once and is moved from its hard coded place to be repeated with each database loaded data set

then opening source in firefox, chrome and safari only firefox reacts that way the other two submit correctly and contain the html form source as it is presented from the server only firefox ignores it

i do believe the culprit is in table rendering somehow i was using tables to display the data as can be seen from the sample attachment, have tossed the tables and gone with fieldsets and the problem stopped in firefox and was not changed in the other two either now all three submit and i'm moving on from this just remembering not to use tables in repeated form presentations

thank you for your kind response

Comment 15

10 months ago
Created attachment 8901017 [details]
TestCase where Heuristic exeptionhandler WORKS

The fixer algorythm for the form works, so I cannot repro on win10.
The form sends the fields as expected, and the </form> element isn't moved.
Note that it is an invalid HTML structure anyway. Although works.

Mozilla/5.0 (Windows NT 10.0; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0

Comment 16

10 months ago
ok, I can repro with function SAVE WEBPAGE (FULL), this saves the code below:

<!DOCTYPE html>
<html><head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8"></head><body>
<table>
  <tbody><tr>
    <td>
      <form method="get">
        <input name="test" value="1" type="hidden">
    </form></td>
  </tr>
</tbody></table>
<input value="Send" type="submit">

</body></html>

Comment 17

10 months ago
Reporter, workaround which is HTML5 ready

<table>
  <tr>
    <td><form method='get' id='myform1'></form></td>
    <td><input type='text'   name='test1' value='test1' form='myform1' /></td>
    <td><input type='text'   name='test2' value='test2' form='myform1' /></td>
    <td><input type='text'   name='test3' value='test3' form='myform1' /></td>
    <td><input type='submit' name='send'  value='Send'  form='myform1' /></td>
  </tr>
  <tr>
    <td><form method='get' id='myform2'></form></td>
    <td><input type='text'   name='test1' value='test4' form='myform2' /></td>
    <td><input type='text'   name='test2' value='test5' form='myform2' /></td>
    <td><input type='text'   name='test3' value='test6' form='myform2' /></td>
    <td><input type='submit' name='send'  value='Send'  form='myform2' /></td>
  </tr>
</table>

The attribute "form" is part of the HTML5 spec. So you should use this nowadays.

Whilst your html structure is invalid, this bug cannot be valid. You figured out the heuristic correction algorythm and tried to apply your webpage to that implementation, but this is not part of the spec.
Anyway we aren't able to repro properly your issue, whilst in your code there is no <tbody> element which is automatically added to the <table> element. See Comment 16. So its different, than your code report.

I suggest you to close this bug as WORKSFORME
(Reporter)

Updated

10 months ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 months ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.