169743 - [object] Support <param name="PLUGINSPAGE" ...>

Status: RESOLVED WONTFIX

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

Description

[rubydoo123]

Offshoot from bug 167601, we should also provide support via param element for
PLUGINSPAGE

Comment 1

[rubydoo123]

cc'ed folks and assigned to peterl

Comment 2

[rubydoo123]

based on a conversation with the team, the functionality that would be performed
using the pluginspage attribute is the same as used for pluginurl, the decision
was made to not invoke this attriubte.

Comment 3

[Peter K. Sheerin]

Based on this decision, you may want to determine what sort of evangelism you
should use on how the browser should fall back if an XPI package is specified as
the value for PLUGINURL if it doesn't contain a plugin compatible with the
platform being used, or fails for other reasons.

Should this be that the script inside the XPI should direct the user to a URL
that has an explanation about the failure, and perhaps a download that can be
installed manually?

Comment 4

[Peter Lubczynski]

What about slightly differenet funtionality for PLUGINSPAGE? We currently have
the problem that an extra browser window may open because we open the URL in a
window with a target of _blank. Perhaps PLUGINURL should open it in _current
while PLUGINSPAGE should open in _blank. Thoughts?

Comment 5

[Arun Ranganathan]

Peter,
Is this http://bugzilla.mozilla.org/show_bug.cgi?id=168490 about the different
window opening?  

Comment 6

[Peter Lubczynski]

Tad bit different than bug 168490 because in that bug we do not know if we are
getting an XPI or a HTML page when choosing the target window.

Comment 7

[Peter K. Sheerin]

Hmm. So you can't query the MIME type of the URL given first before deciding
what to do with it? If you can, that would be a way to make this work well while
just using PLUGINURL, otherwise you might reconsider putting PLUGINSPAGE back
in, since you could then know the mime type ahead of time.

I think Peter L.'s suggestion would take care of the problem with blank windows,
while offering several other benefits--if the XPI installation based on
PLUGINURL fails, then the browser could use PLUGINSPAGE to direct the user to an
instruction page that lists alternative installation methods and provides other
instructions on resolving installation problems.

I'm assuming this was the original reason both attributes were defined for NN 4.x?

To me, this seems like the logical solution, but since I'm not privy to the
discussion beppe mentioned, I'm not sure if there was a convincing argument that
this could be handled gracefully with just the PLUGINURL parameter.