Bug 68002 - Some interface attributes do not appear on the prototype as required by WebIDL
Summary: Some interface attributes do not appear on the prototype as required by WebIDL
Status: RESOLVED DUPLICATE of bug 49739
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore JavaScript (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL: http://dev.w3.org/2006/webapi/WebIDL/...
: 70929 (view as bug list)
Depends on:
Blocks: 67335
  Show dependency treegraph
Reported: 2011-09-13 07:03 PDT by Joel Martin
Modified: 2011-12-29 06:44 PST (History)
6 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Joel Martin 2011-09-13 07:03:13 PDT
I was attempting to object detect support for binary type support in the WebSocket object and discovered that the binaryType attribute is not visible in the prototype (https://bugs.webkit.org/show_bug.cgi?id=67335#add_comment). For WebSocket object detection this is a blocking issue because instantiating the object triggers a network connection (even if you immediately call close() and null the websocket object in the same execution context).

However, it seems like a more general issue of efficiency (object detection without needing instantiantion) and also of compliance with the WebIDL definition of attributes: http://dev.w3.org/2006/webapi/WebIDL/#es-attributes:

"For each attribute defined on the interface, there must exist a corresponding property. If the attribute was declared with the [Unforgeable] extended attribute, then the property exists on every object that implements the interface. Otherwise, it exists on the interface’s interface prototype object."

I'm not sure how widely this problem exists Chrome, but at least for WebSocket attributes, firefox and opera are correct and have the attributes names visible on the prototype.
Comment 1 Simon Pieters (:zcorpan) 2011-09-15 07:54:34 PDT
I don't have "canconfirm" permission but I can nonetheless confirm that WebKit violates the spec here.
Comment 2 Yuta Kitamura 2011-09-15 20:09:37 PDT
For example, what should happen if you call "WebSocket.prototype.readyState" without creating a WebSocket instance?

Firefox Aurora raises a cryptic exception, which actually made me get surprised.

> MozWebSocket.prototype.readyState
[Exception... "Illegal operation on WrappedNative prototype object"  nsresult: "0x8057000c (NS_ERROR_XPC_BAD_OP_ON_WN_PROTO)"  location: "JS frame :: Web Console :: <TOP_LEVEL> :: line 1"  data: no]

Does this match what the spec expects?
Comment 3 Yuta Kitamura 2011-09-15 20:14:56 PDT
Pasting Sam's comment at https://bugs.webkit.org/show_bug.cgi?id=67335#c10 for the record

> For the record, it is currently our intention to eventually put attributes on the prototype, we just need to figure out a way to do it with regressing performance (which is a bit difficult).  In the mean time, one can always construct a dummy object and test for the attributes presence to do feature detection.
Comment 4 Alexey Proskuryakov 2011-10-26 12:10:43 PDT
*** Bug 70929 has been marked as a duplicate of this bug. ***
Comment 5 Alexey Proskuryakov 2011-10-26 12:11:17 PDT
Is this the same as bug 49739?
Comment 6 Kentaro Hara 2011-12-29 06:44:59 PST

*** This bug has been marked as a duplicate of bug 49739 ***