111502 - Form values are submitted even if they don't exist anymore

Status: VERIFIED DUPLICATE of bug 98487

(Core :: DOM: Core & HTML, defect)

Description

[Jim MacGowan]

This bug only affects Mozilla 0.9.6

I am using DOM to add and remove groups of hidden INPUT fields. If I remove one
or more of these DOM created INPUT fields. The values are still submitted to the
next page.

I would think this is caused by the the changes made in 0.9.6 that allow form
fields on hidden layers to be submitted to the next page.

To test it. Try deleting one of the rows then submit the page. You should not
see the deleted form values in the submitted form variables list. The page works
on IE and earlier versions of Mozilla (pre-0.9.6).

Comment 1

[Boris Zbarsky [:bzbarsky]]

ccing jkeiser in case he decides that I'm actually on crack...

That hostname does not resolve for me so I cannot look at the testcase.  But if
you're calling removeChild on an ancestor of the <input> instead of the input
itself then this is "removeChild of form's child does not clear form pointer of
descendant controls".  Marking duplicate; please reopen if I've misunderstood
the situation.

*** This bug has been marked as a duplicate of 98487 ***

Comment 2

[Jim MacGowan]

Sorry about the URL not working. I am having problems with my primary DNS
server. For now you can get to the test page using
http://24.72.9.177/testdom1.php. If that doesn't work for you, I have also
posted it at http://www.jump.ca/testdom1.php.

I am actually using deleteRow to remove a table row that includes INPUTs. I
wouldn't think an INPUT value should still exist even after the table row it
resides in, doesn't exist anymore. So I have reopened the bug. Hopefully you can
use my test page to get a better understanding of the problem.

I really hope this isn't the proper behavior for a W3C DOM deleteRow. I am going
to have to add a bunch of useless code, clearing values, just to work around
this. It will also create another coding difference between Moz/NS and IE.

Comment 3

[John Keiser (jkeiser)]

It sounds to me like bz is probably right.  That other bug shows "ghost
elements" staying around when you remove form controls by removing their parents
(which is what you're doing).

Resolving a bug as duplicate doesn't mean "it's not a bug," it just means "this
other bug is the same problem."

In terms of the testcase, I suggest you make the form a GET form and attach the
testcase as HTML, if possible ... we can look at the parameters that appear in
the URL.

Comment 4

[Jim MacGowan]

Attachment: add/edit/delete DOM rows test

Same page as the URL except it is using a GET form and does not include any PHP
code.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Yep.  Definitely the same bug.

It doesn't matter whether you removeChild() or deleteRow().  The point is that
you are removing a node that is

1)  a descendant of the form
2)  an ancestor of some input elements.

> I really hope this isn't the proper behavior for a W3C DOM deleteRow

No, it's not.  It's a bug.  :)  It should also be fixed within 3 weeks or so --
we have an approach that should fix it, now we just need to implement it.

Re-marking duplicate; you'll automatically get mail when anything happens to the
bug this is a duplicate of.

*** This bug has been marked as a duplicate of 98487 ***

Comment 6

[Vladimir Ermakov]

verifying