This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 22600 - Need a way to make navigator.plugins supported named properties not enumerable
Summary: Need a way to make navigator.plugins supported named properties not enumerable
Status: RESOLVED FIXED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 22320
  Show dependency treegraph
 
Reported: 2013-07-08 22:16 UTC by Ian 'Hixie' Hickson
Modified: 2014-04-11 19:04 UTC (History)
4 users (show)

See Also:


Attachments

Description Ian 'Hixie' Hickson 2013-07-08 22:16:43 UTC
If I do this I get "true", "true":

   alert(0 in navigator.plugins);
   alert('Google Talk Plugin' in navigator.plugins);
   

If I do this I get "true", "false":

   var names = {};
   for (i in navigator.plugins)
     names[i] = true;
   alert(0 in names);
   alert('Google Talk Plugin' in names);


With this I get "true", "false" ("true", "true" in Gecko, but that seems bogus given the other results):

   alert(navigator.plugins.propertyIsEnumerable(0))
   alert(navigator.plugins.propertyIsEnumerable('Google Talk Plugin'))


I don't see a way to do this in WebIDL. For now I've just said "The properties exposed in this way must not be enumerable".

TESTCASE: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2397

(Note that Firefox doesn't act consistently here. It seems like it makes properties enumerable once you've tried to see if they're there? But try running the examples above in isolation and you'll see the difference. Or run the middle part of the test before the other two parts.) (I couldn't test IE.)
Comment 1 Boris Zbarsky 2013-07-09 03:31:54 UTC
> It seems like it makes properties enumerable once you've tried to see if
> they're there?

It creates the properties when you try to see if they're there, and creates them as enumerable.  Just trying to enumerate does _not_ create the properties.  That's a bug.

That bug is being fixed in https://bugzilla.mozilla.org/show_bug.cgi?id=855611 which will in fact make both the name and the index enumerable, per current WebIDL spec.

> For now I've just said "The properties exposed in this way must not be
> enumerable".

Unfortunately, that directly contradicts normative requirements WebIDL has here; we will be tracking WebIDL unless and until it gets changed (simply because all the code in question is autogenerated in our WebIDL bindings, so has no choice but to track WebIDL).
Comment 2 Boris Zbarsky 2013-07-09 03:34:37 UTC
But note that we want a feature like this for <form> anyway, for bug 22320.
Comment 3 Ian 'Hixie' Hickson 2013-07-09 20:27:38 UTC
Other browsers don't enumerate the names them either. Given that this API only exists for back-compat, being different just because WebIDL doesn't have a way to do this doesn't seem like a good idea.
Comment 4 Cameron McCormack 2014-01-26 17:17:14 UTC
You can link to the term #dfn-unenumerable now:

https://github.com/heycam/webidl/commit/de52ca39d9513511c5eca7c030ec040035ad3f86
Comment 5 Boris Zbarsky 2014-01-27 01:32:57 UTC
I wonder whether we should use this for htmlcollection too... people seem to get confused by the current enumeration behavior there.  :(
Comment 6 Ian 'Hixie' Hickson 2014-03-11 17:02:37 UTC
Taking this to deal with the implications on my side.
Comment 7 contributor 2014-04-11 19:04:34 UTC
Checked in as WHATWG revision r8571.
Check-in comment: Sync with WebIDL over 'unenumerable'.
http://html5.org/tools/web-apps-tracker?from=8570&to=8571