83433 - DOM prototype objects not exposed in recent builds

Status: VERIFIED FIXED

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

Description

[Jeff Yates]

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.

Comment 1

[Jeff Yates]

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.

Comment 2

[Johnny Stenback (:jst)]

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

Comment 3

[Prashant Desale]

Updating QA contact to Shivakiran Tummala.

Comment 4

[Matthew Wilson]

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

Comment 5

[Johnny Stenback (:jst)]

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

Comment 6

[Johnny Stenback (:jst)]

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

Comment 7

[Cathleen]

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

Comment 8

[Johnny Stenback (:jst)]

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.

Comment 9

[Nisheeth Ranjan]

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

Comment 10

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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

Comment 11

[Johnny Stenback (:jst)]

Attachment: WIP for fix

Comment 12

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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

Comment 13

[Johnny Stenback (:jst)]

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

Comment 14

[Johnny Stenback (:jst)]

Attachment: Fix

Comment 15

[Johnny Stenback (:jst)]

Attachment: Fix

Comment 16

[Asko Tontti]

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

Comment 17

[Johnny Stenback (:jst)]

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.

Comment 18

[(not reading, please use [e-mail] instead)]

I think these changes are causing blocker bug #90472.

Comment 19

[Johnny Stenback (:jst)]

Attachment: Fix for the branch, includes fixes for the regression caused by the above patch

Comment 20

[Scott MacGregor]

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.

Comment 21

[Jeff Yates]

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

Comment 22

[scottputterman]

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?

Comment 23

[Johnny Stenback (:jst)]

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.

Comment 24

[Bob Clary [:bc] (inactive)]

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.

Comment 25

[Nisheeth Ranjan]

Plussed after discussion in the PDT today.

Comment 26

[Jeff Yates]

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

Jeff.

Comment 27

[selmer (gone)]

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!

Comment 28

[Johnny Stenback (:jst)]

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

Comment 29

[selmer (gone)]

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

Comment 30

[Sivakiran Tummala]

verified ....

Comment 31

[Ben Bucksch (:BenB)]

This bug most likely caused bug 92377.

Comment 32

[Johnny Stenback (:jst)]

Yes it did, "oh well" :-)

Comment 33

[Sivakiran Tummala]

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