Closed Bug 9392 Opened 25 years ago Closed 21 years ago

"document.plugins" returns null instead of returning Object Embed array.

Categories

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

x86
Windows 95
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: desale, Assigned: vidur)

References

Details

(Keywords: testcase, Whiteboard: [nsbeta2+] document.plugins does not return [Object EmbedArray])

Attachments

(3 files)

Javascript command "document.plugins" returns null instead of returning Object
Embed array.

Product: Seamonkey.[apprunner/Viewer]
Build: 1999-07-07-08
Platform: PC [Windows-95]

Steps to Reproduce:
1] Please copy the code I'm providing. Save as HTML file.
2] Open this HTML file in apprunner as well as viewer.
3] You'll see the value of document.plugins gets printed.

Expected Results:
document.plugins: [object EmbedArray]

Actual Results:
document.plugins: null

CODE:

<html>
<head>
<title>
</title>
</head>
<body>
<form name="propForm">
<script>
<!--
document.write("document.plugins: ");
document.write(document.plugins);
//-->
</script>
</form>
</body>
</html>

END OF CODE:
QA Contact: beppe → desale
Changing QA contact to myself.
Status: NEW → ASSIGNED
Target Milestone: M10
Whiteboard: [TESTCASE] document.plugins does not return [Object EmbedArray]
set status to "[TESTCASE] bla" standard.
Target Milestone: M10 → M11
any status update on this? -> m11
Assignee: av → mccabe
Status: ASSIGNED → NEW
Component: Plug-ins → Javascript Engine
Assignee: mccabe → av
Component: Javascript Engine → Plug-ins
Andrew:

This is not a JavaScript engine bug.  It looks like plugins aren't being exposed
properly to scripts running within the browser.  Getting this right is part of
the plugins implementation, isn't it?  I willing to help you investigate the
problem, but it's not a problem with the JavaScript language itself.

I'm reassigning this bug to plugins, and adding myself to the CC list.  Please
send me mail if you'd like to talk about how to solve it.

