858344 - NamedNodeMap constructor no longer exposed to web content

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, defect, P5)

Description

[William J. Edney]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20130404 Firefox/23.0
Build ID: 20130404030859

Steps to reproduce:

alert(window.NamedNodeMap)


Actual results:

I got the following output:

undefined


Expected results:

I would've expected the following output:

function NamedNodeMap() { [native code] }

Comment 1

[William J. Edney]

NB: This works up to the current release channel, Firefox 20.

Comment 2

[(mostly gone) XtC4UaLL [:xtc4uall]]

and Beta, but not Aurora and newer.

Bug 847195?

Comment 3

[Boris Zbarsky [:bzbarsky]]

Yep.  NamedNodeMap got removed from the spec, so we apparently renamed it to MozNamedAttrMap.

William, is this causing a problem on actual web sites?

Comment 4

[William J. Edney]

Boris -

Well, our system has a small 'protocol' of methods (less than 5) that we 'monkey patch' onto a host of the built-in objects (well, their constructor's prototype) for polymorphism purposes. I was surprised that NamedNodeMap was missing.

I would assume that by 'the spec', you're referencing DOM Level 4. If so, is there an implementation roadmap for implementation of L4 into Gecko? I'm a bit surprised that these changes are being made now, given that DOM Level 4 is merely a working draft at this point, but this is not a huge deal for us - I can test for it.

So this bug can be closed.

Thanks!

Cheers,

- Bill

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

FYI, the DOM spec we (and most other browser vendors) are progressively implementing is http://dom.spec.whatwg.org/

Comment 6

[Boris Zbarsky [:bzbarsky]]

> I would assume that by 'the spec', you're referencing DOM Level 4.

Kinda; it's not quite called that.

I think it's being implemented piecemeal; some parts of it are more stable than others.  In some parts it's way better than the L3 spec ever was, while others are more in flux.

Comment 7

[William J. Edney]

Hmmm... ok.

I have to admit, this is pretty scary. While I understand the need to evolve the codebase as the standards change, it's unclear to me how to move forward with a stable platform that apps can be developed to when features are removed. And by apps I mean long-lived, enterprise, change-the-browser-maybe-once-a-year-if-you're-lucky apps.

In any case, this is not the forum to debate this - the 'speed over stability' horse was beaten to death long ago. I have to say that I'd really like to see a 'Gecko changes' roadmap, if one exists, or some kind of worklist or something so that those of us here in the wild can sort of chart a course through the minefield (i.e. "Ok, I see here that feature X is scheduled to go away in Firefox 25..."). Any pointers to a document such as that would be most welcome.

Feel free to close this. NamedNodeMap isn't important but I'm left wondering whether it's the canary in a coalmine...

Cheers,

- Bill

Comment 8

[Kohei Yoshino [:kohei]]

Added a note to the site compatibility document.
https://developer.mozilla.org/en-US/docs/Site_Compatibility_for_Firefox_22

Comment 9

[Anne (:annevk)]

I filed bug 1055467 on restoring this API partially (still only deals with attributes).

Comment 10

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven't been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.