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

Hi Art,

> -----Original Message-----
> From: Arthur Barstow [mailto:art.barstow@nokia.com]
> Sent: Thursday, February 21, 2013 3:40 AM
> 
> 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?
> 

I think the timeline would be depending on the browser vendors and WebKit
community. Anyway, I'll filing the bugs soon and share the status keeping my
eyes on the feedbacks.


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

Thank you so much. I think test case #1 and #6 in constructor.html should be
moved to DOM spec test. It is resorting to the implementation of Event
interface. E.g., WebKit Event implementation does not even have isTrusted
attribute at the moment.


> 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-documen
> > t-crea
> > teevent>. It is also described in the spec: "This method is pretty
> > teevent>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 Thursday, 21 February 2013 06:13:53 UTC