SV_MEETING_TITLE -- 08 Jul 2015

<garykac> Hello. I'm not on the call because I forgot my laptop today... :-(

<garykac> But at least I'm here. ^_^

<masayuki> Hi!

Excellent.

If you want to use a regular phone to dial in: +1-617-324-0000

Code is: 647 802 277

So... agenda?

<garykac> Testing. Specifically, the doc that you sent out.

I commited the code to web-platform-tests this past week.

<garykac> I'd also like to have a set of short-term goals. Targetting something around end of September.

Ok. Anything else?

<garykac> For example, test a few events. Verify in multiple browsers. et al.

<masayuki> My important issue is https://www.w3.org/Bugs/Public/show_bug.cgi?id=21120

OK. So:

1. Goals (short term & testing)

2. Bug 21120

3. Testing framework (Travis)

Anything else?

Alright. Topic #1.

<garykac> That's probably enough for today.

Gary you mentioned targetting something for end of Sept.

Were you thinking of a re-publication of the spec, or something else?

<garykac> Getting a new spec published would be rather ambitious.

<garykac> I was thinking more in terms of tracking progress on the testing front.

Clearly the major effort for us will be on the interactions and order of different events in relation to each other.

<garykac> It would be nice to start picking off a few bugs as well. E.g., the ones that Masayuki wants prioritized.

<garykac> Re: event ordering. I didn't see support for ambiguous ordering -- events can occur in either A>B or B>A order.

<garykac> Do we have situations where we have a sequence of events, but a few of them don't have a strictly defined order?

<garykac> Something like ABCDE nad ABDCE both being valid.

We may in regards to composition events or key/down up pairs.

<garykac> I'm not sure if that's needed. We probably won't know until we start digging into the testing.

When you say "support" what do you mean?

<garykac> I think it sounds like something that could be added later, but I wanted to bring it up.

<garykac> by support: I mean creating a single test that accepts either ABCDE or ABDCE as correct event order.

That shouldn't be a problem.

The framework I wrote just records what happens, it doesn't prescribe a "right" or "wrong" answer--that logic still needs to be authored by the test author.

In regards to bugs, I counted 9 bugs that are related to key names/processing.

We could set a goal to work through all those 9 bugs by Sept.?

<garykac> that sounds good.

<masayuki> Sounds good to me too.

<garykac> I haven't yet updated the spec now that it lives in the new location.

<garykac> I need to get set up to do that...

I find it a bit easier to work with--you can even update directly through the Github website if you wish :)

<garykac> Yeah, I'm sure it's not that hard - it's just doing it the first time.

Q: regarding new keys... do we need to add low-level mapping key/code values for any new "key-like" think that exists in all the world?

(e.g., new TVs and remote controls in Asia, etc.?)

It seems like an intractable (and never ending) problem.

<garykac> We *don't* want to say the people can add whatever codes they want.

<garykac> The only alternative is to specify all the keys that people would be tempted to add.

<garykac> We don't have to do them now, but we can play whack-a-mole as they come up.

<garykac> [edit] We don't have to do them *all* now...

It seems like for some specific scenarios, should it be OK to overload some kind of user-defined key/code values?

Hardware people are coming up with new buttons with new labels and associated control codes all the time.

Is it the responsibility of our spec to define everything that could eventually, maybe, be used in a browser?

It seems like we are going the wrong direction--all these key codes make it _harder_ to author websites that will just work across a variety of platforms...

<masayuki> At least web apps installed into such device need to distinguish what button in remote control is pressed.

<garykac> Yes, but we don't care about vendor-specific buttons on remotes. But once they're defined in something like Android or iOS, it starts to make sense to think about including them.

<garykac> I'm assuming that anything defined by (say) Android can occur in an Android browser.

<garykac> But perhaps that's a mistaken assumption.

Android (the OS) is larger in scope than Chrome right?

<garykac> Yes.

<garykac> Hmmm....

Well, if the OS can generate the key code from some supported hardward, then it probably goes to the browser as-is...

Perhaps I'm just complaining about all the keys and codes that I'll never user.

<garykac> It's a valid concern.

<garykac> I'd like to only add keys that can be generated by a virtual keyboard (and thus, can make it into the browser).

<garykac> Thinking about it now, I'm not sure if all of those keys satisfy that constraint.

Well, let's evaluate the set of 9 bugs we have on the subject, and see if we can get resolutions in the bugs for what we want and don't. It doesn't make sense to speculate here.

What would be a good goal for testing?

<garykac> Have a framework (kinda done)

<garykac> Write some number of tests (probably small to start with0

Well, today we now officially have 1.

<garykac> Make sure we're evaluating on multiple browsers

I'll transition to my topic.

http://w3c-test.org/uievents/

<garykac> Get feedback from the browser vendors about our approach.

We now have an official home in web-platform-tests.

I've created some basic directory structure based on Gary and I's initial brainstorming.

First test to validate the framework script I proposed last week: http://w3c-test.org/uievents/order-of-events/mouse-events/

You can view the source to see what I did.

I made the mistake of direct-checkin to master on web-platform-tests (and broke the build as a result).

Subsequent commits will be done via pull-request.

:-)

