New issue
Advanced search Search tips

Issue 687431 link

Starred by 1 user
Status: Duplicate
Merged: issue 643712
Owner:
yukishiino@chromium.org
Closed: Feb 2017
Cc:
lfg@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

Web IDL spec violation: Class name of prototypes should end with "Prototype"

Project Member Reported by mgiuca@chromium.org, Feb 1 2017 
Chrome Version: 58.0.2998.0
OS: Linux (all?)

What steps will reproduce the problem?
(1) Open console.
(2) TextDecoder.prototype.toString()

What is the expected result?
"[object TextDecoderPrototype]"

What happens instead?
"[object TextDecoder]"

This isn't a bug with TextDecoder; all interfaces behave the same way.

Rationale: idlharness.js (which, by the way, is being promoted for all new layout tests by a presubmit warning) requires this for all interfaces, and fails if the string doesn't match.

Here is an idlharness test for TextDecoder which currently fails in Chrome:
https://w3c-test.org/encoding/idlharness.html
"TextDecoder interface: existence and properties of interface prototype object"

It might be a problem with idlharness (I haven't checked against the spec) but it passes in Firefox 51.0.1.

+yukishiino who helped with my previous bindings generator / idlharness discrepancy ( Issue 627309 ).

Comment 1 by mgiuca@chromium.org, Feb 1 2017

Status: Assigned (was: Untriaged)
Found the spec for this:

https://heycam.github.io/webidl/#interface-prototype-object
"The class string of an interface prototype object is the concatenation of the interface’s identifier and the string “Prototype”."

Comment 2 by mgiuca@chromium.org, Feb 1 2017

Summary: Web IDL spec violation: Class name of prototypes should end with "Prototype" (was: String name of prototypes should end with "Prototype")

Comment 3 by mgiuca@chromium.org, Feb 1 2017 

I did some digging and found a way to fix the issue in the V8 Bindings code in Blink:
https://codereview.chromium.org/2666943003

However, there is a TODO there about breaking the garbage collection (which I don't understand), and that in fact may be the reason this doesn't comply with the spec in the first place. However, we can't be expected to use idlharness for writing layout tests until this is fixed.

(I don't intend to work on this, but my CL may be of use.)

Comment 4 by jsb...@chromium.org, Feb 1 2017

Mergedinto: 643712
Status: Duplicate (was: Assigned)
Duplicate of issue 643712

You probably want to see that bug for more context about why we haven't just done this so far - there's a lot of history here. :(

Comment 5 by mgiuca@chromium.org, Feb 1 2017 

#4: Weird, I just found  Issue 627604  which is also a duplicate and I was about to dupe this to that. Will dupe it to your issue.
►

Sign in to add a comment