See also: IRC log
<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
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
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
<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
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
<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[End of scribe.perl diagnostic output]