188938 - Object should submit (name attribute on <object>)

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, enhancement, P3)

Description

[John Keiser (jkeiser)]

According to the HTML4 spec, <object> in a form is supposed to submit. 
Presumably this is to support the creation of new form controls using <object>
(like, for example, a slider).

http://www.w3.org/TR/html401/interact/forms.html#object-control

http://www.w3.org/TR/html401/interact/forms.html#successful-controls
"The current value of an object control is determined by the object's
implementation."

As noted in bug 178341, <object> in IE always submits the value "[object]". 
This is incredibly useless and (IMO) not worthd duplicating.  We need to
actually be able to have the plugin give us the value to be submitted (or
possibly even multiple name/value pairs).

Comment 1

[John Keiser (jkeiser)]

*** Bug 178341 has been marked as a duplicate of this bug. ***

Comment 2

[Boris Zbarsky [:bzbarsky]]

Note that an <object> _does_ have a well-defined name attribute and .name property.

Comment 3

[Peter Lubczynski]

we probably need to extend the plugin API to query the plugin for what
name/value pairs it would like to submit...

Comment 4

[Stanimir Stamenkov]

I don't think a single OBJECT element should "generate" multiple {name:value}
pairs. A single OBJECT element with 'name' specified should represent a single
named form control (/successful control/ valid for submition) with value
depending on the implementation. I suppose when the object is of unknown type
and there's no plug-in to handle it the value should fallback to some default
value (like already mentioned "[object]" or just empty string). If there's
plug-in to handle it and 'name' is specified there should be API to query the
plug-in for value.

Comment 5

[Andrew Goodale]

There's a Microsoft Knowledgebase article on how IE supports this for ActiveX
controls: Article #Q172064
http://support.microsoft.com/default.aspx?scid=kb%3ben-us%3b172064

IE indeed only supports one named value for an ActiveX control.

Comment 6

[Andrew Goodale]

For those who don't know, the "default property" of an ActiveX control is a
property on the control's IDispatch interface which has a DISPID of zero
(DISPID_VALUE in C++). 

An analagous implementation for Mozilla might be to have a special named
property in a plugin's XPIDL interface, but you may want to consider adding
another well-defined "NPPVariable" type for NPP_GetValue. That way, plugins that
don't have or need an XPIDL interface can support this.

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 257543 has been marked as a duplicate of this bug. ***

Comment 8

[Vlad Alexander]

We are porting a popular ActiveX plug-in to Mozilla using the new scriptable
NPAPI. The plug-in needs to post data to the server. We don't want to put
Mozilla users at a disadvantage by having them use JavaScript/hidden field
approach, especially when IE can do this without resorting to client-side
script. This is a good opportunity to add this feature to Mozilla in time for
the release of scriptable NPAPI.

Also, just like IE, the control should only submit a single name/value pair.

Comment 9

[moo_the]

Would appreciate it very much if we receive some help in solving this problem

Comment 10

[Johnny Stenback (:jst)]

Attachment: Add NPPVformValue to NPAPI.

This fixes this bug by introducing a new NPPVformValue into the NPPVariable
enum that's now used to request the form value from a plugin if its part of a
form during form submission.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 176736 [details] [diff] [review]
Add NPPVformValue to NPAPI.

>Index: modules/plugin/base/public/npapi.h
>+  /* Get the plugin value (as UTF-8 string data) for form submission
>+   * if the plugin is part of a form. Use NPN_MemAlloc() to allocate
>+   * memory for the string data.
>+  */

>Index: modules/plugin/base/src/ns4xPluginInstance.cpp

>+ns4xPluginInstance::GetFormValue(nsAString& aValue)

>+    nsMemory::Free(value);

Are we guaranteed that NPN_MemAlloc() uses nsMemory::Alloc?  If so, worth
commenting clearly here.  If no, please use the right allocator?

>Index: content/html/content/src/nsHTMLObjectElement.cpp

> nsHTMLObjectElement::SubmitNamesValues(nsIFormSubmission* aFormSubmission,

>+  nsCOMPtr<nsIObjectFrame> objFrame(do_QueryInterface(frame));

This should warn in debug builds.  See
http://lxr.mozilla.org/seamonkey/source/layout/generic/nsObjectFrame.cpp#449
Frames are not refcounted; don't use nsCOMPtr on them.	Just do:

nsIObjectFrame* obj = nsnull;
CallQueryInterface(frame, &obj);

r=bzbarsky with those nits fixed.

Comment 12

[Johnny Stenback (:jst)]

(In reply to comment #11)
> >+ns4xPluginInstance::GetFormValue(nsAString& aValue)
> 
> >+    nsMemory::Free(value);
> 
> Are we guaranteed that NPN_MemAlloc() uses nsMemory::Alloc?  If so, worth
> commenting clearly here.  If no, please use the right allocator?

Yeah, NPN_MemAlloc() is implemented here:

http://lxr.mozilla.org/mozilla/source/modules/plugin/base/src/ns4xPlugin.cpp#2048

And this is the public NPAPI header, internal allocator comments IMO don't
belong here.

> Frames are not refcounted; don't use nsCOMPtr on them.	Just do:
> 
> nsIObjectFrame* obj = nsnull;
> CallQueryInterface(frame, &obj);

Fixed (with a an explicit null frame check before calling CallQueryInterface()). 

Comment 13

[Boris Zbarsky [:bzbarsky]]

> And this is the public NPAPI header

ns4xPluginInstance is a public NPAPI header?  I was saying it's worth commenting
where you do the Free(), with pointers to the right code...

Comment 14

[Brendan Eich [:brendan]]

Comment on attachment 176736 [details] [diff] [review]
Add NPPVformValue to NPAPI.

sr=me with the changes bz wanted -- I think it's worth matching allocator and
free functions where possible (I don't always do this in JS with its
error-throwing layer on malloc/free, but arguably that's different from having
two wrapper pairs on malloc free, and mixing, as this patch seems to do;
anyway, I've regretted my ways based on JS embedder feedback).

/be

Comment 15

[Johnny Stenback (:jst)]

(In reply to comment #13)
> > And this is the public NPAPI header
> 
> ns4xPluginInstance is a public NPAPI header?  I was saying it's worth commenting
> where you do the Free(), with pointers to the right code...

Sorry, didn't read your comment right there. Comment added.

Comment 16

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 176736 [details] [diff] [review]
Add NPPVformValue to NPAPI.

modules/plugin/base/public/npapi.h
   /* 12 and over are available on Mozilla builds starting with 0.9.9 */

clearly not all of the values above 12 are available on 0.9.9 :) should there
be a comment above NPPVformValue that it's available starting 1.8?

Comment 17

[Johnny Stenback (:jst)]

Fix checked in.

Comment 18

[Johnny Stenback (:jst)]

(In reply to comment #16)
> (From update of attachment 176736 [details] [diff] [review] [edit])
> modules/plugin/base/public/npapi.h
>    /* 12 and over are available on Mozilla builds starting with 0.9.9 */
> 
> clearly not all of the values above 12 are available on 0.9.9 :) should there
> be a comment above NPPVformValue that it's available starting 1.8?
> 

Fixed that too, thanks.

Comment 19

[Vlad Alexander]

Broken in Minefield:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a4pre) Gecko/20100403 Minefield/3.7a4pre

XStandard plug-in for testing on Windows:
http://misc.xstandard.com/mozilla/NPXStandard.dll

XStandard plug-in for testing on OS X:
http://misc.xstandard.com/mozilla/XStandard.plugin.zip

See test page here:
http://misc.xstandard.com/mozilla/javascriptfree.asp