This mouse events tests was the simplest that I could conceive.

I also looked briefly at the web-driver tests.

It seems that we should be able to hook up webdriver to automate a large portion of our manual tests.

I'm still unsure how webdriver will handle input like dead-key simulation, crillic keyboard layouts, etc.

<garykac> The mouse-event passes even if you enter/leave box 1 multiple times and then enter box 2 (from outside box 1). I would have expected the event order to be different enough to complain.

Yeah, we can change that. Just need to add handlers to the space around the boxes.

It was originally done by including the raw test in an iframe, but it didn't seem strictly necessary, so I merged the test container and the iframe together.

Is the pattern appropriate for testing?

<garykac> I expected multiple mouseenter/mouseleave pairs for box 1 to be enough to make the test unhappy.

<garykac> In any case, it looks great!

<garykac> It's nice to have this as a starting point for the tests.

Yes, you bring an interesting point--the test only tests mousemove in isolation--no other events are tested--yet you almost need to test ALL the related events in sequence to make sure it's all working correctly.

(Start small)

Gary, want to try writing a followup test using this framework this week?

<garykac> Since this is a manual test, it would be nice to have the user do something (like move the mouse) and then run a whole bunch of event order tests.

<garykac> But we also would like each test to be small and self contained.

Both options are available.

I kept it simple with one test in one file.

<garykac> Perhaps: Test groups as associated with a single user action (moving the mouse between boxes). and we have a number of tests for that particular group.

Sounds good to me. Nothing like getting your hands dirty to see what works and what doesn't.

<garykac> That keeps tests small, and the user/tester doesn't have to repeat the same tedious action for each test.

<garykac> Yeah.

<garykac> Anyway, I'm out later this week.

:-(

<garykac> I won't be able to play with this until Aug.

<garykac> (although I want to)

Perhaps I can make some more progress on the 'test group' concept.

<garykac> How about we set that as a goal for end of Sept.

OK.

masayuki: are you interested in contributing?
... you are welcome to.

<garykac> A user-action-group with a small set of associated tests.

Proposed goals for Sept.:

* A user-action-group with a small set of associated tests.

<masayuki> Hmm, I'd like to do that, but I have a lot of bugs to be fixed by the end of Sept...

* Resolve 9 bugs dealing with adding new keys/codes.

Gary has been sending ideas for tests--thanks Gary.

<garykac> masayuki: The most important thing would be to get feedback on the tests.

I'd like to also capture those somewhere.

<garykac> Goal: * Get initial feedback on tests from browser vendors

<garykac> I think those 3 things capture what we can reasonably expect to fix in the time (since we have a variety of vacations during this period)

<masayuki> garykac: So, you mean, I should check the tests you will create? Then, perhaps, I could.

I can have some folks from MS look over it. The fella that wrote some of the original events tests is still here :-)

<garykac> masayuki: yes, any feedback on the tests (once we have some) would be great.

Between the three of us, we can have feedback from Mozilla, Microsoft, and Google. :) Have any good contacts at Apple?

rniwa might be helpful

<masayuki> How to post feedback for them? bugzilla? github? ML?

<garykac> No, but I can ask around once we have something to show.

<garykac> Yeah, Ryousuke might be a good person.

On feedback: if we use Github issues for Web-platform-tests they might get lost in the crowd.

<garykac> (err... that wasn't intended to be a general comment on goodness....)

<garykac> At this point, we can track issues in a single doc (or bug if you prefer). Once things have stablized, then github issues will be more apprpriate.

But, github issues are the standard way to go. You can also tag people in them to get our attention.

We have this bug we could use for initial feedback: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25967

<garykac> I don't feel strongly either way. We can play it by ear.

<masayuki> For checking if each test is tested, managing with single document (like Google document) isn't so bad way.

We were also thinking of cross-linking tests into our spec to keep better track of them.

<garykac> Well, we can work out those details later.

<garykac> When are we all available to meet next time?

Gary, what is your vacation plans? Back in August?

<masayuki> 14 and 21 is avaialbe, but not so 28.

<garykac> I'll be out until late Aug

<garykac> Aug 25 might be the next time...

I'm gone from next monday to the 23rd, so 28th would be my soonest.

<garykac> But you could meet earlier...

I could meet Aug. 3, or 25th.

<garykac> Aug 4, 11, 18, 25.

Uh, 4th or 25th.

<masayuki> Currently, I have no plan in Aug, so, I must be available every week in Aug.

<garykac> I'll talk to you all on Aug 25. If you decide to meet earlier, I'll catch up by reading the log.

Well, can we check in on the 4th? We won't have Gary, but it will help force me to work on the testing.

<garykac> sgtm

<garykac> ^_^

<masayuki> OK.

<garykac> OK. I'm checking out now. I'll talk to you all later.

Thanks Gary!

masayuki: hear from you again on the 4th.

<masayuki> Travis: yeah, see you.

<masayuki> (starting another meeting now...)

- DRAFT -

SV_MEETING_TITLE

08 Jul 2015

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output