Closed Bug 9378 Opened 26 years ago Closed 25 years ago

document.layers returns null.

Categories

(Core :: DOM: Core & HTML, enhancement, P2)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Windows 95
Type:
enhancement

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: desale, Assigned: vidur)

References

Details

Javascript command "document.layers" returns null instead of returning the layers array. Product: Seamonkey.[apprunner/Viewer] Build: 1999-07-07-08 Platform: PC [Windows-95] Steps to Reproduce: 1] Please copy the code I'm providing. Save as HTML file. 2] Open this HTML file in apprunner as well as viewer. 3] You'll see the value of document.layers gets printed. Expected Results: document.layers: [object LayerArray] Actual Results: document.layers: null CODE: <html> <head> <title> </title> </head> <body> <form name="propForm"> <script> <!-- document.write("document.layers: "); document.write(document.layers); //--> </script> </form> </body> </html> END OF CODE: Right now I'm thinking it should go to vidur. It might go to ekrock, since its a layer bug. Vidur, please assign it to ekrock if I'm wrong.
Blocks: 9192
No longer blocks: 9192
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → INVALID
I rescently entered this bug. After talking to vidur, came to know that we are not going to support "document.layers" in 5.0, so that makes this bug invalid. So I'm going ahead and marking it invalid.
Status: RESOLVED → VERIFIED
Invalid. Verified.
Status: VERIFIED → REOPENED
If you are not going to support document.layers it should be undefined instead of null
Severity: normal → enhancement
Status: REOPENED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: INVALID → LATER
this will not be addressed for Comm 5.0 commericial product. How about we mark Verified/Later so it gets addressed for 5.1? this is the best way to not lose this enhancement for later.
Status: RESOLVED → VERIFIED
Status: VERIFIED → REOPENED
Resolution: LATER → ---
I'm still interested in understanding why it has to be undefined and not null. Shouldn't the if (document.layers) checks that are out there still fail for a null value? Having said that, I agree that it probably makes sense to do what a non-layers browser would do i.e. return undefined.
*** Bug 11853 has been marked as a duplicate of this bug. ***
Moving all non-DOM[012], non-crash bugs to M15.
HTML DOM bugs are M11/P2 for Vidur.
Target Milestone: M11 → M13
Any theoretical considerations aside, we want code of this form: if (document.layers) { /* Nav4 code */ } else if (document.all) { /* IE4+ code */ } else if {document.getElementsById) { /* Nav5 W3C DOM code */ } ... to work smoothly on Nav5 as there's a *lot* of it out there already, and we want to make it as easy as possible for developers who already support Nav4/IE4 to upgrade and support Nav5, maintaining backward compatibility if possible. See http://developer.netscape.com/docs/examples/javascript/browser_type.html for more detail about this. It seems that code of that form will work correctly regardless of whether we return undefined or null. If I'm correct about that, then I'm fine with having it return undefined (which does seem logical) rather than null. If there is *ANY* way in which having document.layers return undefined rather than null will make content/JS developers' lives harder, we should do whatever will make their lives easier. Vidur, please use me if you need chatting/research. Either way, fixing this is a low priority. Moving to M13.
In an attempt to get my bug list in order again, marking all the bugs I have currently as ASSIGNED.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 25 years ago
Resolution: --- → FIXED
Rather than debate this more, I checked in a change to revert to Nav 4.x behavior - we now return undefined.
Verified with 2000-01-20-09.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.