Web Events WG Voice Conference -- 11 Sep 2012

<scribe> Scribe: Art

<scribe> ScribeNick: ArtB

Date: 11 September 2012

<smaug_> argh

Tweak Agenda

AB: yesterday I submitted a draft agenda http://lists.w3.org/Archives/Public/public-webevents/2012JulSep/0020.html. After I submitted the agenda, there was a short exchange between me and Rick re test results for TEv1 spec and if there are related follow-ups, we can discuss them during the Testing topic.
... Any change requests?

<smaug_> ArtB: ^

<smaug_> I'm in a bad place without external mic

Announcements

AB: any short announcements for today (I don't have any).

Testing the Touch Events v1 Candidate

AB: so, the general topic is "what must be done to complete a test suite for the TEv1 Candidate?" http://www.w3.org/TR/2011/CR-touch-events-20111215/. There are also a few sub-topics I want to discuss.
... re the existing tests ...
... yesterday I did a line-by-line review of Matt's single-touch tests http://w3c-test.org/webevents/tests/touch-events-v1/submissions/Mozilla/.
... I think they are all good tests. I was pleasantly surprised by the coverage because the report says 17 tests are run but depending on how one counts, that file includes over 40 assertions.
... some related sub-topics are: 1) how does the group comes to consensus on the "goodness" of a test?; and 2) how are "good/approved" tests designated as such?
... the WebApps and HTML WGs handle these two issues by having an explicit "Call for Review" (CfR) for tests with a fixed period. If no negative comments are submitted, the tests are copied to an "approved" directory (f.ex. http://w3c-test.org/webapps/DOMCore/tests/approved/). I'd say that process work "reasonably well".
... I think we're going to need something like this
... any comments on how we should address these two issues?
... an advantage is that it is lightweight

… and I'm willing to do the admin stuff

AB: any comments?

<smaug_> would be really nice to get tests also from others than just Mozilla

… hearing none, I propose we adopt a similar model

AB: any objections to WebEvents adoptiong a similar test approval process?

[ None ]

RESOLUTION: WebEvents will use the same test case approval process that is used by the WebApps and HTML WGs

AB: I can start a CfR for the single-touch tests and a separate CfR for Olli's multi-touch tests. How much time do people need?

RB: I already worked reviewed them

SM: the process is a bit different than what we use

… so that is my objection

<smaug_> it varies how many tests one test file actually has

<smaug_> I mean, it varies in webapps too

SM: it's not really an objection

… I may be able to reuse some of Opera's tests

<smaug_> IIRC multi-touch.html was mainly as an example how to add tests for multitouch

… and that can take some unpredictable amount of tests

RB: but those are two different issues (reviewing existing tests and submitting new tests)

… I'd like to submit some too

SM: yes, I guess you're right

AB: any objection to two week review for the existing tests?

[ None ]

AB: I can start a CfR for the single-touch tests and a separate CfR for Olli's multi-touch tests; two week review period
... so Olli, are you OK with starting a CfR for the mulit-touch tests?

<smaug_> I don't think that is needed

<smaug_> IIRC sangwhan or someone was going to write more tests

<smaug_> based on the multi-touch.html test

AB: so Olli, you mean they aren't ready for review?

SM: I'd like to convert our tests to testharness.js

… but I don't have approval for that yet

<smaug_> ArtB: multi-touch.html is ok, but we may want to split the tests differently

<smaug_> I mean, to more files

RB: I think talking about organization make sense

<smaug_> sounds quite nice

<rbyers> Question on test organization seems coupled to the question of whether the test suite will be manual-only

<rbyers> If so, organizing to minimize the number of manual steps required seems critical

AB: yes, that make sense
... my recommendation is that we do a CfR for the multi-touch tests too and then reviewers can comment on whether or not it would be better to split the file until multiple files

<sangwhan> my question "has any WG started using webdriver/selenium/watir?" was sort of related to the point that rick raised, in a sense that manual tests are no fun so either make a manual test test multiple things with minimal user interaction possible, or split everything up but do it in something like webdriver/selenium/watir to make tests less painful

AB: any objections to two CfRs now?

[ None ]

AB: so I'll start two different CfRs

<smaug_> webdriver/selenium etc don't work everywhere

<sangwhan> that's true

AB: there is some work being done by the Browser Test Tools WG

… I don't follow that group closely

… but I can find out their status re WebDriver

<scribe> ACTION: report on the status of WebDriver work by the Browser Test Tools WG [recorded in http://www.w3.org/2012/09/11-webevents-minutes.html#action01]

<trackbot> Sorry, couldn't find user - report

<rbyers> Right, I propose that the tests should always have the option of being run manually

<scribe> ACTION: Barstow report on the status of WebDriver work by the Browser Test Tools WG [recorded in http://www.w3.org/2012/09/11-webevents-minutes.html#action02]

<trackbot> Created ACTION-97 - Report on the status of WebDriver work by the Browser Test Tools WG [on Arthur Barstow - due 2012-09-18].

<rbyers> so that we can test on any sort of browser / mobile device...

RB: want to make sure the tests can be run manually

… so can run on any mobile devices

AB: I agree

<sangwhan> Fair point, yes

AB: we haven't really talked about basic principles or constraints or requirements re testing

… if someone wants to do so, that would be good

AB: so the next question is how many more tests are needed to test the CR?
... some gaps I noticed when reviewing single-touch are: the 3 methods that extend the Document interface http://www.w3.org/TR/2011/CR-touch-events-20111215/#extensions-to-the-document-interface; cancelevent (could be hard to automate?); preventDefault
... I guess there is also Cathy's analysis to use
... how are we doing to determine "the test suite is done"?

<smaug_> ( multitouch case will need plenty of tests for various touch lists)

… that question could be a bit premature if people haven't yet reviewed what we do have

RB: one thing I am struggling with is the level of UA details

… e.g. preventDefault

… could be hard f.ex. to determine exact coordinates

AB: that's a good point

… and to extent I think that comes back to some previous discussions we've had regarding the level of depth testing we need to do

<smaug_> (Default handling is defined in the spec for certain cases, so there is stuff to test)

AB: do we have any volunteers to help us figure out a plan for the testing?

RB: I volunteer to review the spec (as I'm analyzing the existing tests) and note those areas that are not tested

… What do I do if I want to create some new tests/assertions?

<smaug_> would be nice to get patch files if one decides to also fix testcases, not only review them

AB: I would say bug fixes and smalll additions could be done directly

<sangwhan> forking/branching is definitely a option, .patch is a option, committing directly to tip would be another option

… for more significant additions, a separate file may make more sense

AB: I'd say that people should make a recommendation

RB: ok, I'll take an action to create one test before the next meeting

<scribe> ACTION: Rick create a new test case for the TEv1 spec [recorded in http://www.w3.org/2012/09/11-webevents-minutes.html#action03]

<trackbot> Created ACTION-98 - Create a new test case for the TEv1 spec [on Rick Byers - due 2012-09-18].

SM: if the spec is underspecified re UA behavior, I'd like to hear about it

RB: for example the scrolling text in the touch event text leaves a lot of flexibility for UAs
... perhaps the test suite should just focus on the API and not UA behavior/semantics at all

AB: in general I agree

… and in that sense, the text as written today is "good enough"

AB: I'll ping Matt about his action related to "so, what test cases are missing from the v1 test suite"
... anything else for today on testing?

Encourage more consistent semantics of Touch.identifier?

AB: Rick started a thread about Touch.identifier http://lists.w3.org/Archives/Public/public-webevents/2012JulSep/0017.html.
... I think one of the main questions is if the spec is under specified re Touch.identifier and/or if should additional non-normative hints should be provided

RB: this came from a demo I wrote

… it showed colors are different from iOS and Adroid

… I used identifier to influence color

… Behaviour differences can be a problem though

… some people will consider this as a bug

… Re the spec, the existing text re identifier may be OK

… but we should talk about it

<smaug_> IMO the spec is clear enough. id is id, not any specific number. (Perhaps id should have been string)

… May want all of the implementations to do the same thing here

<Cathy> Is this related to a previous issue we had? - http://www.w3.org/2010/webevents/track/issues/15

SG: re Msft's PointerEvents, they reserve id 0 for the mouse

… all pointer events that come from the mouse have the same identfier

… SG: http://lists.w3.org/Archives/Public/public-webevents/2012JulSep/0018.html

RB: we could say id 0 is reserved

… So Matt raised this issue back in April

… Oh, this explains Chrome's behavior

<smaug_> I haven't seen any bug reports in Mozilla's bugzilla about this issue. Are there any in webkit's bugzilla or in Opera's bug database?

… and the spec was changed based on Matt's feedback

SM: I don't think Safari will change its impl

<sangwhan> The main issue is that current implementations will probably not change based on a constraint that is introduced in the specification, namely the first implementation of touch events

AB: so what do you think Rick?

RB: I didn't realize a previous decision has been made

… I think we will probably mean we will change Chrome to match iOS

… Would like to hear from others

… Should we intentionally constrain impls here?

<sangwhan> Opera does follow the algorithm that Matt mentions in the issue noted above, with a exception that the non-primary touch points will change identifiers, which is due to how we internally handle touch points

AB: there is needs to be a balance

… and need to reflect what's been implemented

<rbyers> sangwhan: what do you mean 'change identifiers'? It can't change while the touch point is active, right?

<sangwhan> e.g. So first two touches will be [0,1] but the second will be [0,2] and the third with three touch points will be like [0,3,4] (I'm not testing this live, so that's just a idea)

<rbyers> Makes sense

SM: need to know the primary touch

… perhaps we can add a small constraint re the primary touch should be 0

RB: should we put something in the spec that mobile Safari will never conform to

SM: yeah, this is a tricky call

… if we add that small constraint, I don't think we will have a large interop issue

<smaug_> why you need to special case the "primary touch". Shouldn't that be [0] in the touch list

SG: if you have a "primary" touch, then a 2nd and then lift the first finger, the 2nd becomes the primary

AB: should we take this to the list?

RB: I think it would be OK to keep v1 as is and to consider this change for v2

… would that be OK?

AB: yes, that would be OK

<smaug_> arg

RB: I don't feel strongly enough about this to not change v1 at this point

<sangwhan> Either way works for me (less editing, at least ;))

AB: any additional followups should be done on the list

<smaug_> thanks

AoB

AB: any other business/topics for today?
... re next meeting ...

… I say in two weeks (CfRs will have been done)

… meeting adjourned

- DRAFT -

Web Events WG Voice Conference

11 Sep 2012

Attendees

Contents

Tweak Agenda

Announcements

Testing the Touch Events v1 Candidate

Encourage more consistent semantics of Touch.identifier?

AoB

Summary of Action Items

Scribe.perl diagnostic output