Re: RfR: Progress Events Test Cases; deadline January 28

Jungkee - it appears there is quite a bit of implementation work needed 
before this spec can exit CR. Do you have any data regarding a timeline 
for when the implementations will be updated to conform to the CR?

FYI, I created the document 
<http://www.w3.org/wiki/Webapps/Interop/ProgressEvents> to summarize the 
status of the tests based on this thread. (A few followups below.)

Msger - Jungkee asked for your feedback below and again in <>. Would you 
please followup?

-Thanks, Art

On 1/31/13 6:24 AM, ext Jungkee Song wrote:
> Hi Art, Ms2ger and all,
>
>> -----Original Message-----
>> From: Arthur Barstow [mailto:art.barstow@nokia.com]
>> Sent: Tuesday, January 29, 2013 12:33 AM
>>
>> On 1/18/13 2:35 PM, ext Arthur Barstow wrote:
>>> <http://w3c-test.org/webapps/ProgressEvents/tests/submissions/Ms2ger/>
>>>
>>> If you have any comments, please send them to
>>> public-webapps-testsuite@w3.org  by January 28.
>> I reviewed Ms2ger's constructor.html and interface.html tests and ran them
>> (via the framework) on Mac OS with Chrome (24), FF (19) and Opera (12.12).
>> Below are some comments and results.
>>
>> I ran the constructor.html on a WP8 device running IE10 mobile and it
>> failed all tests implying that browser does not support this spec (I
>> didn't run interface.html).
>>
>> -AB
>>
>> = constructor.html
>>
>> test 1: Chrome fails isTrusted sub-test - returns "undefined" and
>> expecting false. Opera fails eventPhase sub-test - returns "2" and
>> expecting 0 (NONE). Implementation bugs?
>>
> This should be an implementation bug. In DOM4, it is specified that "The
> isTrusted attribute must return the value it was initialized to. When an
> event is created the attribute must be initialized to false." I think it is
> more like DOM4 test assertion but it should be addressed.
>
> This should be an implementation bug as well. In DOM4, the value e.NONE is
> specified as "Events not currently dispatched". It can also be treated as a
> DOM4 test assertion though.

OK, so bugs for Opera and Chrome.


>> test 2: fails on FF and Opera. Where is the requirement defined that
>> substantiates "There must NOT be a a initProgressEvent()"?
>>
> initProgressEvent() had been present until
> <http://www.w3.org/TR/2011/WD-progress-events-20110310/>  version and removed
> from<http://www.w3.org/TR/2011/WD-progress-events-20110809/>  version. As
> it's been replaced by constructor, it may not be supported any more.

Given this API was specified at one point in time, perhaps this test 
should produce a Warning rather than a Failure.

>> test 6: all the browsers fail this. Where is the requirement defined that
>> substantiates "document.createEvent() should not work with ProgressEvent"?
>>
> This is not allowed by DOM4 document interface definition. createEvent is
> supposed to work only with the strings and interfaces defined in the spec
> <https://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-document-crea
> teevent>. It is also described in the spec: "This method is pretty much
> obsolete as events have constructors these days, but needs to be supported
> for legacy content. Tough."

Perhaps this test should be part of the DOM4 test suite or it should 
produce a Warning rather than a Failure. (Also, your comments seem to 
indicate we need be clearer if a test is for the CR or the latest ED.)


>> = interface.html
>>
>> test 1: Chrome and Opera both fail the length sub-test - they return 0 and
>> "2" is expected. Where is this expecation of "2" defined? FF also fails
>> this test with length of "undefined".
>>
> length is the property of the constructor function object that specifies the
> number of arguments. It is expected to be 2 as defined in ProgressEvent
> interface:
> [Constructor(DOMString type, optional ProgressEventInit eventInitDict)]
> Hence, they should be implementation bugs.

OK, so fails on Chrome, Opera and FireFox.

>> test 2: FF fails the constructor sub-test - returns object and function is
>> expected.
> It seems the type of ProgressEvent.prototype.constructor must be function.
> It should be a bug.
>
>> Opera fails this test because desc.value is "undefined" and
>> expecting ProgressEvent.prototype.
>>
> The assertions in this test seem to be valid since the
> ProgressEvent.prototype object should be presence to define the attributes
> of ProgressEvent interface and the prototype object itself should not be
> enumerable, writable and configurable. Thus, this should be regarded as a
> bug.

OK, so different bugs for FF and Opera.


>> tests 3,4,5 - none of the browsers pass this test but it's not really
>> clear to me what specific requirements from the spec are being tested so
>> at a minimum, some context for these tests should be added.
>>
> I think these assertions are valid in testing the enumerability and
> configurability of each of the attribute of ProgressEvent. Hence, I think
> they need to be treated as bugs but I also have a comment on this test case:
>
> Ms2ger,
>
> - This test case doesn't take an assertion for writable attribute. Should
> the desc.writable be true or false?
> - Doesn't the assertion on configurable have to be
> assert_equals(desc.configurable, false) ?
> where configurable is,
> true if and only if the type of this property descriptor may be changed and
> if the property may be deleted from the corresponding object.

Ms2ger?


>> test 6 - passes Opera and FF and fails Chrome. Not clear where the
>> "Interface objects propoerties should not be Enumerable" requirement is
>> defined.
>>
> Ms2ger, could you explain this?

Based on Jungkee's followup, this is a Chrome bug.


>> test 7 - passed Opera and FF and fails Chrome
>>
> @Ms2ger, could you explain this?

Ms2ger?

Received on Wednesday, 20 February 2013 18:40:53 UTC