Bug in html/dom/reflection.js around valueOf

[tbroyer]

In html/dom/reflection.js, some tests are conducted with objects like

wpt/html/dom/reflection.js

Line 288 in adc1ac0

{valueOf:function() {return 3;}}],

I believe these objects are missing a toString:null (like some others have BTW).
Without the the toString:null, the attribute is actually set to [object Object], not to 3 as expected; turning them identical in effect to the {"test": 6} tests.

The tests pass because they all but 2 have a domExpected function that will actually compute an "unexpected" expected value. Of the two tests that don't have, clamped unsigned long will actually re-compute the domExpected later on, and double will never exercise them as all (tested) reflected double attributes have a customGetter that neutralizes those tests.

Context: I'm doing some research around attribute reflection related to custom elements (blog post) and started using the WPT html/dom/reflection.js, slightly modified, to test the behavior of custom elements. My tests wouldn't pass with a double property and debugging (adding more precise logging on test failure) led me to this bug.

[tbroyer]

Fwiw, there's another bug in the double tests, this time around -0: the idlIdlExpected lists -0 as the expected value, but since the attribute value is "0", the getter can at no point parse it to -0; the expected value can only ever be 0, never -0.

wpt/html/dom/reflection.js

Lines 540 to 542 in adc1ac0

	"idlTests": [ -10000000000, -1, -0, 0, 1, 10000000000],
	"idlDomExpected": ["-10000000000", "-1", "0", "0", "1", "10000000000"],
	"idlIdlExpected": [ -10000000000, -1, -0, 0, 1, 10000000000]

This is due to:

• the rules for reflecting an IDL attribute of type double, that will always serialize the value to the DOM attribute before parsing it back on getting
• the best represetation of the number n as a floating point number, referenced from the setter, that relies on the ECMAScript ToString, itself dictating that the number -0 is stringified to 0
• the rules for parsing floating-point number values, referenced from the getter, that will never infer a minus number from a string not containing a minus sign

Again, this test is actually never run due to the customGetter (by the way, one might notice that the progress element is of type limited double, that isn't supported by html/dom/reflection.js).

As this is closely related (if only because it's never actually exercised) to the valueOf-related bug above, I don't think this deserved its own issue, hence reported here as an additional comment.