Object should submit (name attribute on <object>)

RESOLVED FIXED in mozilla1.8beta2

Status

()

Core
Plug-ins
P3
enhancement
RESOLVED FIXED
15 years ago
8 years ago

People

(Reporter: John Keiser (jkeiser), Assigned: jst)

Tracking

Trunk
mozilla1.8beta2
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
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).
(Reporter)

Comment 1

15 years ago
*** Bug 178341 has been marked as a duplicate of this bug. ***
Note that an <object> _does_ have a well-defined name attribute and .name property.

Comment 3

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

Comment 4

15 years ago
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

15 years ago
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

15 years ago
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.

Updated

15 years ago
Priority: -- → P3
Hardware: PC → All
Target Milestone: --- → Future
*** Bug 257543 has been marked as a duplicate of this bug. ***
Summary: Object should submit → Object should submit (name attribute on <object>)

Comment 8

13 years ago
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

13 years ago
Would appreciate it very much if we receive some help in solving this problem
(Assignee)

Updated

13 years ago
Assignee: peterlubczynski-bugs → jst
(Assignee)

Comment 10

13 years ago
Created attachment 176736 [details] [diff] [review]
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.
Attachment #176736 - Flags: superreview?(brendan)
Attachment #176736 - Flags: review?(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.
Attachment #176736 - Flags: review?(bzbarsky) → review+
(Assignee)

Updated

13 years ago
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla1.8beta2
(Assignee)

Comment 12

13 years ago
(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()). 
> 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 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
Attachment #176736 - Flags: superreview?(brendan) → superreview+
(Assignee)

Comment 15

13 years ago
(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 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?
(Assignee)

Comment 17

13 years ago
Fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
(Assignee)

Comment 18

13 years ago
(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.

Updated

12 years ago
Blocks: 163993

Updated

12 years ago
No longer blocks: 163993

Comment 19

8 years ago
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
You need to log in before you can comment on or make changes to this bug.