Open Bug 335567 Opened 15 years ago Updated 2 years ago
Alternate Content To OBJECT should not participate in HTTP POST
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/20060308 Firefox/184.108.40.206 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11) Gecko/20060308 Firefox/18.104.22.168 Alternate content such as form controls should not participate in the HTTP POST if the <object> can be rendered. In this example, if logo.gif can be rendered, then data from <textarea> should not be send to the server: <object data="logo.gif" type="image/gif" width="180" height="60"> <textarea id="abc" name="abc" rows="5" cols="70">Hello World!</textarea> </object> Here is a test case for the above example: http://misc.xstandard.com/mozilla/alternate-content1.asp This bug is causing serious problems for us. We produce a Firefox plug-in that uses the following construct: <object name="abc" type="application/x-xstandard"> <param name="Value" value="some text" /> <textarea name="abc">more text</textarea> </object> In the above example, data is sent to the server from both our plug-in (correct) and the alternate content (incorrect). Reproducible: Always Steps to Reproduce: 1. Create an object element that can be rendered by the browser 2. Add a form element as alternate content to the object element 3. Submit the form Actual Results: Data is sent from the alternate content to the server. Expected Results: No data should be sent to the server from alternate content if the object can be rendered.
Where does the HTML spec say that such content shouldn't be submitted?
Assignee: nobody → form-submission
Component: General → HTML: Form Submission
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → Trunk
FYI, Opera 9 does not post data from alternate content. And neither does IE.
Just use different names for the two controls.
(In reply to comment #4) > Just use different names for the two controls. but that's hardly the point, is it? if the object has rendered, the fallback (which is provided as an alternative, in case the object couldn't be rendered) shouldn't submit, imho.
this is invalid per html5
Assignee: form-submission → nobody
QA Contact: ian → form-submission
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.