<lukeis> :yt do you know the way to san jose

<selbot2> Do You KNow the Way to San Jose by Dionne Warwick - http://www.youtube.com/watch?v=jqWt49o7R-k&feature=youtube_gdata

<ato> AutomatedTester, simons: https://github.com/w3c/webdriver/pulls

<mdas_> .

<selbot2> simonstewart

<ato> Scribe: ato

Finalise wire protocol endpoints

wilhelm: Who wants to lead the discussion?

<simonstewart> https://code.google.com/p/selenium/wiki/JsonWireProtocol

simonstewart: I can kick it off.
... I suggest we use these ones, which are the endpoints that are currently used in the open source Selenium project, and which all the implementations are currently using.
... Obviously the ones we've punted on won't be there.
... And we've discussed the endpoints for the advanced user interactions in the previous meetings.
... Things like logs might be there.
... Use RFC, instead of strange syntax we use here.
... Seem ok?
... Given discussion yesterday, they are relative paths.

jgraham: What are the actual changes here?

simonstewart: Not many. I didn't add it to the agenda.

wilhelm: Is there any controversy here?

simonstewart: The set of command we have in the W3C spec is a subset of the ones in the open source project, with some additional endpoints specific to the spec.

Automate_: getElementRect

MarcFisher: maximise/resize window
... Discuss changes over the email list.

simonstewart: Are we basically there?

sam_u: 19.1, we're going to have vendor specific prefixes for command names?

simonstewart: 18.2 describes the protocol.
... So it's the next section.

JohnJansen: And we're getting rid of the command names, right?

simonstewart: Yes.

MikeSmith enters.

wilhelm: Then we're done.
... Let's do the manual test automation.

<JohnJansen> scribe: JohnJansen

WPT and Manual tests

UNKNOWN_SPEAKER: projector is warming up. slowly.

jgraham: want to use webdriver to automat manual tests at the w3c
... fairly interesting use case
... no page to inspect, instead you have scrip that sets up state
... tests can be split over multiple files and is magic
... so we want to write the webdriver test to be in the same page

ato starts to show slides

ato: need to integrate with wpt runner
... certain tests cannot be automated via runner (visuals, eg)
... webdriver can do all of these
... examples of unautomatable (onkeydown, onkeypress)
... eg:

<ato> http://localhost:8000/html/editing/focus/focus-02-manual.html

<ato> http://w3c-test.org/html/editing/focus/focus-02-manual.html

ato: walking through code
... lots of stuff necessary here that test author should not have to care about
... what if we had an interface from the JS test to the WebDriver controlling the browser?

<simonstewart> Ah! WebDriverJS. We have this! https://code.google.com/p/selenium/wiki/WebDriverJs

<simonstewart> In particular: https://code.google.com/p/selenium/wiki/WebDriverJs#Working_in_a_Browser

ato: essentially the wpt tests only need a small feature set from WebDriver
... prototype of webdriver.js
... possibly we can reuse from Simon pasted above
... you do face xorigin issues
... so the xhr is forwarded

seva: you wrote bindings to control this?

ato: yes.
... this reduces the overhead test authors need to worry about

JohnJansen: is this code available to see?

ato: not sure where it is right now, but will find it
... this is not dependent on node

simonstewart: is there any issue with using webdriver.js?

jgraham: licensing?
... we want the whole of wpt to be under the same license

ato: technology choice is not the considersation, the use cases are
... we have 3 technoolgies to think about: python, JavaScript in the page, python hybrid

wilhelm: i love this. it will reduce friction.

jgraham: dev wants to submit tests and is asking for a way to write tests with events

mikesmith: not a lot of devs lining up to write WPTs now. We should remove any blockers. We want web developers to submit tests.
... nice to make it easier for individuals to contribute in some small way
... this seems like a good way to go

simonstewart: my only concern with javascript only is that it's a lot of code to make it nice

jgraham: it would have to be async to use webdriver at all
... else we need inbrowser specific apis for testing that are not webdriver at all
... people will be increasing used to writing this

seva: webdriver has its own promise api

jgraham: longer term plan for javascript has a concept of wait

seva: one potential problem: browser needs to be compliant enough for this to work

https://status.modern.ie/promiseses6?term=promise

jgraham: adding polyfill for this or other huge libraries is not desirable

