Keyboard events: want to be able to test US
ASCII, but also international keybaord. Want to test "given a
layout, what events are generated"

Being able to automatically change layout is
desirable.

Also generate dead keys

Also creating IME composition events

Those are the big things. Undoubtedly need
more

:)

<wilhelm> Scribe: wilhelm

simonstewart: Mouse is pretty
easy.
... There's a limited range of APIs that we're expecting to
generate.
... click, dbclick, contextclick, mousedown, mousedown.
... OS-level.
... These events are on the other side of the glass.
... How does the browser process all these things?
... We discussed yesterday scroll wheel.

garykac: Would that include
ticks? There's pixels and ticks.

simonstewart: Undecided.
... Keyboard: presskey, releasekey, send a string of
characters
... Just a charsequence.
... With webelement.sendkeys, we allow people to send
internationalized text

garykac: For Japanese, I don't
want to send the full string.

simonstewart: The commands on
webelement are do-as-I-mean.
... The advanced actions are do-as-I-say.
... Initial implementation just blasted the value in.
... To do the second case, there is the ability to have a IME
engine in the open source web driver.

MarcFisher: There are functions
to call, but they are not neccessarily working.

simonstewart: IME-handler
... Will list the available engines.
... Your test will be very brittle, as it relies on a specific
IME engine.

garykac: Scan code?

simonstewart: Initial
implementation does some calculation to figure out the scan
code. Specify A, queries the OS.

garykac: This needs to be
controlled in the tests.
... I want to test A on a French keyboard...

simonstewart: We're not an OS
level automation API, but browser. We'll take advantage of the
machine.
... For testing multiple keyboards, you may need multiple
VMs.

garykac: That will not work.

simonstewart: I'm not aware of
any cross-platform IME...

garykac: I thought we'd have OS
specific components.

simonstewart: And we attempt to
mask that.
... ChromeDriver, Marionette inject events right into the event
queue.
... Looks like it comes from the OS.
... FFdriver and IE on Win uses Win32 APIs.
... Error-prone.
... The OS makes some assumptions about focus of windows.
... For accurate emulation, you need to go through the Win32
APIs.
... These tests take a long time to run.
... Must be able to run without focus, for parallell
processing.
... spec has three audiences: People writing tests for their
web apps.
... Browser vendors.
... Spec editors.
... Low-level, cross-platform method is incredibly
challenging.
... TBH, we don't ahve the expertise around this table.
... Maybe you.

garykac: Injecting keyboard
events into @@ is something that we do.

simonstewart: Unfocused
windows?

garykac: Win yes, Mac no.

simonstewart: Mac has a mouse
window and keyboard window.

garykac: I have less concern
about the machine doing something else.
... Interop between browser vendors. Difficult to run tests
will not be run.
... You inject cooked browser events?

garykac: Section 6.3
... I'm going to be merging the UI events stuff into
this.
... SO that there is one canonical document.
... UI events provides more info on how awful keyboards
are...
... This maps to Windows virtual keys.
... Assumes we have a location field.
... This is only the non-printable.
... Separator?
... This also includes old keys.
... Media keys.
... You may want to refer to this and say "this is where we get
our values from".
... You may need location fields.
... This completely ignores Android + FirefoxOS, which we also
need.

simonstewart: So far we haven't
needed most of these keys...

garykac: Thank you for the
information!

simonstewart: I've learned a lot
about the horror that is keyboards.
... Reviews of our sections on this would be very
helpful.

PFWG PFWG

Michael Cooper, staff contact

@@, observer

@@, with IBM

MichaelC: A number of us were
here at TTWF. Some of this may be familiar.
... We want to sync the accessibility testing with other
testing.
... THis is an iteration of these efforts.
... IN the past few days we've got a better
understanding.
... Suggested agenda items:
... Developing accessbility tests from the point of view of a
developer who wants to ensure accessibility in the UA.
... We test tools, content.
... We talked about how WebDriver can be used to test web pages
in UA to see if accessibility features work as intended.
... May depend on things from WebDriver.
... How can we use WD to test accessibility tests?
... We develop ARIA, which could be tested that way.
... Considering accessibility tests that can be done like the
testharness.js, reftests...
... If we wish to add tests?

Janina: The best defined are the
UA interfaces to accessibility API.
... On their way to Rec.
... We're looking at that approach for basis for furhter
work.

MichaelC: What level of shared
knowledge do we have?

simonstewart: *describes the
purpose and functionality of WebDriver*

@@: JS in the browser?

simonstewart: No.

@@: Are you using Windows automation?

simonstewart: It depends.
... We need to be able to test browsers without window having
focus.
... We should be able to background the window.
... (Describes the three types of events and their
implementations.)

