Bug 8131 – Some properties and methods of window and document objects cannot be converted to a string

• Status: CLOSED
• Resolution: FIXED
• Component: DOM

[Gérard Talbot (no longer involved)]

Steps to reproduce:
1- Load provided URL
2- click the button to list the properties and methods of window | document | event object

Actual results in Safari 2.02 (416.13): nothing happens

Expected results: properties and methods should be listed.

Right now, Mozilla browsers, MSIE 6, Opera 7+ lists the properties and methods of these objects (albeit some browsers may have a few bugs too).

Fixing this bug would help DHTML and/or js+DOM scripters figuring out what they can use in a DHTML application and establish the level/degree of support/implementation of this or that property/method in Safari.

I searched for duplicate and couldn't find any.

[Alexey Proskuryakov]

Some of the properties here cannot be explicitly converted to a string:
alert(window['CSSRule']); // OK, [object CSSRuleConstructor]
alert(window['CSSRule']+""); // exception, "TypeError: No default value". OK in Firefox.

Interestingly, these problematic properties are just not listed in Firefox - not sure why.

Event object is dumped correctly in current WebKit builds, available at <http://nightly.webkit.org>. The troublesome property was event.view.

[Eric Seidel (no email)]

I feel like I fixed a very similar bug last fall which was caused by some of our java script binding objects not having proper prototypes (thus not having a toString() method).

[Gérard Talbot (no longer involved)]

> Some of the properties here cannot be explicitly converted to a string:
> alert(window['CSSRule']); // OK, [object CSSRuleConstructor]

I've never seen such "window['CSSRule']" code but I know one can access css rules in Firefox with

if(document.styleSheets && "cssRules" in document.styleSheets[0]) 
// DOM 2 CSS interface compliant
{
... code ...
};

http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/css.html#CSS-CSSStyleSheet-cssRules

At this precise url
<http://www.quirksmode.org/dom/w3c_css.html#access>
Peter-Paul Koch claims that Safari 1.3 supports cssRules[] collection. He gives a testpage:
<http://www.quirksmode.org/dom/tests/stylesheets.html>

> Event object is dumped correctly in current WebKit builds, available at
> <http://nightly.webkit.org>.

<...Argh...sigh> unfortunately, I can only test my website with a Mac in an Internet Cafe.

[Alexey Proskuryakov]

> I've never seen such "window['CSSRule']" code 

Oh, this is actually just a reduction of what fails in the test case:

TotalString += PropertyIterator + 1 + ". " + arrWindowProperties[PropertyIterator] + " = " + window[arrWindowProperties[PropertyIterator]] + "<br>";

arrWindowProperties[0] happens to be CSSRule in Safari. Several other window properties (e.g. window.XMLHttpRequest) have the same problem. To partially work around this WebKit bug, you can use a try/catch block:

try {
 TotalString += PropertyIterator + 1 + ". " + arrWindowProperties[PropertyIterator] + " = " + window[arrWindowProperties[PropertyIterator]] + "<br>";
} catch (ex) {
 TotalString += PropertyIterator + 1 + ". " + arrWindowProperties[PropertyIterator] + " - " + ex + "<br>";
}

> <...Argh...sigh> unfortunately, I can only test my website with a Mac in an
> Internet Cafe.

No problem, checking with nightly builds is not a requirement for filing WebKit bugs, it's just an extra favor :)

[Alexey Proskuryakov]

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

[Alexey Proskuryakov]

Most of the missing prototypes have been added in bug 9310. There is a strange problem with window.debug - it is only present when the document is loaded for the first time (not after a reload), and it still causes a "No default value" exception.

[Alexey Proskuryakov]

Created attachment 8884 [details]
fix window.debug and test all properties

I have added a prototype to window.debug, now all the properties of window and document objects can be converted to string.

The strange behavior of window.debug is caused by it being added in KJSProxy::initScriptIfNeeded(), which isn't called when reloading. I am not sure where it should be (Interpreter::initGlobalObject? kjs_window.cpp? removed completely?)

[Geoffrey Garen]

Comment on attachment 8884 [details]
fix window.debug and test all properties

Good fix.

Given the goofiness of this property, and the existence of alternatives like window.console.log, I think we should probably remove it entirely.

If KDE folks are listening, do you get any mileage out of window.debug?

[Alexey Proskuryakov]

Landed r14903. Opened bug 9492 for window.debug.

[Gérard Talbot (no longer involved)]

Marking as VERIFIED