Closed
Bug 167601
Opened 22 years ago
Closed 22 years ago
[object] Support <param name="PLUGINURL" ...>
Categories
(Core Graveyard :: Plug-ins, defect, P3)
Core Graveyard
Plug-ins
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.2beta
People
(Reporter: rubydoo123, Assigned: peterl-bugs)
Details
(Whiteboard: [PL2:NA])
Attachments
(1 file)
1.91 KB,
patch
|
peterlubczynski-bugs
:
review+
jst
:
superreview+
|
Details | Diff | Splinter Review |
Submitting bug to track the coding to support pluginspage in param element. The param element coding: <param name="pluginspage" value="path to xpi file"> The default plug-in functionality should be the same as with the embed element and the codebase attribute hack. This is to provide a mechanism to phase out the codebade attribute hack.
Reporter | ||
Updated•22 years ago
|
Priority: -- → P3
Whiteboard: [PL2:NA]
Target Milestone: --- → mozilla1.2beta
Reporter | ||
Comment 1•22 years ago
|
||
Arun corrected my mistake in requesting pluginspage instead of pluginsurl. So, the request should be to use pluginsurl. I have updated the Summary to reflect that change. Arun also pointed me to an historical reference of the use: http://developer.netscape.com/docs/manuals/htmlguid/tags14.htm#1684921 Thanks Arun!
Summary: Support <param name="pluginspage" ...> → Support <param name="pluginsurl" ...>
Comment 2•22 years ago
|
||
This patch will look for PLUGINURL (singular) in the PARAM tags of OBJECT tags instead of CODEBASE. The default plugins are already setup to look for this.
Comment 3•22 years ago
|
||
According to the spec here: http://developer.netscape.com/docs/manuals/htmlguid/tags14.htm#1684921 The name value should be singluar ___PLUGINURL__ ---- Anthony, can I get a review?
Comment 5•22 years ago
|
||
Should both PLUGINSPAGE and PLUGINURL be supported, as the reference from Arun about Netscape 4.x documents? That would provide the advantage of allowing an unambiguous method of specifying whether the URI points to an XPI package or a human-readable download instruction page. PLUGINURL could also be used by other browsers that don't support any automatic download/installation, and by Mozilla for those cases when the XPI installation fails (say, because the XPI doesn't contain a plugin compatible with the user's platform). (From http://developer.netscape.com/docs/manuals/htmlguid/tags14.htm#1684921 ) ---- PLUGINSPAGE="instrURL" specifies the URL that contains the instructions for installing the plug-in if it is not already installed. PLUGINURL="pluginURL" is the URL of a Java Archive (JAR) file, which is a compressed collection of files that can be signed. ----
Reporter | ||
Comment 6•22 years ago
|
||
Peter S: see bug 169743 (just opened for pluginspage support
Comment 7•22 years ago
|
||
Comment on attachment 99228 [details] [diff] [review] patch v.1 sr=jst
Attachment #99228 -
Flags: superreview+
Comment 8•22 years ago
|
||
Comment on attachment 99228 [details] [diff] [review] patch v.1 (from comments)
Attachment #99228 -
Flags: review+
Comment 9•22 years ago
|
||
The relevant comment in the patch still refers to pluginspage: + // if we didn't find a PluginsPage param on the object tag, + // there's nothing more to do here + if(nsPluginTagType_Object == tagType && !bHasPluginURL) return rv; That should probably be changed to PluginURL to avoid confusing things...
Comment 10•22 years ago
|
||
comment fixed and patch checked into the trunk, marking FIXED
Comment hidden (Intermittent Failures Robot) |
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•