This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 26309 - Form submission doesn't require form element to be in document, although at least Trident and Gecko have that behavior. Blink submits also not-in-doc forms.
Summary: Form submission doesn't require form element to be in document, although at l...
Status: RESOLVED WORKSFORME
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-11 15:43 UTC by contributor
Modified: 2014-09-18 21:36 UTC (History)
8 users (show)

See Also:

Attachments

Description contributor 2014-07-11 15:43:16 UTC 
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html
Multipage: http://www.whatwg.org/C#sandboxSubmitBlocked
Complete: http://www.whatwg.org/c#sandboxSubmitBlocked
Referrer: http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html

Comment:
Form submission doesn't require form element to be in document, although at
least Trident and Gecko have that behavior. Blink submits also not-in-doc
forms.

Posted from: 91.154.44.207
User agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0
Comment 1 Ian 'Hixie' Hickson 2014-07-15 18:32:47 UTC 
Is there a particular reason we'd want to not submit those? We definitely want to be able to do rAc() on them, so it seems weird to limit the submission. Why not just remove the restriction in Gecko and Trident?
Comment 2 Ian 'Hixie' Hickson 2014-09-03 23:17:45 UTC 
cc'ing Mozilla and Microsoft folk for comment 1.
Comment 3 Jonas Sicking (Not reading bugmail) 2014-09-03 23:40:15 UTC 
I agree that in-document-ness should not affect forms functions in general.

I guess the only argument that I can think of is that it's less obvious which browsing context to navigate when the form is submitted. But defining that it is .ownerDocument.defaultView seems fine. Unless, of course, the form has a target, in which case the target is found by starting at the .ownerDocument.defaultView.

Boris or Olli might have stronger opinions.
Comment 4 Boris Zbarsky 2014-09-03 23:51:23 UTC 
There are a bunch of edge cases here, starting with what happens when the form's owner document is not the current document in its browsing context.

But modulo those being defined sanely, I don't have a problem with out-of-document forms being able to submit, at first glance.
Comment 5 Anne 2014-09-04 09:05:26 UTC 
No strong opinions, but make sure it makes sense for HTML imports, shadow tree, XMLHttpRequest, etc.
Comment 6 Olli Pettay 2014-09-04 11:54:45 UTC 
The reason for Gecko's behavior is ancient, but it was done
on purpose
https://bugzilla.mozilla.org/show_bug.cgi?id=28988#c17
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla%2Fcontent%2Fhtml%2Fcontent%2Fsrc%2FAttic%2FnsFormSubmitter.cpp&rev=&cvsroot=%2Fcvsroot&mark=265-266#250
(Not saying anything about whether the reasoning was good.)

But if not-in-doc behavior can be defined properly, I'm not against.
Comment 7 Ian 'Hixie' Hickson 2014-09-04 18:30:41 UTC 
It would basically be defined to be equivalent to inserting it into the documentElement of its ownerDocument, and then submitting it. This covers all the edge cases above (e.g. the document not being active). (Obviously it wouldn't be quite in those terms, but the effect would be equivalent.)

smaug: interesting, thanks.

I guess I'll go ahead and define this to submit. Adrian, please do comment if you would rather we not do that!
Comment 8 Ian 'Hixie' Hickson 2014-09-18 21:36:30 UTC 
Resolving as per comment 7 (the spec allows form submission from a form not in a document). Let me know if you find a reason to change this after all. Thanks!