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

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.


> 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.


> 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."


> = 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.


> 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.


> 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.


> 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?


> test 7 - passed Opera and FF and fails Chrome
> 

@Ms2ger, could you explain this?


Jungkee

>

Received on Thursday, 31 January 2013 11:26:30 UTC