Cynthia: Assisstive technologies
use OS accessibility layers to interact with f.x. UA.
... Old MS API, IBM API, newer MS Windows automation...
... Windows UI automation was designed with a couple of ideas
that are different.
... To be used as a test driver in addition to
accessibility.
... Combine patterns. Invoke, selection.
... "This is an invokable thing, not just a button"
... You can combine patterns.

MichaelC: The accessibility APIs
do similar things, but vary between OSes.

Janina: Linux accessibility layer
used for testing Linux desktop.

<simonstewart> What was the
name of the linux project that uses accessibility testing?

Cynthia: You're doing
platform-specific work.

simonstewart: Yes, but hidden
behind the APIs.

Cynthia: We look at the markup in
ARIA or HTML and our document, "this document should have these
properties".

simonstewart: Forms of
accessibiltiy testig already done with WD include: test
tabindex.
... We also had element-by-ARIA.
... Could be used via XPath.

Janina: Would have been
useful.

simonstewart: We disucussed the
equivalent of a DOM in accessibility.
... Maps to DOM.

Cynthia: This exists, but outside
the browser.

Jason: Some UAs already have
OS-level accessibility integration. Unifying would be
good.
... Interested in interaction between this approach of testing
with WebDriver and Indie UI.

MichaelC: They are do what I
mean-events.

simonstewart: *describes the
three audiences of WebDriver*
... It sounds like you're interested in the first audience,
third audience.

simonstewart: You may be able to
do a lot of it already.
... Tabbing stuff should be easy.
... WebDriver has findElementByTagName.
... Tab, find the active element.

Cynthia: img.onclick, etc. are
tricky. Buttons are not.

simonstewart: Finding elements
with a click handler is more difficult.

MarcFisher: But possible with
JS.

MichaelC: Challenge with
accessibility spec testing: we have to test how the spec shows
up in different accessibility APIs.

Cynthia: You are using some of
those APIs for driving?

simonstewart: Chrome and Firefox
inject blessed events into their event queues.
... Nowhere near OS.
... We're trying to avoid the OS-level stuff, because the
requirement of not having window focus is important.
... QAs often don't ahve more than one machine. Must be able to
test while doing other work.

Cynthia: You're always going to
be looking at the role.
... Actual attributes.

MichaelC: We're looking at the
accessibility API...

Cynthia: COmpare expected results
with outout from OS-level API.
... Testing that the markup was mapped correctly to the
API.
... Manually, using inspector.
... SOme of these tools are automatable.

simonstewart: Focus of WD is
automating the browser. Already a massive challenge.
... If there was some common accessibility DOM in the OS, that
can be integrated with WebDriver.

<simonstewart> Not OS:
browser

<simonstewart> /accessibility
DOM in the OS/accessibility DOM in the browser,/

MichaelC: It sounds to me that
WebDriver would help us do some testing of the accessibility
specs.
... BUt not a lot.
... We've mostly been avoiding those, as they are all
manual.
... We can improve our test suite with automation.

simonstewart: WD is a library you
can use to poke the browser. You could use another library to
poke the OS accessibility layer.

MichaelC: More potential for
accessibility testing re: WCAG.

simonstewart: If there's
something we can do to facilitate testing of accessibility in
web applications.

Cynthia: Something that comes up
as a button in the accessibility API can be any element with
role=button.

simonstewart: It would be
interesting to track progress on Accessibility DOM.

Charter and plan forward

MikeSmith: Our charter expires at
the end of the year.
... dburns has already posted on the list about this.

dburns: What we're proposed is LC
around March next year.

Q1 vs Q2?

simonstewart: MY suggestion was
aim for Q2, with a checkpoint at the end of Q1.
... If we give us a too tight deadline and fail to meet that,
rechartering will be a pain.

<simonstewart> wilhelm: we
keep on setting dates in the calendar, but first of all we need
to figure out what needs to be done to get the spec and test
suite to where it needs to be

<simonstewart> scribe
simonstewart

<simonstewart> wilhelm: we
keep on setting dates in the calendar, but first of all we need
to figure out what needs to be done to get the spec and test
suite to where it needs to be

<simonstewart> ... does that
make sense

<simonstewart> ?

<dom> scribenick:
simonstewart

MikeSmith: I don't think it makes
that much difference on what we decide. We do need to
demonstrate progress and milestones to aim for
... as long as we have that, we're ok

plh: can go to management and say
that things are moving forward, though not at LC yet
... just a mattter of convincing colleagues. Not currently
getting pressure to actually getting it finished.

AutomatedTester: Another nice
thing is that we're further along in the implementations than
we are in the spec.

plh: only thing I'm worried about
is people who aren't sponsored by a company being able to make
meetings

wilhelm: one other thing that
we've discussed is scope creep. Solution proposed earlier is to
move unstable pieces to a separate document

plh: that's a common solution

AutomatedTester and simonstewart: both happy
to edit two documents

MikeSmith: other thing I want to
ask about is extension duration. Is there an outside limit?