ato: found that writing this prototype is not that much (350 lines?)

simonstewart: true, it will get more complex with conditionals, etc

jgraham: we have a corpus of tests already we can check this against

MikeSmith: wants to be able to free up time to help

ato: getting jgraham, ms2ger, etc into a room to discuss would be good

jgraham: probably don't really need to add too much right away

wilhelm: only need to solve the 95% case, not the 100%. We do not need to aim for the sky.

jgraham: core of the problem is that webdriver is synchronous

ato: wpt opens the browser window, then opens a window to run tests
... looks like a bug because I cannot attach to the new window correctly

jgraham: just look at the manual tests for now

ato: wite a custom reporter? maybe stream them out somehow

jgraham: yes. and if we can only do so for the manual tests, that should be fine

<scribe> ACTION: on MikeSmith investigate requirements for automation of existing manual tests [recorded in http://www.w3.org/2014/10/31-webdriver-minutes.html#action01]

MikeSmith: this is where the subjct matter expertise is, so we need to be the group that determines if this is the right thing to do

seva: we should consult with Jason on this (jleyba)

<scribe> ACTION: simonstewart figure out what thing we want to use (webdriver.js v this new stuff) [recorded in http://www.w3.org/2014/10/31-webdriver-minutes.html#action02]

ato: what does that action mean?

MikeSmith: it's a recommendation

jgraham: we need to make sure wpt run against the latest version

ato: how do Microsoft and Google feel about this?

JohnJansen: seems OK, but I need to see how it actually works in the browser

sam_u: seems fine, but getting it into the CI - I don't know if I can commit to doing that right now.

[ Break until :40 ]

<juangj> RRSAgent: this meeting spans midnight

<ato> Ms2ger: We'd like to find out what the use cases and features needed to automate the manual tests in wpt.

<ato> Ms2ger: So that we (the WG) can make a recommendation on what we think to be the best technical solution for employing WebDriver.

<ato> DA BOOG: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26147

<simonstewart> :gist

<selbot2> Please paste >3 lines of text to https://gist.github.com

<ato> Scribe: ato

<simonstewart> https://gist.github.com/shs96c/84d94aa2b9d978718db3

Attributes and properties

<simonstewart> That patch needs to be applied to the tip of the current version of the webdriver spec

<simonstewart> Then just go to webdriver-spec.html#widl-WebElement-getElementAttribute-DOMString-DOMString-name

<simonstewart> "Just"

Ms2ger: You might want to pay attention, since you raised the bug.
... You might want to pay attention, since you raised the bug.

simonstewart: Is this algorithm better?

jgraham: Than what was there before?

simonstewart: Yes.

jgraham: At first glance, yes.

jimevans: I'm going through it.

jgraham: I'm very confused why you convert stuff to string in the end.

simonstewart: Return value was always a string.

jgraham: That's just weird.

MarcFisher: It makes it easier to implement client bindings.
... If you know that attribute will return a string, it's easier to implement in languages like java.

simonstewart: Yeah, you avoid having to return Object.

jgraham: I mean it just means it returns less data.
... Properties and attributes are different here.
... An attribute is always a string, property might be another type.

simonstewart: Do you want the history of how this came to be?

jgraham: No.

simonstewart: Then you'll forever be puzzled about why this is the way it is.

MarcFisher: Assuming that we want to keep this behaviour, the only change I'd probably want to recommend, seems like we're encouraging people to make mistakes.
... Step 3.
... Top-level step 3.

simonstewart: In Google.
... The terms were used interchangably.
... readonly and className tend to be the ones were people just don't know.

wilhelm: What is the controversy?

simonstewart: Return type.

ato: We should return string if we don't conflate.
... But we should return complex object if we do.

simonstewart: This is the result of six years worth of people using WebDriver and filing bugs they just don't understand.
... This is why we conflate.

jgraham: So taking a step back.
... What's the value proposition of this being part of the server and not the client?

simonstewart: If we put in the client Microsoft and Apple can't use it.

MarcFisher: I think the local end should be free to expose what they want to a certain extent.

simonstewart: Yeah, so they have the option of not exposing this method.

MarcFisher: Selenium could expose this via executeScript.

simonstewart: What if we rename it?
... For me it's just a useful handle.

MarcFisher: Does the spec actually need to define this behaviour?

simonstewart: Yes, developers and QA aren't going to be looking at the spec.
... Consistent, clear, and unambiguous.

MarcFisher: The browser has no effect on it.

jgraham: If you implemented this in JS and the client bindings executed that JS, the behaviour would be the same in all browsers.
... All you're doing is that you're pushing a high-level primitive on to the wire.
... Do we want to support the extra weight?

simonstewart: I believe it is.
... The original version of this is called getAttribute because that is what it used to be name.
... People passed in class and it didn't return what people thought it would.
... TL;DR: People don't understand the difference between property and attributes.
... So we special cased some things.
... [explains history]
... People didn't want to deal with the specifics.
... That explains the special-cases.

MarcFisher: OK.
... So given this history, so I would argue that the history supports that this should not be in the spec.
... It's an evolving thing based on particular instances of people making certain types of errors people make.
... We're fixing on the errors we've seen up to this point.
... If Selenium provides an executeScript based version of this, then they can evolve that in the direction of what is appropriate in their use case.

jgraham: Very clear example: Any other property that has some complex value, that doesn't just return a string, is going to return Object-Object in this case.
... It's going to be completely useless.

simonstewart: So you're worried about future-proofness?

jgraham: Well sometimes is useful sometimes not.
... We can't change it once the spec is there.
... We can't extra special cases in the future and break people's code.

simonstewart: No we have to be super-cautious.

MarcFisher: The level of cautiousness in Selenium is MUCH lower than the level of cautiousness we need to exercise here.

simonstewart: This method has been stable for long.
... We're trying to make people's lives easier and better by providing this spec.
... Most people in this room understand the difference between properties and attributes.

jgraham: You can have a non-normative appendix you can say that we have found that this approach is useful when implementing client bindings.

jimevans: It's better served only implemented in the JS using executeScript, there are any number of other methods in the spec that this also applies to.
... I understand where the argument is coming from.
... Why do we want to special case this one?

MarcFisher: Because this one is contentious.

simonstewart: I think it's just with the name.

ato: No.

simonstewart: Your argument is that we should get rid of all of these other methods.

jgraham: Yeah, I do kind of think that the visibility stuff is faintly ridicolous.
... And there is a fairly strong argument to not have this in the specification.
... Because it's not backward compatible in the future when we add new stuff, because we might break people's code.
... But yeah I agree, it's putting high-level stuff in the protocol is dangerous.
... Tag name is clearly not going to change.
... It's fairly low-value to have it in the protocol, but it is fine.

seva: Maybe the problem is not the high level commands, but the algorithms.

simonstewart: You need visibility to be strongly defined.

jgraham: I think if it's very stable, I think you have a much weaker argument to do that.
... Is it going to be the case in five years time, that people are going to stop using this stuff because it's broken.

ato: Is it possible to put this in an extension to the spec?

jgraham: Is the point of this spec to provide interop between different local end implementation, or just to provide a wire protocol.

[much discussion on the same things scribed above]

simonstewart: The reason this has value to the user, when you call this you get back the same in all browsers.

jgraham: There's nothing in the spec that says the local end can't implement something else for all of these methods.
... Just because it's in the spec, doesn't mean you need an endpoint for it.

simonstewart: Whose the audience of this spec?
... It's the QAs and developers.
... If I put on my implementor hat the perspective is different.

<lukeis> what do we want? time travel! when do we want it?

<scribe> ACTION: Land current diff, do an update of that which includes reference to the reflecting attributes in HTML5. [recorded in http://www.w3.org/2014/10/31-webdriver-minutes.html#action03]

<mdas> https://dvcs.w3.org/hg/webdriver/raw-file/tip/webdriver-spec.html#interactions

Touch Events

mdas: I need some clarification.
... I don't know where to put all the terms I want to define.
... But they make it easier to explain what my intention is.
... I wanted to rename input device to input source.
... Does that make sense?

<scribe> ACTION: mdas to rename input device to input source [recorded in http://www.w3.org/2014/10/31-webdriver-minutes.html#action04]

Conclusion about releasing events when action chain finishes.

Batch -> tick

jimevans: Omnious?

mdas: Tick will be replaced.

jimevans: I like batch better than tick.

wilhelm: Which one will be the current?

mdas: Tick.

jimevans: I prefer batch.
... I don't care /that/ much.

<scribe> ACTION: mdas to rename batch to tick [recorded in http://www.w3.org/2014/10/31-webdriver-minutes.html#action05]

mdas: Pointer Actions
... How we describe starting an action
... Different set of instructions
... Is it dependent on the input source, or should they apply across surces?

AutomatedTester: Keep this undefined
... If Microsoft decides that the events sequence is going to follow that of pointer events, our description would point at something else which would describe the sequence.

mdas: We need to make sure this works for touch events as well.

AutomatedTester: The event sequence for your finger on a Windows Phone is going to be significantly that of an Android or iOS device.

mdas: I just want to clarify what a pointer down and a pointer move are.
... Is that the start of their action?
... I don't want to go into the implementation.
... How should the user start a pointer event?

MarcFisher: There's no previously defined location.
... mouse down pushes down whereever your cursor is right then and there.

mdas: Dependent on the input source?

ato: What's the alternative?

MarcFisher: Virtual finger position?

wilhelm: Is that weird?

MarcFisher: Yes.

Automate_: If you're moving your finger from point A to B, should we fire a hover event on the way there?

MarcFisher: Allows you to have a single API.

jimevans: It seems to me, maybe this is stretching the point a bit, but it seems we have two types of pointer input sources.
... Style, finger, mouse
... Two categories: Position of the pointer is persistent, and one where the position of the pointer i snot persistent.
... When you release you don't have a cursor anymore.
... Although that blurs a bit more when you have things like the Surface touch screen.

AutomatedTester: Same thing can be said for other things.

MarcFisher: I have a touch screen on Chrome OS.

jimevans: In my mind maybe we can draw the line between pointer input sources.

mdas: Let's say that you wanted to push down at A and move over to B; should the events be atomic or different?

jimevans: Different I think makes sense.
... You have to tell the action what type.

MarcFisher: We should have distinct command names.

wilhelm: I'm writing a web app for Surface, and I want to run the exact same TC with a finger and a mouse.
... Would that work?
... [tc]

jimevans: On Windows Desktop, which is what Surface runs, it acts as another type of mouse class action.
... You happen to let it go on an element that would hover that element.

mdas: What would the different API's look like?
... Pointer down: If your input source is a touch device

MarcFisher: I'm not a big fan of reusing names for different things.
... Given action name should be unique/fixed

mdas: It could be any type of input source.
... Mostly consensus.

jimevans: The diagrams are particularly instructive.

mdas: Good.

jimevans: In particular they help to illustrate they pause actions.

mdas: That's very difficult to explain in words.

jimevans: That's has been a point of contention in the past, and this illustrates it very, very clearly.

mdas: I think that ends this point.

sam_u: I don't know if we're going to do the stylus thing or not.

wilhelm: How is this handled on the Galaxy Note device?

sam_u: Not the same as the Surface.
... Doesn't have pressure.
... More like touch.

MarcFisher: If chromedriver never supports the stylus device type, then it doesn't matter if it's in the spec or not.

AutomatedTester: Then what happens if you ask for it?

simonstewart: You get an error code.

jimevans: Yes, we should define this.

simonstewart: Unexpected parameter.

<scribe> ACTION: mdas to define unsupported input sources should throw unexpected parameter status. [recorded in http://www.w3.org/2014/10/31-webdriver-minutes.html#action06]

<scribe> ACTION: mdas to return list of input sources in session capabilities. [recorded in http://www.w3.org/2014/10/31-webdriver-minutes.html#action07]

<scribe> ACTION: MarcFisher to specify that interpretation of required capabilities depends on the capability itself; whether it's met or not. Language for that each one is special cased. What it means to fulfil a capability is defined by that capability itself. [recorded in http://www.w3.org/2014/10/31-webdriver-minutes.html#action08]

<scribe> ACTION: mdas define input devices capabilities. [recorded in http://www.w3.org/2014/10/31-webdriver-minutes.html#action09]

wilhelm: Two questions.
... The spec currently says MUST support keyboard, mouse, touch.

mdas: Why does it say that?

simonstewart: Probably just loosen that language.

mdas: Do we even want to even to define that?

No.

<scribe> ACTION: mdas to remove prose on required input sources. Should not mandate anything. [recorded in http://www.w3.org/2014/10/31-webdriver-minutes.html#action10]

wilhelm: What will happen then if you try to type on a watch that has no keyboard?

mdas: We already have an action on defining an error for that.

wilhelm: I guess voice can be glorified keyboard.

MarcFisher: Yeah.
... Or unsupported operation.

wilhelm: Do we have an extension point for sending more information with the action?

mdas: Yes
... That would depend on your input source.

wilhelm: Where do I add the additional values?

mdas: There's a JSON blob.

wilhelm: There's an extension point right here.

<scribe> ACTION: mdas clarify how to add more parameters to each action. [recorded in http://www.w3.org/2014/10/31-webdriver-minutes.html#action11]

sam_u: With the ID's, it looks like you give a separate ID with every pointer source.
... This all depends on the local end.

mdas: Yeah, the local end can make it up.

sam_u: Does it get destroyed? Can it be reused?

MarcFisher: Yes, you can leave a finger on the screen for example.

mdas: You can reuse it if you want.
... The identifiers are for active input sources.

sam_u: Okay.
... Is there any limit on how many touches?

mdas: No.

sam_u: With persistent devices, can you have a tick with two different ID's, we don't have any obligation to maintain two mice?

No

<scribe> ACTION: mdas to specify if there are multiple mouse sources, the first mouse input source will be used. [recorded in http://www.w3.org/2014/10/31-webdriver-minutes.html#action12]

<mdas> resolution: ids start from 0 for each input source

Resolve action 12

Drop action 12

<scribe> ACTION: mdas to ignore action 12 [recorded in http://www.w3.org/2014/10/31-webdriver-minutes.html#action13]

<mdas> RRSAgent: drop action 13

wat

<simonstewart> scribe: simonstewart

Open Bugs

<wilhelm> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26743

wilhelm: clarify behaviour for typing in non-interactabke elements

juangj: requirement for keybased interaction is that the element is interactable
... there are tests that send inputs to non-interactable elements. Chrome driver blows up, firefox driver types into the element, and IE driver sends to the BODY element

ato: that seems wrong
... this is WebElement.sendKeys, right?

everyone nods

ato: we should be returning an error message

MarcFisher: sounds like chrome driver is doing the right thing

AutomatedTester: what if you have a canvas element and you send a space bar? Should that error? What if you're playing a game

?

ato: it's a "do what I want" thing, for well recognized inputs.

simonstewart: What's to stop you using advanced interactions in the canvas case?

MarcFisher: if the element is focusable you can send keys to it, right?

ato reads from spec

AutomatedTester: the actions api allows you to not send through the element
... I'd expect findElement(body).sendKeys(" ") to scroll

ato: I think I'd agree

jgraham: isn't focus defined now?

ato: it might be. We didn't decide whether or not "interactable" should go away, and whether ut's the same thing as focusable

ato outlines case where a div covers an input element

ato: it's focusable but not displayed

jgraham: it sounds to me that all you need to do is look at the definition of HTML5 and if an element has focus you can send keys to it
... there might be a special case for the root element?

ato: what about disabled elements?

seva: for space it'll scroll. For other keys something else will happen

jgraham proves point by reading html5 spec

MarcFisher agrees, adding caveat that you can always send keys to BODY

jgraham: something about anchor elements. I suspect that this means that the document object has focus when you hit the space bar

<wilhelm> https://html.spec.whatwg.org/#focus

ato: if you have a disabled input field and send focus to it and type, the document element gets the input

MarcFisher: if other people have definitions, let's use them
... what do we want to be the equivalent of sending keys with nothing focused

debate about how selenium does sendKeys and advanced user intactions.

<ato> data:text/html;charset=utf-8,<script>%0D%0Awindow.onkeyup %3D function(ev) { console.log(ev) }%0D%0A<%2Fscript>%0D%0A%0D%0A<input disabled>

MarcFisher and simonstewart have a discussion about whether we need an API for just sending keyboard input to the document node

simonstewart: what's the use case?

MarcFisher: scrolling using the spacebar

wilhelm: tab index testing

ato: how do you know which part of the document to click?

mdas: why not just send an escape key?

MarcFisher: that doesn't work

ato: that's UA specific

jgraham: I have been speaking to hixie. The viewport can be focused, and the DOM anchor for that is the document IIRC

wilhelm: so html.focus(): is that the viewport?

jgraham: yeah, I think so

ato: but that's the DOM definition

jgraham: the focus can be in some other part of the UA. There isn't a direct mapping between what webdriver considers focusable and the OS
... It seems difficult to test the case where you hit spacebar and the page scrolls. What about the case where space switches tab

ato: document.focus()

jgraham: document.documentElement.focus() would probably work

ato: it would bubble the event up to the document since it might not be focusable

If your document element is in focus and you send a key, the document gets the keyup

ato: or window, I suppose

jgraham: you could make the root element focusable (eg: content editable)

MarcFisher: the focused element is the BODY

simonstewart: so findElement(body).sendKeys(" ") would do what you want?

MarcFisher: yes

jgraham reads the spec. Laughter

ato reasons about why the spec is written the way it is.

MarcFisher: all we need to do is say that the BODY is interactable
... If you set body.display = 'none', it still remains the active element

<wilhelm> data:text/html,<!DOCTYPE html><style>html {background: blue;} body {background: orange; display: none;}

jgraham: it sounds like HTML specifies this for you

ato: can you summarize?

jgraham: not sure I can, but it defines elements that can have focus, and those are the ones that can have key input
... we've not even thought of the dialog element. It's a special layout thing that doesn't allow focus to go outside of it
... sounds like hixie has already done the work, and we shouldn't do the same

slight digression as browser vendors find out what their browsers do when you remove the document root element

<scribe> ACTION: ato redefine what is an interactable element and basically say webelement.sendkeys() should return an error when the element isn't focusable [recorded in http://www.w3.org/2014/10/31-webdriver-minutes.html#action14]

MarcFisher: wasn't interactable also for clicks?

nodding

MarcFisher: it's possible we need "typeable" and "clickable"

juangj: "pointerable"

MarcFisher: it may be easiest to say "is focusable or is the BODY"

ato: shall we move on?

*sighs*

wilhelm: we're going through the bugs that people have raised and that they want to talk about
... anyone?
... last discussion item is when we meet, then it's lunch

juangj: should we remove xpath

ato: blackberry asked us very nicely not to do that

MarcFisher: next f2f?

AutomatedTester: let's put it to the mailing list

:action wilhelm ask mailing list for date and place for next f2f

<scribe> ACTION: wilhelm ask mailing list for date and place for next f2f [recorded in http://www.w3.org/2014/10/31-webdriver-minutes.html#action15]

oh deary me

wilhelm: that's all we had on the agenda

ato: but one other thing: proxying?

<ato> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26391

simonstewart: do we mean proxying as in HTTP or setting in the capabilities

AutomatedTester: if it's setting via capabilities, it needs to be in L1. And it's blocking L1 already

ato: ok

wilhelm: ok

simonstewart: ok

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/dammit//
FAILED: s/dammit/whoops/
Succeeded: s/dammit//
Succeeded: s/yo uhave/you have/
Succeeded: s/form/from/
Succeeded: s/jscript/JavaScript/
Succeeded: s/simonstart/simonstewart/
Succeeded: s/determinses/determines/
Succeeded: s/arguments/attributes/
Succeeded: s|s//whoops||
Succeeded: s/:whobrokeit//
Succeeded: s|S/CR/CI/||
Succeeded: s/CR/CI/
Succeeded: s/Break until :40/[ Break until :40 ]/
Succeeded: s/base/bar/
Succeeded: s/damnit/oh deary me/
Found Scribe: ato
Inferring ScribeNick: ato
Found Scribe: JohnJansen
Inferring ScribeNick: JohnJansen
Found Scribe: ato
Inferring ScribeNick: ato
Found Scribe: simonstewart
Inferring ScribeNick: simonstewart
Scribes: ato, JohnJansen, simonstewart
ScribeNicks: ato, JohnJansen, simonstewart
Present: seva wilhelm JohnJansen mdas jimevans SimonStewart jgraham LukeInmanSemerau DavidBurns juangj SamUong ato MarcFisher
Got date from IRC log name: 31 Oct 2014
Guessing minutes URL: http://www.w3.org/2014/10/31-webdriver-minutes.html

WARNING: No person found for ACTION item: on mikesmith investigate requirements for automation of existing manual tests [recorded in http://www.w3.org/2014/10/31-webdriver-minutes.html#action01]

People with action items: an ato clarify current diff do figure how includes land marcfisher mdas of out reference simonstewart that thing update want we what which wilhelm