DOM prototype objects not exposed in recent builds

VERIFIED FIXED in mozilla0.9.3



18 years ago
11 years ago


(Reporter: pbwiz, Assigned: jst)


({dom1, dom2, regression})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [PDT+], )


(4 attachments)



18 years ago
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 
( 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.


Comment 1

18 years ago
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.

Priority: -- → P1
Summary: Node.prototype not exposed in recent builds → DOM Core prototype objects not exposed in recent builds
Target Milestone: --- → mozilla0.9.1

Comment 2

18 years ago
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
Target Milestone: mozilla0.9.1 → ---

Comment 3

18 years ago
Updating QA contact to Shivakiran Tummala.
QA Contact: desale → stummala


18 years ago
Blocks: 73348


18 years ago
No longer blocks: 73348

Comment 4

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

Comment 5

18 years ago
Hmm, this was marked as a crash bug, did this ever case a crash or was the
keyword added by mistake?
Keywords: crashmozilla0.9.2
OS: Windows 2000 → All
Hardware: PC → All
Summary: DOM Core prototype objects not exposed in recent builds → DOM prototype objects not exposed in recent builds
Target Milestone: --- → mozilla0.9.2

Comment 6

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


18 years ago
Blocks: 70647

Comment 7

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

Comment 8

18 years ago
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.


18 years ago
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Comment 9

18 years ago
*** 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?


18 years ago

Comment 11

18 years ago
Posted patch WIP for fixSplinter Review
nsBranch ok, this is necessary. Get this on the trunk ASAP to shake out possible
Keywords: nsBranch

Comment 13

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

Comment 14

18 years ago
Posted patch FixSplinter Review

Comment 15

18 years ago
Posted patch FixSplinter Review

Comment 16

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

Comment 17

18 years ago
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.
Whiteboard: [FIXED ON TRUNK]
I think these changes are causing blocker bug #90472.

Comment 20

18 years ago
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

18 years ago
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

2) Emulation scripts that allow NS6+ to act more like IE for compatablility 

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

Comment 22

18 years ago
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

18 years ago
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

18 years ago
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

18 years ago
Plussed after discussion in the PDT today.

Comment 26

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


Comment 27

18 years ago
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

18 years ago
Changes are checked in on the branch and trunk now, closing bug, lets re-open if
there are issues with these changes.
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 29

18 years ago
A little keyword cleanup, added vbranch just to be sure.
Whiteboard: [FIXED ON TRUNK][PDT+] → [PDT+]

Comment 30

18 years ago
verified ....
This bug most likely caused bug 92377.

Comment 32

18 years ago
Yes it did, "oh well" :-)

Comment 33

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


11 years ago
Component: DOM: Core → DOM: Core & HTML
QA Contact: stummala → general
You need to log in before you can comment on or make changes to this bug.