184691 - Bogus "PARAM" added to plugin's parameter list

Status: RESOLVED INVALID

(Core Graveyard :: Plug-ins, defect)

Description

[Jason Summers]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3a) Gecko/20021210
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3a) Gecko/20021210

When invoking a plug-in with an <object> tag, a bogus extra parameter named
"PARAM" is sent to the plug-in (via NPP_New()) if any <param> tags are present.
The value supplied for PARAM is a NULL pointer.

Reproducible: Always

Steps to Reproduce:
For example, if a plugin handles type "application/x-example", try the following
HTML:

 <object type="application/x-example" width=100 height=100>
  <param name=x value=y>
 </object>
Actual Results:  
The following parameters will be sent to the plug-in:

  "type"   = "application/x-example"
  "width"  = "100"
  "height" = "100"
  "PARAM"  = (null)
  "x"      = "y"

Expected Results:  
The parameter named "PARAM" should not be there.

Comment 1

[rubydoo123]

The null param is basically a separator between values passed via the object and
values being passed via param elements.

Comment 2

[Jason Summers]

Okay, so I searched around and found all of five words ("separated by a PARAM
entry") that maybe are supposed to suffice as the documentation for this.

I would have hoped that such a feature would have used a name that's a little
less generic than "PARAM", to avoid name collisions with existing plugins, but I
suppose it's too late for that now.

Anyway, won't the NULL pointer cause some existing plugins to crash when they
try to read the value? Even in the *current* API documentation, I don't see
anything about the need to test for NULL pointers.
http://devedge.netscape.com/library/manuals/2002/plugin/1.0/npp_api7.html

Comment 3

[Peter Lubczynski]

-->INVALID

This is by design for 4.x compatibility. Null 'values' are valid, for example,
the MAYSCRIPT attribute.