plh: two years is a limit, but as
a checkpoint

MikeSmith: not planning on making
any changes to the charter itself.

plh: try to be realistic

simonstewart: so, milestones.
Work items first

MikeSmith: testing and spec work
are the two pieces.

simonstewart: going through the
spec and identifying things to pull out into 1.1 and fill out
placeholders

wilhelm: also need to look at the
OSS test suite for things that need to be specified
... suggests going through the OSS test and adding official
tests and placeholders for the spec
... added a wiki page (webdriver/testsuite) started listing
tests we don't have but should

simonstewart: do we want to go
through that suite now?

wilhelm: split up and do in
parallel
... maybe that's a day's work per chapter?

wilhelm: IME? lets move that to
1.1
... its currently unstable in all implementations

simonstewart: DOM events, UI
events... do we want to work with that in 1.0 or 1.1?

wilhelm: is that important for
now?

simonstewart: our keyboard
mappings are how we encode them for sending them over the
wire
... our commands are simple

Mfisher: we may need to tweak

simonstewart: at a later version
we may need to add to handle more DOM Events

mfisher: keyup and keydown is
missing?

simonstewart: its implemented in
the OSS project for all browsers

mfisher: the Dart implementation
may not have this information

simonstewart: are there other
ommissions that we need to put in
... we will move authentication to 1.1
... (explaining how authentication may work in the
future)
... Basic auth is important bug on the OSS project

simonstewart: for fleshing out
the text would be 2-3 weeks
... does logging and http
... David Burns can do user inputs
... and others can help too
... and then a few editing passes are required

we need to fix the WebIDL output

MikeSmith: we are going to be
doing snapshots regularly but we are getting away from that in
other groups
... we are going to be removing TR from robots.txt
... to make sure implementors always find the editors draft

wilhelm: we could do this
regularly

MikeSmith: to get to TR we need
to pubrules within W3C
... lets worry about editors drafts for now

MikeSmith: based on this and we
need to think about when we will hit LC

wilhelm: we are looking at 600hrs
worth of work

simonstewart: I am freeing up 1/2
a day a week

automatedtester: I am getting
more free time

MarcFisher: I should be able to
do 1/2 day a week too

AutomatedTester this is roughly 75 work days
(600/8)

ShuotaoGao: I can do that too

MarcFisher: we can do 3/4 days a
week by the sounds which is ~36 weeks

simonstewart: maybe we do a
writing week on this

(discussing F2F next year to get people to
work on spec)

Lunch!

<wilhelm> We reconvene at
14:00.

<jgraham> So, if anyone at
TPAC cares, I am about to talk about test code review and demo
review tools including critic in WebApps

<jgraham> There are plenty of
spaces

<darobin> ah shit, I'm in
another meeting

<ArtB> (Shenzhen meeting
room)

<ArtB> if you hurry, we can
try to find an empty seat for you ;)

MikeSmith: hey, do you need help
from a Bugzilla dev?

<simonstewart> scribe:
simonstewart

The Way Forward

AutomatedTester: Before lunch we
were talking about 36 weeks to get everything done.

wilhelm: that takes us to the
22nd July

MarcFisher: we could drop that
down if we did more work per week

AutomatedTester: That plus one
week contingency. Suggests 1st August 2014 as the LC date

wilhelm: suggests a full year
extension to the charter

AutomatedTester: Not sure how
long between LC and CR, and then REC

MikeSmith: LC comments period is
a minimum of three weeks
... commonly extends to six weeks
... most people wait until the end of the LC comment period
before submitting comments
... takes a week or so until after comments close before you
normally publish another draft
... need to write up a Disposition of Comments documnet
... minimum of a month from LC to CR.
... One thing to mention: we could skip CR so long as we were
confident that we would meet our CR exit criteria (normally 2
interoperable implementations)

<scribe> ... (done by each
statement in the spec that gives a conformance requirement)

UNKNOWN_SPEAKER: Can do this if
you say upfront in the LC draft to transition directly to
PR

simonstewart: would we need to
recharter to handle 1.1?

MikeSmith: the charter doesn't
limit us to only one document

wilhelm: should we charter for
two more years so that we can move to 1.1 after 1.0?

MikeSmith: we don't need to come
up with a new charter if there's a new deliverable after
1.0
... suggests chartering for two years
... within two years we may want to recharter. Or we could
declare victory and finish
... Though I think we should keep the group open, since people
will start reporting issues once they start using the
spec.
... * the story of XSLT 1.0 in browsers *

wilhelm: suggests describing 1.0
as a feature set, rather than "being complete", to allow for
changes

MikeSmith: this gets to the
difference between a living standard, or having separate
levels.
... within the W3C model, levels seems like the way to
go.
... So for now aim for LC in August? Build into the schedule a
CR period, but can consider in August if we need to