Sometime since Mozilla 0.9 (build 2001050515) the Node.prototype object stopped being exposed. It is important that it be re-exposed since it disables my RangePatch.js script (http://www.pbwizard.com/Articles/Moz_Range_Object_Article.htm) that allows the Range object to be used all the way back to Netscape 6.0. I would like this to be repaired before the next milestone is released so that those who depend upon this (including some developers inside Netscape/AOL) can keep depending upon this. Jeff.

Changed Summary due to more info. I have found that more than one prototype object is not being exposed any more. The Range object's prototype is also not exposed any more (even after creating a range). I have confirmed that other constructors are now not available (HTMLElement, HTMLDivElement, Element, etc.) and I think this may be part of the reason why the prototype is not available any more. Some major change has been made and it has broken a very fundemental strenth of Mozilla (being able to add methods/properties to the core objects). I have also found that trying to define new properties to the prototype using __defineGetter__ and __defineSetter__ causes the browser to crash when you close it. Jeff.

Please don't set target milestones on bugs you don't own! This is a well known problem (XPCDOM regression, and we knew about this before checking landing the changes), this will be fixed, but not for mozilla0.9.1

Updating QA contact to Shivakiran Tummala.

*** Bug 86847 has been marked as a duplicate of this bug. ***

Hmm, this was marked as a crash bug, did this ever case a crash or was the keyword added by mistake?

*** Bug 83123 has been marked as a duplicate of this bug. ***

johnny, do you have a proposal patch for solving this issue yet? -thanks!

I have this working in my tree, but it'll take me some time (a few days) to clean the code up and get it tested.

*** Bug 80046 has been marked as a duplicate of this bug. ***

jst, can you post your patch in whatever state it's in so people can test and play?

nsBranch ok, this is necessary. Get this on the trunk ASAP to shake out possible regressions.

*** Bug 71639 has been marked as a duplicate of this bug. ***

BTW leaks seems to gone up after this landed to trunk (2392 B -> 824 KB).

The leaks that were introduced by this was due to some experimental code that I accidentally checked in when I landed this patch, I just fixed the problem and the leaks are down to ~2k again.

I think these changes are causing blocker bug #90472.

hmmm...sorry to butt in here...This seems pretty high risk to be taking today for the branch. PDT is really looking primarily at nice safe null ptr checks and the like =). What are the ramifications if we ship without this? Asking now 'cause they are gonna ask tomorrow.

I am not invoved in Netscape/Mozilla, but I am the origional reporter of this bug. If in any way possible that this bug can be fixed before the finalized NS6.1 is released it should be done. NS6.1 PR1 breaks a lot of code out there developed to: 1) Fix previous bugs in Netscape via script see: http://www.pbwizard.com/Moz%20Patches/index.htm 2) Emulation scripts that allow NS6+ to act more like IE for compatablility reasons. see: http://webfx.nu/dhtml/ieemu/ Both are important. VERY important. The first allows us to write script without a lot of browser dependant code checking for NS6.0, NS6.01 and NS6.1. The second is eaven more important if you are wanting NS to get a larger market share because it allows a lot of currently working scripts to work in NS and IE without a complete rewrite. Personally I would rather you NOT release 6.1 if this bug is not fixed in it. Jeff Yates http://www.pbwizard.com

I second mscott's concerns. Do we believe there's been enough testing to know that this didn't break anything else? My main concern is that it looks like there have been a few regressions already caused by this fix. How confident are you that those were the only ones?

This is important for Netscape 6.1 because it adds back support for extending and tweaking the way the DOM works, this is something that was possible in 6.0, and developers expect this to work. Not having this in 6.1 would leave the DOM severily krippled and not extendable at all, wich is extremely valuable to our evangelism effort. Web-developers have been asking for this since it was removed from the mozilla DOM (in the XPCDOM landing). While this patch might looks big and scary, the largets change in this patch is to move code from 100+ files (the code was not really removed, merely copied and the old code was made obsolete for removal later, on the trunk only) around our code base into the file nsDOMClassInfo.cpp, these changes are not done by hand, they're done using a script, so the human error factor should be out of the equation for those changes. The rest of the changes, while not trivial, are fairly straight forward, the code just sets up a prototype chain on the DOM objects, it doesn't mess with the object->prototype relationship so even if something goes wrong, the DOM object will continue to work as it's expected to, but reflection of properties on "inherited" prototypes might not work... Yes, the initial patch did cause one regression (two separate bugs on different days), but that was in code that's not really related to these changes. The regression was due to a brain-fart of mine that happened just before checking in and the changes I made just before checking in didn't get enough testing, the regressions were caused by my stupidness, not by real errors in this change. The last patch is from what we've seen so far regression free, but I'd rather wait n' see one more day until I land this on the branch. Ideally I'd land this on the branch on the weekend, or monday.

I believe the DOM prototype objects should be fixed. If this bug is fixed, once a method or property has been assigned to the prototype for an Object/Interface is will be automatically available to all other instances of that Object/Interface. This approach is very powerful and no other browser on the market provides such extensibility of it's underlying DOM. This feature, if properly marketed, will be seen by the web developer community as a major advantage of the Mozilla platform. While the 'average' web developer will probably not make direct use of this capability, advanced web developers can take advantage of the resulting extensibility of Mozilla's DOM to provide JavaScript based work arounds to bugs in Mozilla's current implementation as well as extensions which increase the compatibility of Mozilla in an increasingly proprietary Internet Explorer dominated web. These work arounds can be applied selectively to different Mozilla releases. This will promote the development of high level JavaScript libraries that will work unchanged in Mozilla 0.9.2 and subsequent releases even though the native implementation may be lacking initially. Advanced web developers will be the ones providing the script libraries that the 'average' web developer will be using. If we do not provide the advanced web developers with the tools with which to create reusable, maintainable script libraries then it will be all the more difficult to maintain their interest in developing for and supporting Mozilla based solutions. Without the script libraries that the advanced web developers provide, the 'average' web developer will ignore Mozilla. Finally, let me add this personal observation. Unless you have suffered the pain and frustrations for yourself you do not understand how difficult or painful it is to develop advanced DOM based Web Applications for Mozilla. Having an extensible DOM will lighten that suffering to some degree at least.

Plussed after discussion in the PDT today.

Does that mean that it made it into the finalized version of Netscape 6.1? Jeff.

The plus was provisional: we need to get this checked in for tomorrow's build, we need to get it a *bunch* of exposure, we need to get all the feedback good and bad. If we get the feedback and it's sufficiently good, then this will stay in. If we don't get the feedback or it's not good, then it'll be backed out. We're taking a bit of a risk on this one, we need to get some warm fuzzies!

Changes are checked in on the branch and trunk now, closing bug, lets re-open if there are issues with these changes.

A little keyword cleanup, added vbranch just to be sure.

verified ....

This bug most likely caused bug 92377.

Yes it did, "oh well" :-)

oh yeah it is ---there are some testcases to show it is exposed :)