[Webkit-unassigned] [Bug 18056] Cannot convert DOM exception prototype object to a string

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=18056





--- Comment #11 from Cameron McCormack <cam at mcc.id.au>  2009-09-04 21:03:55 PDT ---
(In reply to comment #10)
> > +                if ($function->signature->name eq "toString") {
> > +                  $implIncludes{"PlatformString.h"} = 1;
> > +                  push(@implContent, "    if (thisValue.inherits(&${className}Prototype::s_info))\n");
> > +                  push(@implContent, "        return jsNontrivialString(exec, \"[object \" + String(thisValue.toThisObject(exec)->className()) + \"]\");\n");
> > +                }
> 
> Should be indented four spaces, not two.

OK.

> If you use String() here you'll get the inefficient WebCore::String, which
> reallocates on every append. Then convert into a UString since that's what the
> jsNontrivialString function takes.
> 
> You'll want to use UString() instead. It may need to be written as
> JSC::UString.

OK.  So I made it generate:

  return jsNontrivialString(exec,
      UString("[object ")
    + thisValue.toThisObject(exec)->className()
    + UString("]"));

since not explicitly calling UString on both char*s caused ambiguous
operator+() calls.  Would it it be better to avoid the second UString
conversion by doing something like:

  UString s("[object ");
  s.append(thisValue.toThisObject(exec)->className());
  s.append(']');

?

Anyway, if I do the first one above then I get linker errors:

/Developer/usr/bin/g++-4.0 -o
/Users/cam/svn/WebKit-2/WebKitBuild/Debug/WebCore.framework/Versions/A/WebCore
-L/Users/cam/svn/WebKit-2/WebKitBuild/Debug
-F/Users/cam/svn/WebKit-2/WebKitBuild/Debug
-F/System/Library/Frameworks/Carbon.framework/Frameworks
-F/System/Library/Frameworks/ApplicationServices.framework/Frameworks -filelist
/Users/cam/svn/WebKit-2/WebKitBuild/WebCore.build/Debug/WebCore.build/Objects-normal/i386/WebCore.LinkFileList
-framework ApplicationServices -framework Carbon -framework Cocoa -framework
JavaScriptCore -licucore -lobjc -lxml2 -framework QuartzCore -framework
SystemConfiguration -framework OpenGL -arch i386 -exported_symbols_list
/Users/cam/svn/WebKit-2/WebKitBuild/Debug/DerivedSources/WebCore/WebCore.exp
-Wl,-single_module -compatibility_version 1 -current_version 532.0
-install_name
/Users/cam/svn/WebKit-2/WebKitBuild/Debug/WebCore.framework/Versions/A/WebCore
-Wl,-Y,1455 -dynamiclib -mmacosx-version-min=10.4 -lWebCoreSQLite3 -lobjc
-sub_library libobjc -umbrella WebKit
ld: Undefined symbols:
__ZN3JSC11concatenateEPNS_7UString3RepES2_
__ZN3JSC7UString7nullRepEv

Any hints?

> > +PASS String(new WebKitCSSMatrix().__proto__) is "[object WebKitCSSMatrixPrototype]"
> > +PASS Object.prototype.toString.call(new WebKitCSSMatrix().__proto__) is "[object WebKitCSSMatrixPrototype]"
> 
> Doesn't WebKitCSSMatrix.prototype work? If not, is that a bug?

I got the impression that because WebKitCSSMatrix didn't have
[GeneratorConstructor] on it that window.WebKitCSSMatrix wouldn't exist, but
that doesn't seem to be true.  I'll just use WebKitCSSMatrix.prototype.

> In some cases, I think this is the only way our internal class names are
> exposed. I'm not sure that names such as DOMException, DOMWindow, DOMSelection
> are suitable to be seen by the web pages. Are those names the same as in other
> browsers? 

They can still be exposed if you do
Object.prototype.toString.call(DOMException.prototype), etc., for example. 
Similarly for the actual host object instances.  So I don't think we're
exposing anything new.

DOMException seems suitable as a name to expose, since it's the name of the
interface in the DOM Core spec, and other browsers use that name.  For the
window object, Gecko uses "Window" and "Selection" rather than "DOMWindow" and
"DOMSelection".  While it's probably good to have consistently exposed
[[Class]] names across browsers, that seems like a separate issue.  I don't
believe Selection is part of any spec at the moment.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.