I notice that testing 'document.plugins == null' returns true in my 4.x browser
as well - desale: do I need to have plugins installed before document.plugins
appears?  Plugins and their manifestation to DOM javascript is not my area...
I don't think its neccesary to have plugins installed before document.plugins
appear.
I just stumbled across this comment on a 'DOM browser' webpage
(http://www.gemal.dk/browserspy/showprop.html) -

Current known bugs: To see the Plugins object you have to go to the Mimetypes
object first! Anybody got a clue why?

Seems like it could be relevant.
Target Milestone: M11 → M13
m13
Status: NEW → ASSIGNED
Target Milestone: M13 → M14
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
Target Milestone: M14 → M15
Target Milestone: M15 → M16
Target Milestone: M16 → M18
Isn't this really a DOM0 bug? Leaving on Plugins component for now. Adding jst & 
stever to cc:. Marking 4xp. 

See related bug 25359, "navigator.plugins and/or navigator.mimeTypes not 
working."

Is there any way we could get this fixed for beta2? It's probably less important 
than 25359 from the standpoint of content developers if push comes to shove.
Keywords: 4xp
Nominating nsbeta2. We really need to get JavaScript detection of plug-ins via 
the DOM enabled so that the content gets turned on. Many sites like ZDNet 
automatically fall back to GIFs if the plug-in isn't detected. So until this bug 
is fixed, we're not getting good testing coverage of the plug-in content out 
there and are at risk to leave content compatibility bugs undiscovered.
Keywords: nsbeta2
Whiteboard: [TESTCASE] document.plugins does not return [Object EmbedArray] → document.plugins does not return [Object EmbedArray]
Adding another testcase that shows that you can get the correct behavior if you 
use with (document) and with (navigator) js blocks in the html.
per jst in http://bugzilla.mozilla.org/show_bug.cgi?id=25359 the problem is 
nsHTMLDocument::GetPlugins() -
http://lxr.mozilla.org/seamonkey/source/layout/html/document/src/nsHTMLDocument.
cpp#2473

Note: The testcase I added has a note about the plugins.length value changing 
over time.  It's unrelated: 
http://bugzilla.mozilla.org/show_bug.cgi?id=39534
Could someone please give a clear description here about exactly what the
following properties should return?

navigator.plugins
navigator.plugins[n]
document.plugins
document.plugins[n]
document.embeds
document.embeds[n]

I'll start by explaining the parts I tink I know, please correct me if I'm
wrong...

navigator.plugins     is an array of currently installed plugins on the client
                      computer (dom/public/idl/PluginArray.idl).

navigator.plugins[n]  is the n:th plugin of type "Plugin"
                      (dom/public/idl/base/Plugin.idl).

document.plugins      An array of ????

document.plugins[n]   The n:th ????

document.embeds       An array of embed tags in the document
                      (dom/public/idl/html/HTMLCollection.idl)

document.embeds[n]    The n:th embed element in the document
                      (dom/public/idl/html/HTMLEmbedElement.idl).

Someone please fill in the '????'s.
[nsbeta2+] 
Whiteboard: document.plugins does not return [Object EmbedArray] → [nsbeta2+] document.plugins does not return [Object EmbedArray]
Reassigning to Vidur, who's kindly agreed to take this on. Thanks Vidur!!!
Assignee: av → vidur
Status: ASSIGNED → NEW
document.plugins is now aliased to window.navigator.plugins. I didn't notice the 
first time around that this was part of 4.x. Fix checked in on 6/20/2000. Note 
that document.plugins does not work for XUL documents.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
navigator.plugins is working fine now. 
Status: RESOLVED → VERIFIED
Test case for document.plugins
  http://mozilla.org/quality/ngdriver/suites/javascript/doc011.html
is failng (Actual Result null) in M18 build 2000080120 on MacOS 8.6.
However, navigator.plugins test
  http://mozilla.org/quality/ngdriver/suites/javascript/nav007.html
does pass.
reopening per failed testcase report
adding nsbeta3 keyword
Status: VERIFIED → REOPENED
Keywords: nsbeta3
Resolution: FIXED → ---
Per PR2 triage, no time/rick left for PR2 bits.  Putting on nsbeta2- radar.
Whiteboard: [nsbeta2+] document.plugins does not return [Object EmbedArray] → [nsbeta2-] document.plugins does not return [Object EmbedArray]
Putting on nsbeta2+ temporarily to see if can take for PR2.
Whiteboard: [nsbeta2-] document.plugins does not return [Object EmbedArray] → [nsbeta2+] document.plugins does not return [Object EmbedArray]
Vidur....this should have been checked in per selmers voicemail...did ya get it 
in the branch?
I landed Vidurs changes last night, marking FIXED.
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
Works on Build ID: 2000080404. Marking verified.
Status: RESOLVED → VERIFIED
I met this problem again on Mozilla 1.0 RC 3
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523

Same happens to Netscape 7.0 PR1 on Solaris
Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020719 Netscape/7.0
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Add "browser-china-bughunter@sun.com" in "CC" list;
*** Bug 193552 has been marked as a duplicate of this bug. ***
The testcase at
http://mozilla.org/quality/ngdriver/suites/javascript/doc011.html shows that
document.plugins returns [object HTMLCollection]. From bug 142774 I realize that
the testcase is incorrect (is expecting [object PluginArray]).

I'm just wondering (since it was 3 years since the summary was changed): Should
document.plugins really return [object EmbedArray]? Can someone clarify, please?
Sorry about the spam, but according to
http://devedge.netscape.com/library/xref/2002/client-data/property-data-document.html

"document.plugins" seem to return [object HTMLCollection]...
This bug is really fixed, it was fixed a long time ago. The testcases on
mozilla.org refered to in this bug have been fixed as well.
To summarize, document.plugins returns document.embeds (4xp).
Marking FIXED.
Status: REOPENED → RESOLVED
Closed: 24 years ago21 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: