<jgraham> Good morning, wilhelm

<MikeSmith> wilhelm_: good morningーI'm around on IRC if/when needed

<jgraham> RSSAgent, make minutes

<wilhelm> Agenda: https://www.w3.org/wiki/WebDriver/2015-TPAC-F2F

<AutomatedTester> scribe: AutomatedTester

<jgraham> RSSAgent, draft minutes

<JohnJansen> https://www.w3.org/wiki/WebDriver/2015-TPAC-F2F

<wilhelm> Scribe: wilhelm

State of the union

AutomatedTester: The main things changed in the spec since the last meeting is that we have proper, prescriptive langauge in the spec now.
... It's a lot better.
... The general gist has not changed, just the format, so that you can actually implement things.
... ato has done a big chunk of the work.
... I believe our charter ends at the end of this year. We need a final push to finish the last little bits done.
... So we can move forward to REC.
... THat should be the main part of our discussion today and tomorrow.

JohnJansen: THe test suite is an important point to get to REC.

ato: We can also start the REC process before the test suite is finished.

AutomatedTester: We have three diverging implementations, and need the test suite to rein things back in.
... We can move things about on the agenda.

Agenda review

sam: I put the Bluetooth in the agenda. Interest from platform implementors.
... Jeff from GOogle is chairing the Bluetooth work.
... I don't know if this is for the first level of the spec.

simonstewart: We have places in the spec for extensions.

sam: They need a test suite for this. COuld be an extension.

ato: One of the things we want to achieve is to allow other platform techs to make their specs testable.
... We talked about mobile related things, punting most of them until we have the core spec finished.
... Re: bluetooth, USB, someone should come up with a strawman proposal.

jgraham: It would be good if they come here.

sam: Jeff can come in tomorrow.
... This could start as a vendor-specific feature.

<simonstewart> https://w3c.github.io/webdriver/webdriver-spec.html#protocol-extensions

AutomatedTester: There is an example in your code for launching web apps.

ato: We decided to punt other things: Shadow DOM, logging.

jgraham: FOr the agenda for tomorrow: What future work is there for this group? W3C process, charter.

ato: I added an agenda item: window focus. DOM events queued.

JohnJansen: Accessibilty testing with WebDriver.
... Accessibility WG is meeting nearby.

simonstewart: Every year we have a discussion about this. There is overlap.

AutomatedTester: We have invited them over previously.

ato: I think it makes sense to talk about the level 2 stuff to avoid conflict with level 1.

JohnJansen: Should there be a v2 spec draft?

jgraham: I'm very dubious about that.

AutomatedTester: There is a top-level bug you can raise bugs against.

ato: We also haven't talked about how to do extensions to the spec later. One spec, or multiple? Per feature?

<AutomatedTester> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24121 is the L2 Bug

simonstewart: We should talk about concrete steps to get to LC.

(Discussion about specific screenshot issue, wrt. scrolling.)

JohnJansen: Our screenshot implementation was based off Chrome, many complaints.
... We talked about an optional parameter.

AutomatedTester: There's also screenshot of element. Should we scroll to the element?

<ato> https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=20860&hide_resolved=1

Open issues

AutomatedTester: Should we skip issues on click, etc.?

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

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

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

simonstewart: Do as I say: Don't wait. Fire away the event.
... Do as I mean is tricker: Clicking something, expecting page load. At that point you should use page loading strategy when to determine when to return to the user.
... Super-racy condition.
... Because page load hasn't started.

jgraham: This is not super easy.

simonstewart: It is.

jgraham: With a short gap, you can still lose.

ato: Why can't we do something like: add mutation observer, listens to the document..

simonstewart: Onbubble may be cancelled. WHere would you put it?

jgraham: It seems very unsatisfactory to wait an arbitrary amount of time.
... Leverage that the person using the API probably knows what to expect.

simonstewart: Test authors often don't understand implicit waits.
... (Describing how this has been solved in different implementations.)

jgraham: Wait for the event loop to be processed.
... Event handler for that click event?
... Let one cycle of the event loop run or wait for the click handler to run.

ato: Sounds like a good solution.

jgraham: (Comments on the bug.)

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

ato: (Reads the bug description.)

<juangj> Scribe: juangj

(some discussion happened while wifi was dead)

simonstewart: should click in the middle of the first visible client rect

johnjansen: center of client rect may be obscured

<ato> .

<ato> https://irccloud.mozilla.com/file/HblZkA5l/wilhelms.png

samuong: there’s a special case [in chromedriver] for <area> tags, and for circles etc. we try to figure out the center
... i think this is a special case because of the way chrome gives you the clientrects for these elements?

not quite sure how firefox does it

ato: do you have a test case for this?

samuong: i’ll make one

<scribe> ACTION: samuong make a test case for <area> element clicking [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action01]

<JohnJansen> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22653 - resolved already

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

simonstewart: (explains original reasoning for this)

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

simonstewart: i’m happy to not do it that way

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

automatedtester: yes, should probably special case this. it comes up regularly in #selenium IRC

ato: we’ve already reached a conclusion on this (comment 1) and it just hasn’t made it into the spec yet

johnjansen: my hesitation with comment 1 is that we don’t want to dictate that the browser replace the set file, we should just let the browser do what it does

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

(discussion about whether this text even still exists in the spec — it doesn’t)

the original motivation was that some browsers couldn’t do HTTPS

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

ato: (reading the current text on alerts in the spec)

simonstewart: so you’re saying that the “are you sure you want to navigate away” prompt gets implicitly dismissed?

ato: you can get an ‘unexpected alert’

jgraham: as far as i can tell, this text doesn’t actually specify anything
... there are two cases. case where you do an explicit ‘get’, and the case where you do something else that causes navigation to happen

simonstewart: should handle the same way; if the dialog pops up, should be handled the same way by the prompt handler

ato: all of the commands that are meant to handle or deal with alerts in some way have an explicit step to ‘handle any user prompts’ that checks the prompt handler

jgraham: then i dont understand the sentence that says the prompts are dismissed implicitly on navigation
... what you’re saying you want [about no special casing of this alert] and what the spec says are different
... it seems to me that ‘get’, specifically, has to have a step to check for this; if there’s an unload prompt at the moment, get will never return

ato: problem here is we’re trying to specify a blocking api but some of the things here happen asynchronously

jgraham: not every endpoint can cause an alert. just navigation, executescript, …

simonstewart: you could imagine some bastard doing some sort of setTimeout thing to cause an alert when getting cookies

jgraham: it’s specified that you have direct access to cookies

ato: does that mean we need to add a list of the commands [that can cause alerts]?

jgraham: interactions, get, executescript, … back/forwards … ok this is a bit of a nightmare

ato: the html5 on this topic is interesting. ‘alerts’ and ‘user prompts’ are not synonymous
... this also handles the old IE thing, showModalDialog

JohnJansen: edge has this new thing too, about whether you want to switch apps

jgraham: so the conclusion here is that there’s more work needed

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

ato: tempted to just resolve this bug because we haven’t really started working on it
... not sure why he wants to remove this

AutomatedTester: i think what marc was saying is that it doesn’t need to be there because the low-level tap stuff would have it

samuong: can’t find the word “alias” in the spec; it looks like that part of the bug is no longer true

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

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

ato: “The remote end must include a configuration option to limit the accepted IP range allowed to connect and make requests” is in the appendix

jgraham: surely we didn’t mean to put a requirement in the appendix

simonstewart: do we need this section? [appendix C on “security”]

jgraham: i’m very unhappy about this saying there “must be a configuration option"
... would like a word that means “should” but isn’t “SHOULD”
... want to rewrite this to be non-normative, purely informative text

JohnJansen: purpose for limiting it is that it’s dangerous to leave it open. if you don’t limit access, you’re maybe an idiot, but it doesn’t have to be a requirement

simonstewart: didn’t this section used to say something about fingerprinting?

(yes, it’s in sec. 3 now; “webdriver-active flag”)

refreshment break

back at :45

RRSAgent: draft minutes

sam: returning to that <area> thing, it looks like that’s a chrome-specific thing that other browser don’t need to worry about

<sam> scribe: sam

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

simon: this is used by people who want to set timeouts back to an original value

james: we should have a getter for every setter; write-only is not good

andreas: useful for marionette users when using a context manager, and restoring to the original state
... some users also have multiple local ends controlling a single browser session

simon: i understand the symmetry arguent (getters for all setters), but no one has ever asked for this

david: it's a frequent request

johnjansen: we resolved this last time, and decided to handle it in level 2

simon: we can add it in level 1

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25058

simon: we should better define spaces, and include unicode spaces

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

<ato> Resolution: We’ll resolve it as a duplicate.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25285

simon: booleans need to be handled properly, there are lots of tests out there that require it

james: attributes need to be returned as a list, so this is going to make it difficult to separate null/false

simon: browser vendors could be responsible for keeping their drivers up-to-date

james: even for browser vendors, it's difficult to keep track of what is implemented and what isn't
... it'll be confusing when attributes are set to the empty string, or something else that's falsy

simon: we can think about renaming this later, but if you want the html attribute call the javascript, otherwise the existing way works ok

simon and james agree that remote ends should keep track of which attributes are boolean

david: with web components we don't have element attributes and idl attributes in sync

andreas: e.g. a custom input element could have its own disabled attribute

james: we don't have a list of boolean attributes for custom elements

simon: it's worse to break existing tests, so we should maintain the existing behavior

andreas: we could fix this by calling get property, then get attribute

simon: this would be grossly inefficient for use cases like sauce labs'

<ato> sam: I’m Andreas by the way.

resolution: leave it the way it is

<juangj> Scribe: juangj

<scribe> scribe: sam

<scribe> ACTION: add note to explain why we're returning a string "true" in section 12.3 [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action02]

<ato> ^ ato

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

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

resolution: punt this to level 2

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

<ato> https://bugzilla.mozilla.org/show_bug.cgi?id=883555

james: bug title differs from link in bug
... if a string has bidi text, webdriver shouldn't modify that

resolution: bug is invalid, we shouldn't strip these out

<ato> https://bugzilla.mozilla.org/show_bug.cgi?id=883555

<ato> http://www.w3.org/TR/findtext/

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

resolution: someone needs to define "effective css whitespace"

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

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

simon: we should return what's in the dom, and talk to the css people about an api to get the result of the text transform

resolution: close the bug and have a note

<jgraham> https://w3c.github.io/webdriver/webdriver-spec.html#dfn-json-clone

<jgraham> http://rocallahan.github.io/innerText-spec/index.html

^ this doc says that innerText will handle text transforms

james: this might require firefox nightly

simon: ideally we would return what the user sees when getting the visible text, but currently there is no good way to do this
... we can implement this when a better method is available

wilhelm: firefox, chrome, edge implement innerText differently in terms of text transforms

<AutomatedTester> https://drafts.csswg.org/css-text/#text-transform-property

simon: we shouldn't be breaking existing tests by changing this

james: someone should go through the spec for innerText and webdriver and finding out what makes a difference here

johnjansen: this is something that css/html should be doing

<wilhelm> Test case for copy and paste: https://jsbin.com/sigoxopamo/edit?html,output

<scribe> ACTION: run the selenium test suite using roc's innerText and see how many fail [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action03]

<ato> http://rocallahan.github.io/innerText-spec/index.html

<JohnJansen> reminder: http://rocallahan.github.io/innerText-spec/index.html

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

<ato> This is what the spec says about extension commands: https://w3c.github.io/webdriver/webdriver-spec.html#protocol-extensions

webdriver doesnt' have the same problems as css vendor prefixes, so this might not apply

resolution: this doesn't need to change

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25678

jason: this is gone from the spec now, and there's new text about focus not being relevant

<simonstewart> http://www.w3.org/TR/html5/editing.html#focus

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

resolution: close 25678

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

26031 is a dupe

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

james: i've fixed this, will close

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26266

james: this is out of scope, move to level 2

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26287

use case is doing a file transfer when local and remote ends are on separate hosts

simon: the remote driver already does something like this

resolution: document this in the spec

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

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27244

this isn't really doable, e.g. for the back command shortcut

in chrome on mac, it's cmd+leftarrow, on linux/windows it's alt+leftarrow

resolution: wontfix

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

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

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

this hasn't been rewritten yet, so we'll discuss once this section has been rewritten

<JohnJansen> returned from Lunch

<juangj> resolution: the coffee here is bad

<juangj> scribe: juangj

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27665

resolution: 27665 is out of scope; you should ask for the input devices you want in desired caps

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28002

simonstewart: what you should do, is if you can’t start another session, just don’t start a session and return an error

jgraham: there’s an implementation-dependent maximum, which for most endpoint nodes is 1

simonstewart: why is this relevant?

ato: suppose marionette has a session going already and you want to start a new one, there needs to be some way to say you can’t do that

simonstewart: there’s already a “session not created” error

ato: that’s not implementable. you’re saying just to return that error if anything bad happens

jgraham: specifying this behavior makes the spec more explicit

ato: this is not irrelevant; it’s a concrete use case that we had to implement for marionette

simonstewart: what about browsers that support multiple users

jgraham: it doesn’t make sense to have two simultaneous sessions because of the amount of global state in a browser

simonstewart: not going to argue but it’s pointless language

(resolved fixed)

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28143

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

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

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28195

some browsers behave differently if you give a valid selector and nothing is matched, vs. if you give a malformed selector

simonstewart: said that thing ^

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28407

ato: yes, it’s possible to have an interactable element that is obscured by another element

jgraham: it’s still possible to focus an element if you can’t click on it

simonstewart: keyboard actions still make sense, mouse not so much

jgraham: this is still a question about visibility so let’s skip it now

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28746

jgraham: what the spec is trying to say is, “do what you think is right”, but you can’t really specify this in detail
... resize the window and try to make it this size

simonstewart: usually you want to view the webpage with a certain size viewport

jgraham: including the chrome is what webdriver has historically done
... the definition in the spec is supposed to be the same as what outerWidth and outerHeight are, except we avoid referring to those because they’re not actually standard

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28754

JohnJansen: the text here is just missing an “else”

ato: i think i fixed this already with a PR

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28756

jgraham: this is about findElement so it’s probably still valid as we’ve yet to rewrite that section

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28760

JohnJansen: the param would be optional and default to ‘click'

sam_: even on a mobile phone?

should be browser-dependent?

JohnJansen: browser doesn’t know if it’s on a touch device

AutomatedTester: what marionette does is: if you’re on desktop and you ask for a tap, it’ll do the click anyway because it does know from when you started the browser that tapping isn’t valid
... not sure what chrome does

JohnJansen: on a laptop like [his], you can use keyboard and touch pretty interchangeably

sam_: mac chrome is probably the only one where touch doesn’t work in a desktop environment
... chrome will generally try to do a tap

jgraham: that makes sense — if you explicitly ask for a tap, the browser should try to do a tap

simonstewart: general agreement with john/the bug)
... and if you ask for a ‘click(“touch”)’ and that’s not supported, do what i mean

resolution: don’t spec “tap()”. spec click with an optional input source, e.g., “click(‘touch’)”, and if omitted, use the platform default

AutomatedTester: where does the platform default come from? that needs to be specified somewhere

simonstewart: no, the browser determines that. chrome on android defaults to touch, chrome on mac defaults to click, who knows what john’s crazy hybrid does

<JohnJansen> I know. Ask me. It's awesome.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28802

simonstewart: acknowledged. punt it.
... nobody implements it right now… well, firefox does because salesforce added it…?

(bug moved to level 2)

<ato> JohnJansen: https://w3c.github.io/webdriver/webdriver-spec.html#dfn-scrolled-into-view

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28968

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

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29054

all: ….. yep

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29070

all: ok, but why is this even called “sendKeys” instead of “keys”

sam_: isn’t it called “value” in the open source protocol?

(yes, it is)

simonstewart: the reason the API is named “Send Keys" is because you’re emulating keyboard input
... ...and also because that was the name of the win32 api

all-lowercase is fine

simonstewart: the other option is to specify that URLs are case-insensitive

jgraham: noooo

ato: ALL CAPS! “SEND KEYS! DO WHAT I MEAN!”

jgraham: this isn’t actually inconsistent with the rest of the spec; this is the only camelCase endpoint but it’s also the only multi-word name
... “screenshot” and “fullscreen” are one word

resolution: just leave “sendKeys” as camelCase, because that’s easier

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

JohnJansen: this might be because of a security issue, where you don’t want to divulge the actual reason for the error

simonstewart: could be “unsupported operation”

JohnJansen: not sure that you always can know for sure that it’s an ssl error

jgraham: surely the browser knows

ato: isn’t “unknown error” really unhelpful to users?

jgraham: should probably coin a new error code for this

JohnJansen: not positive that browser knows for sure — it can know that it can’t authenticate but it might not know the exact reason

jgraham: it must know because it can pop up a dialog explaining what happened
... we wouldn’t require that you explain all the details, just that you say that it was a … er … ssl error for some unknown reason

simonstewart: defining an error code for every possible browser-specific error screen isn’t a good path forward

ato: also that’s not standardized
... opera would have a situation where you can’t even inspect the state of the browser at all so you can’t return the text of the error page

jgraham: but you should still try to return an informative error message

ato: should we have some text about the general purpose of “unknown error”
... a page like firefox’s about:config has this special non-html, xul error page

jgraham: how do we specify behavior when you get into a state where you can’t do some stuff (like executescript on about:config)

simonstewart: yeah, “unsupported operation” seems appropriate

<scribe> ACTION: each command should have a condition to check that the content can be operated on [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action04]

ato: we could remove “unknown error”

simonstewart: it’s still useful — it could be “i ran out of memory”

<scribe> ACTION: add normative text somewhere explaining that “unknown error” MAY be returned when something or other happens that is unknown [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action05]

FAKEACTION: insert rumsfeld joke

<scribe> ACTION: JohnJansen to find out whether Edge can detect the SSL cert error; if it can’t, then we should not add a new error code for ssl certs (as in bug 29168) [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action06]

<ato> JohnJansen: https://revoked.grc.com/

ACTION- 6

ato: there still isn’t enough tea around here

juangj: there is tea in the vending machine

ato: [condescendingly shakes head]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29202

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29204

last two bugs are uncontroversial

that’s all the bugs

refreshment break, in which several people will go in desperate search of actual coffee

returning at :45

<simonstewart> scribe simonstewart

<simonstewart> We're about to talk about window focus

not sure if you need a colon

<scribe> Scribe: simonstewart

Well, I'm scribing now

ato: so "window focus" is in the open issues
... had been talking to a content developer at mozilla. Marionette wasn't firing certain events when a window wasn't in focus
... was trying to click on an input field, and the event only fired when he brought the window into focus
... there's the ability to put the focus manager into a testing mode
... if you want to test this as a platform vendor, then you're in trouble.

simonstewart: talked about utilization of machines using multiple simultaneous browsers

jgraham: should this be a capability?

ato: not sure. Marionette does this as a preference

http://www.w3.org/TR/html5/editing.html#focus

ato: other things in the browser needing focus, such as the permissions dialog. Also effected in marionette by the testing focus thing

AutomatedTester: discussion of how chrome attempts to save battery by slowing event loops

ato: quotes mozilla employee.

AutomatedTester: should this be a capability to allow people to turn focus mode on and off

ato: does wtp support different configs per browser?

jgraham: yes

ato: we want the default in the webdriver spec to support users

so fire events as they are sent by the local end

AutomatedTester: also sounds like a profile-specific thing

test suites

Discussion on the current state of the test suite

JohnJansen: best to leave the test suite where it is currently
... sub-folders per section seems to make sense
... tl;dr; the structure seems sane
... however there are tests that are either not testing things in the spec, aren't testing what they thing they're testing, and some that are doing the Right Thing
... how do we get the PRs into the web platform tests. Original PR was to make sure that the tests could run
... right now the test suite isn't good for people who want to implement new webdriver implementations

jgraham: if there is public code review, then the tests can be merged straight into web platform tests
... in principle you could have a weaker policy, but it would be unusual

ato: agrees with JohnJansen
... will be working on the test suite this quarter.
... one reason we've not done the PR reviews is that there was an opinion that the test suite was so out of date, it wasn't clear whether we should should start from scratch or not
... we need some low level primitives to trigger some conditions that are mentioned from the spec

Mozilla give MS a big hug

JohnJansen: has a doc that explains each of the changes in the PRs
... should we add tests for things that are not in the spec?

ato: it's easy to loose track of what's not in the spec or not

AutomatedTester: organize the untracked folder in the same way as the main test suite, so it's easy to find and move tests as required

ato: is anyone opposed to just merging the tests straight into the tree?
... also, some of the tests are about 10 KLOC

Agreement appears to be to merge the changes in

JohnJansen: is there some way we should flag a test to indicate that it was reviewed within MS?

jgraham: normally you link to the public review.

JohnJansen: we can make the PRs public.

<jgraham> http://www.w3.org/2015/Process-20150901/#transition-reqs

<scribe> ACTION: merge MS PRs (possibly ato) [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action07]

Getting to CR and REC

ato: the goal is to get the primitives that other specs need nailed down and frozen

plh: don't try to be perfect, and keep the cost of producing the rec as low as possible

You can mark features as being "at risk" in the spec. Once they're ready, someone can remove the mark and republish the spec

JohnJansen: the features we have at risk are currently living as bugs

plh: the current version of the spec is going to be your v 1.0?

AutomatedTester: yes, though there are minor areas to work on

ato: major areas :) We're about 80% there

plh: current thinking is to move to CR until you're ready to move to spec

ato: we have a number of different implementations already. Plan is to work on the test suite.

plh: the process doesn't require a test suite. Just need to ensure interoperability
... if you have other ways to demonstrate interop, that's fine.
... be aware that in a year's time you'll probably need to revise things as corner-cases show up

ato: there's no difference between editors' and working drafts.

plh: once you're in CR you need a director's agreement to republish
... so stay as a WD until you're ready to go to REC, then pass through CR as quickly as possible
... that also means there's a minimal window where there are two versions of the spec at the same time (CR and WD)
... think about your versioning.
... /tr/webdriver should always point to the most recent version of the spec.

<JohnJansen> eg: http://www.w3.org/TR/webdriver/

<JohnJansen> is the latest and greatest, but http://www.w3.org/TR/webdriver/1 is the "rec" version

plh: in order to get to CR you need to also have wide review

AutomatedTester: group charter runs out at the end of the year. Do we need to recharter? What's the process to move forward.

plh: you can ask for another extension
... or you can ask for a new charter

AutomatedTester and ato: probably the latter

plh: then get an extension to allow you to finish the spec, then recharter
... put the draft of the charter on GitHub and iterate on it there. It makes it easy to get feedback
... if you're close to finishing, can we use this for web platfrom tests?

jgraham: yes, but it requires engineering
... explains about writing tests in JS on a page and having that call into a webdriver remote end point and then get results back
... the problem is finding the time and contributions to getting that implemented

sam: we started doing something similar for chrome layout tests

ato: might be easier to just write a new binding entirely

<ato> Draft proposal for WebDriver integration with WPT: https://wiki.mozilla.org/Auto-tools/New_Contributor/Quarter_of_Contribution/Web_Driver_Infrastructure

<lukeis> saw a bit about spec tests… would appreciate a recap on what's decided about that… I have a (very old) PR still waiting review: https://github.com/w3c/web-platform-tests/pull/1350 and I just noticed john's (and commented on the review) https://github.com/w3c/web-platform-tests/pull/1890

<jimevans> i think that discussion is going to happen tonight/tomorrow.

<jimevans> or the in-depth part of it will, anyway

<lukeis> it was a topic of discussion yesterday at least :)

<lukeis> look forward to hearing about it then!

<jimevans> oh, nvm. i see the agenda got rearranged. test suite discussion was yesterday. a full recap would be appreciated.

<lukeis> current open PRs :) https://github.com/w3c/web-platform-tests/labels/webdriver

<AutomatedTester> jimevans: lukeis we decided that we are going to merge all PRs and from there sort them

<lukeis> :-/

<lukeis> except John's changes the driver from the internal one to the open source one!

<AutomatedTester> we will eventually throw that out

<lukeis> and move to another repo? or just rework the whole thing

<AutomatedTester> just rework the whole thing

<AutomatedTester> a) get tests running

<lukeis> anyone tasked with that?

<AutomatedTester> b) get the right tests running

<AutomatedTester> I have made it a deliverable for ato this quarter to spend time on the spec test suite

<lukeis> should we just work on a fork somewhere else for now and then merge into that w3c repo later…

<AutomatedTester> so he will be doing this part of his Mozilla work

<AutomatedTester> we don't know all the ins and outs of landing the code

<AutomatedTester> WPT has a rule that as long as the review is public it can be landed in the WPT repo

<AutomatedTester> so he *may* do it in the Mozilla tree and we can upstream

<AutomatedTester> logistics are still to be worked out

<lukeis> 'he'?

<AutomatedTester> John has a plan for how MS could make their tests open too

<AutomatedTester> ato

<lukeis> ok

<AutomatedTester> John also has a tool that could allow us to annotate the spec to see which tests match where which looks great

<AutomatedTester> they will hopefully open that later

<AutomatedTester> "still in development"

<lukeis> i think we need to make some of the guidelines crystal clear on the tests… like, does each test require it's own html document? (or like others seemed to assume, the test class can use one html document, if it fits for multiple tests)

<AutomatedTester> we didnt discuss that today

<AutomatedTester> (it was a long day and we were very tired at the end)

<lukeis> discuss all the things!

<lukeis> ;)

<lukeis> also… why are you awake? :)

<AutomatedTester> I have had 4 hours sleep, wanted to see if my manager was about to give him an update about something not w3c related

<AutomatedTester> will try sleep again in a bit

<lukeis> heh, just saw simon tweet too

<jimevans> lukeis: are you going to be on IRC tonight for the sessions?

<lukeis> doubtful

<jimevans> hrm.

<jimevans> well, i'll leave y'all to carry on then. i doubt i'll make it on either, after the events of this morning (local time)

<AutomatedTester> please remember that there is also the mailing list and if you want clarifications I suggest emailing them today before we start again

<AutomatedTester> so we can do that first

<AutomatedTester> jimevans: is your subtweet about sendKeys?

<jimevans> caught that, did you? i'm not *that* upset about it, it just looks ugly to me. i understand the reasoning behind not changing it.

<jimevans> :)

<AutomatedTester> its literally the only 2 word item in the list

<jimevans> i mean, out of, what, forty-odd end points, its the only one with an upper-case letter in it?

<jimevans> so we change it to just "keys" or something. but really, it's just me nitpicking.

<jimevans> still think it looks awful.

<jimevans> still, the tribe has spoken. so i don't have any room to stand, do i?

<jimevans> besides, i'll gladly compromise on that in return for the status end point. :)

<jimevans> (thanks for that, by the way)

<jimevans> and now, i really *am* going. i need to see to my family.

<wilhelm_> Mmm, jetlag.

<ato> You could look at it in two ways. Either consistency in that every endpoint should be lower-case, or that endpoints that have two words should have capitalisation to distinguish the words and sendKeys is the only two-word endpoint in the whole spec.

<ato> I have no strong feelings either way, but Simon is correct that all implementations would have to change to sendKeys to sendkeys, which is more work than just doing nothing.

<lukeis> and i'll leave you guys with a selbot to do your bidding ;)

<lukeis> have a good meeting!

<wilhelm_> https://www.w3.org/wiki/WebDriver/2015-TPAC-F2F

<wilhelm_> https://www.w3.org/wiki/WebDriver/2015-TPAC-F2F

<wilhelm_> https://www.w3.org/wiki/WebDriver/2015-TPAC-F2F

Bluetooth

<wilhelm> Scribe: wilhelm

<ato> wilhelm: topic?

sam_: Speaking to people at Google, they're interested in having a cross-platform, cross-browser tests that work.
... We are helping the input event people in the blink team do cross-platform tests.
... They want to do the same for Bluetooth, USB; etc.

jyasskin: The bluetooth interaction model is that the web page calls a function which calls a dialog to select bluetooth devices.
... In order to write wpt for this, we have to have a way to control that dialog from the test.
... Mock up what device the test is talking to.
... The first half of that is essential for any users trying to test the web bluetooth protocol in an automated way.
... Simulate the user clicking. Second half less neccessary, they may have a device.
... The dialog is something in the browser UI.
... FUnction to open it is in the spec.
... I've started describing JS functions the test can call.
... IT's not clear that is the right way to do it.

<jyasskin> Test function specifications: https://webbluetoothcg.github.io/web-bluetooth/tests/

jyasskin: They run inside the chrome tests.
... We have shared tests for a bunch of specs, and they need some functions like this.

jgraham: Faking hardware input is a neccessary step.
... How do we want to approach this problem on the platform?
... See also geolocation.
... I feel like there is an advantage to do this in webdriver.
... Advantage for people who test their applications. We need to be very careful that it doesn't assume certain UI conventions.

jyasskin: Look at events in spec. The events are all abstract.
... You can tell it to scan for bluetooth, dismiss dialog, etc.
... Not click on this button.

simonstewart: THe closest we have to this is geolocation in Selenium.
... Two interesting use cases: Writing tests, have a device. Your particular use case.
... Existing functionality is for the first case. Can also spoof location.

jyasskin: Can you deny the geolocation request?

simonstewart: Not fleshed out.

ato: I don't know if we need the same model as user prompts.
... If you decline the dialog, that gives you a response.

jyasskin: The request device call is in response to a user gesture.

simonstewart: Is it modal?

jyasskin: It's close to modal.

ato: In FF, geolocation has a doorhanger.

jgraham: Not modal.

ato: Two forms: tab-modal, global modal.

jgraham: Doorhanger is optional to interact with.

sam_: From Webdriver's POV, this is modal.

jgraham: No, this is an implementation detail.
... (Compares to alert.)

ato: It's not blocking.
... Does not halt script execution.
... If you navigate to a page, the user should expect the dialog.

jgraham: What's here would map well to a Webdriver-style API.

ato: Current status: WOrking on low-level APIs, primitives. Fleshes out the processing model, the endpoints, how commands are executed.
... We're not going to put anything new into the spec.
... We think we are at a point where the spec is mature enough that we can start thinking about adding new things. New levels on top of the current spec.
... We don't know what it'll look like. Level 2? Extension?
... Now is the right time to start thinking about this. Approaching completion of level 1.

sam_: We've been talking about Bluetooth. USB?

jyasskin: Haven't talked directly.
... Basic idea is the same. Permission request, remote device.

jgraham: Mocking up the remote device: How do you expect that to work?

jyasskin: In the current spec, there are fake adapters.
... That's not what we need for end-user testing.
... To help end-users write tests, WD need to completely configure device ahead of time.
... Or for WD to act like the device.
... More compliated than geolocation

ato: ONe of the limitiations of the WD API. One directional.
... Driver can't call the client.

jyasskin: Most of the BLuetooth spec is requests.

simonstewart: The mock device would be a separate process.
... You then let the browser do its connection.

sam_: You probably have a lab full of these devices. To automate tests with WD; you need access to the dialog.

simonstewart: How would the user interact with the browser to make it do this?
... The device is a separate problem.
... Close to geolocaiton.

John: More complex, like the print dialog.

simonstewart: Like the media stuff. Allow/deny.

(More discussion on the continiuum between geolocation and browser-specific dialogs.)

jgraham: To test the implementations, you may need a JS bluetooth device.

jyasskin: Two levels of testing: we want to test an actual device.
... I'd like to be able to write tests in JS and have one of the backends control the actual device.

ato: Two ways to mock out bluetooth device. Instead of using the actual device, replace them with this fake list of devices.
... Problem with that is that you can't emulate the device output.
... Alternative: out of process emulation.
... Do you want to test the actual driver that goes out of the browser?

sam_: If you wanted to do that, you can write something that talks to the OS in a way that does that.

jyasskin: Buy a bluetooth radio, configure it as the actual bluetooth device.
... Misses firmware issues.

John: YOu can test a lot without going to actual bluetooth.

jgraham: How can we write tests that are shareable?
... Special kernel module is hard.
... Can you write a Python script it act as Bluetooth device?

jyasskin: (Refers to Chrome OS implementation.)

jgraham: May be possible to write, running with root.

jyasskin: Mock adapters make a mock layer in the browser, close to the platform abstraction layer.
... If we can standardise the calls that are used, it should be shareable.

jgraham: From WPT POV, if we can supply something that provides Bluetooth events, it's shareable. Difficult.

simonstewart: Out of scope for Webdriver, in scope for Bluetooth.
... Add to WD spec, or add bits to the other spec.

AutomatedTester: With Marionette, we have a way to switch context. Switch into chrome space, this is what you can expect.

jgraham: Lower level than that.
... Unless there is a higher level API that would be good enough, you need to build it into the browser on a lower level.

ato: How do you make the output of that device? Preconfigured?

simonstewart: In the browser sounds like tha wrong place.

sam_: It wouldn't be that analogous to geolocation
... An out of process thing.

simonstewart: Writing a BT emulator is a lot of work.

jyasskin: Just Bluetooth low energy. Smaller feature set.
... But not tiny,.

simonstewart: To make it shareable, make the emulator in a portable subset of C.

jgraham: If you want to do it at that level, it's platform specific.

simonstewart: How does a device appear to the OS?

jyasskin: A BT device. Radio.
... We have a partial implementation in Chrome.

simonstewart: How do I talk to it?

sam_: Stream of data

jyasskin: OS-level API. Not sockets.
... Tree of key-value pairs.
... YOu can subscribe to notifications from the device.
... We want to control when those notifications come.
... We want everything to be request-response.
... (Describes data exchanged in notifications.)

sam_: How hard would it be to make the key-value tree?

jyasskin: Straightforward to make JS that models this tree.
... Verbose, code that crosses boundaries in Chrome.

AutomatedTester: Switching contexts.

jgraham: THe BT stuff is lower level.
... We have a special type of internal worker that can inject stuff that to the rest of the brower looks like a BT device.

ato: Conceptual worry: tests would not be shareable.

(Discussion on context-switching approach.)

jgraham: Unless you write a OS daemon, you need a mock layer in the browser.

ato: Practically, that would look like an endpoint in WD.

jgraham: The WD side is not the difficult or important part.

ato: Two concerns: Control the UI. Mock it out.
... The first is within scope.
... Very worried about the second one.

jgraham: THis is the wrong group for the second point.
... Do we want to make the mock layer in the browser, or closer to the OS?

ato: Starting with the stuff that controls the UI may be a first step.

jgraham: For the other concern, input from browser vendors.

jyasskin: MS supportive, Apple not enthusiastic about BT work.

sam_: We need to figure out how to mock a device. Then talk about endpoints.

ato: Is Google willing to take this on?

sam_: Yes.

jyasskin: I'll put the spec in the BT repo for now, until you guys are ready.

<jyasskin> Current draft BT test specification: https://github.com/WebBluetoothCG/web-bluetooth/tree/gh-pages/tests

wilhelm_: Let's use this example to figure out how to do extensions to WD in general.

jyasskin: Simulate user gesture, controlling the dialog, specified in the linked repo.
... They may not be correct.

ato: The WD process so far has been based on existing implementations. This is the first feature that hasn't been implemented by anyone.

jyasskin: Planning to work with Mozilla to make sure our tests are interoperable.
... We may want to wait until the tests work before getting them into WD.

<scribe> ACTION: sam_ to coordinate the Webdriver-Bluetooth work [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action08]

AutomatedTester: For the mock stuff, contact public-test-infra.

ato: I expect no feedback.
... Find the right people.

(Discussion on testing in current emulators.)

(Discussion on BT tests in mozilla-central.)

(Discussion on test infrastructure specifics.)

https://www.w3.org/wiki/WebDriver/2015-TPAC-F2F

<simonstewart> https://www.w3.org/wiki/WebDriver/2015-TPAC-F2F

Visibility

<gitbot> [13webdriver] 15AutomatedTester closed pull request #187: Get Element Attribute: make it actually return the attribute value (06master...06get_element_attribute_fixes) 02https://github.com/w3c/webdriver/pull/187

<AutomatedTester> scribe: AutomatedTester

ato: while working on the spec for the last 4 months, visibility has been the hardest thing to document
... we have ported the atoms
... if we look at the specification in section 10.1

<simonstewart> https://w3c.github.io/webdriver/webdriver-spec.html#element-displayedness

ato: this is basically a tree traversal algorithm and does a quite number of passes and is not efficient
... an option element can have it's own displayedness that is different to it's parent <select>
... (gives examples of special cases)
... so the algorithm does quite a few passes by looking at DOM
... it also looks at the CSS properties that can make it harder to traverse
... border is not taken into account in Selenium

simonstewart: is that a bug in Selenium or not implementned?

ato: it is not implemented
... there is a problem that the visibility is not done in an atomic actions e.g. animations
... new technologies are going to make this hard e.g. ShadowDOM
... currently there is no support for tree traversal with shadow DOM and there is also scoped stylesheets in shadowDOM
... currently visibility doesnt handle initial vs full view port on mobile e.g. zooming in and zooming out

jgraham: so should we have this in the spec since we know that we can't support it

<simonstewart> http://rawgit.com/slightlyoff/IntersectionObserver/master/index.html

simonstewart: this is important for WebDriver

jgraham: do you mean for Selenium?

simonstewart: no, this is Selenium.
... WebDriver is to emulate what the user is doing

wilhelm_: should this be in the local end or remote?

jgraham: it can't be in the browser because we can't keep this going

sam__: we are seeing issues with ShadowDOM

simonstewart: this is key item in WebDriver

ato: no is saying that we don't want it

jgraham: it can't be implemented as it is

simonstewart: we need to ring fence the conditions that we know it can handle. Other specs need it

jgraham: we could have a broken spec as new items come in

simonstewart: we could define conformant tests

jgraham: no, we need to have this in the spec

ato: this is hard to explain to users conceptually
... there is elementFromPoint that can tell us the element
... border radius elements could be harder

simonstewart: that could work for interactions

<simonstewart> https://drafts.csswg.org/cssom-view/#dom-document-elementfrompoint

AutomatedTester: (discusses elementFromPoint)

ato: we should get a data point of how we could use elementFromPoint

jgraham: this is useful for interactions but not an endpoint

ato: browsers don't know what has been rendered anymore. You are sending things to the GPU and then it is painted. This will make it significantly harder

wilhelm_: if we could get info from the compositioning layer

simonstewart: or delegate

jgraham: this is an At Risk item if we are moving to CR

simonstewart: we need to have some mechanism for interactability

jgraham: elementFromPoint will be able to handle this easily

simonstewart: what about the clickjacking problem? (goes in search for a test)

<juangj> https://github.com/SeleniumHQ/selenium/blob/ab1e647d0fc8fc39e6b00ae94321ab228b6728f2/java/client/test/org/openqa/selenium/VisibilityTest.java#L292 <— simon, is that the test you were looking for?

<selbot2> 03titusfortner 27 days ago - rb - clarify specs for handling missing element attribute call | https://github.com/SeleniumHQ/selenium/commit/ab1e647

(discussing about overlays and clicking)

<juangj> :whobrokeit

<selbot2> simonstewart

click jacking works in Chrome and FirefoxDriver and not IE and Marionette

<simonstewart> https://drafts.csswg.org/cssom-view/#dom-document-elementsfrompoint

simonstewart: what about z-order list?

jgraham: elementsFromPoint could do this

juangj: not implemented everywhere

<juangj> for posterity, here’s the HTML page used by the test i linked above: https://github.com/SeleniumHQ/selenium/blob/master/common/src/web/click_jacker.html

simonstewart: we need to check if an opacity is 0 and then bubble the lower element
... (shows an example of clickjacking)
... visbility is very important?

jgraham: interactions or in general
... clients should be allowed to innovate on displayed items and we don't need this to be in the spec
... for clicks/tests elementFromPoint is what we want of and what is the first visible check

simonstewart: I am ok with dispalyed not being an endpoint but we most definitely need this for interactions

ato: you are concerned if we push this to algorithm to clients because they will diverge

(discusses server changes)

RESOLUTION: Displayedness to be pushed to v2 while better primitives are created

<scribe> ACTION: Gather data on differences between treetraversal algorithm and a elementFromPoint with wrinkles (opacity) [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action09]

RESOLUTION: current displayedness to be moved to an appendix as non-nomative text so people are aware of changes

moz#1164427

<selbot2> 03Nobody; OK to take it and work on it NEW/ Support elementsFromPoint (and elementsFromRect?) - https://bugzilla.mozilla.org/show_bug.cgi?id=1164427

<juangj> seva_: you have electricity??

<seva_> juangj: :) yep, am in developed parts now

Permissions

simonstewart: there is a pattern to use a secure service (webbluetooth, etc). This has allow/deny and and option you can select
... ato and I started discussing a permissions endpoint
... and this would set the permissions
... we would also have multiple permissions that allow this. (web bluetooth, geolocations, etc) with this own allow/deny items
... there are going to be more and more specs extending webdriver

ato: one of the questions we have? are spec languages for user "permissions"

jgraham: the whole area is a disaster area in terms of spec.
... not all permissions are not handled the same, e.g. geolocation is not the same as fullscreen
... UAs dont want to give users too many permission requests

ato: e.g. google hangouts asks for camera, microphone
... we need an abstract way to handle permissions

sam__: what would it mean for things enabled by default or can be set in the profile?

ato: in that case, the test would look for requests for permission and if there are no perms then it would carry on

<simonstewart> So there would up to three parameters: the selector for the kind of permission ("geolocation", "webbt"), a selector for the identifier ("bluetooth device name", "camera to use" --- normally a string), and accept/deny

(discussion how this works see, simonstewart comment right above)

jgraham: is the set proactive or reactive

AutomatedTester: I think it should be reactive
... I think it should be proactive

jgraham: we were discussing this as reactive with the bluetooth folks

sam__: how would we handle this since they are normally per domain

jgraham: this would be on the active document domain

<ato> wilhelm_: Refresh

<ato> wilhelm_: Oppdater, fisketryne

<sam__> present SamUong

<simonstewart> scribe: simonstewart

Accessibility

cyns: Two kinds of testing.
... accessibility testing is time consuming. Only time for one test pass
... browsers do a mapping from ARIA to an underlying OS accessibility api

<jessebeach> jessebeach+

cyns: (enumerates)
... need to take every valid ARIA role and element combination and check them all. 900 ARIA test cases, and each takes 10 minutes
... want to add ability to test api layer to webdriver so you can check whether or not the righ tthing is coming from the OS
... want to be able to write test cases that say I have a button tag, the accessibility says you get a button, and you can click t

joanie: has a demo that runs a test and the browser appears and disappears.

<joanie> http://www.fpaste.org/283921/raw/

joanie: this file tests using data URIs. There are various ARIA things like role, description and accessible name

<joanie> http://www.fpaste.org/283926/91524714/raw/

joanie: each platform has its own accessibility api. linux has atk on the "server" side and at-spi2 on the client side
... without some way of doing testing directly, I have to do a tree-dive.
... this code finds the application with the given name, and then starts looking for accessibles. Probably prone to failure. Once it's got the accessible object, you can do the automated testing

<joanie> https://dl.dropboxusercontent.com/u/1643605/success.png

<joanie> https://dl.dropboxusercontent.com/u/1643605/fail.png

joanie: images are of successful and failing tests

<ato> Scribe: ato

simonstewart: From element ID to accessibility ID?

cyns: I’m not exactly sure.
... Compare what’s in the markup to what came out in the platform.
... I can write on the whiteboard.

simonstewart: That would be useful.

jgraham: I don't entirely understand.
... How platform-specific is this?
... Can we have a high-level platform independent abstraction?

simonstewart: The idea that I though was being proposed was.
... Get me the accessibility ID, produce two trees and compare.
... Are accessibility IDs opaque keys

?

simonstewart: Or model the whole thing in WebDriver?

cyns: For the purpose of testing a browser, to know that this button is a windows button; is it invokable? can you press it?

simonstewart: Are those properties exposed through JS?

cyns: No.
... You make a OS specific call.

wilhelm_: How specific is that?

cyns: I don't understand the question.

simonstewart: What if we give you access to the accessibility ID?
... Is that enough?

cyns: From outside the browser?

simonstewart: That seems like the natural hook-point then.

wilhelm_: Is that what we want?

jgraham: That seems like what you want, if you're doing quite a low-level browser test.
... It seems like it's probably not what you want if you're a website author.

richardschwerdtfeger: The problem we have is if you're testing your website for accessibility, all the test tools look at the DOM.
... Where we're going it's going to get into a model.
... They need to look at a middle layer that exposes this to JS.
... That's what we would _like_ to have access to.

simonstewart: Are you specifying that?

richardschwerdtfeger: If you're an author you don't want to worry about OS specificness.

cyns: Some authors do.
... The Word team does.

jgraham: We definitely have a feature request for a fairly low-level API.
... Use webdriver to get the accessibility ID of a specific element, which you can then pass to the platform API.

cyns: Right.

simonstewart: That should be do-able.
... It sounds reasonable.

jgraham: There's a second thing, which is getting some form of platform-independent abstraction.
... Do you want it as a DOM API, so it's accessible from normal content script?

wilhelm_: Yes, because if that exists it's easy for WebDriver to hook into it.

richardschwerdtfeger: We're limited by what the DOM provides, yes.
... Firefox has a special API for that.
... We need to get it in a platform-neutral way.
... Two different use cases.

jgraham: It sounds like you want a DOM API that does that, and then once there's a DOM API that does that, it would be accessible to your tests and to WebDriver.

wilhelm_: Starting with the DOM API, then making endpoints for that in WebDriver I think is the right thing to do.

jamesn: In Firefox with plugin architecture you can get this.
... Could we use that with WebDriver today?
... Can we get that in a platform-independent way?

simonstewart: Accessibility nodes of the elements; certainly on two platforms it's sometimes possible.
... If we could get hold of that, serialise it, pass it back to the Python test and then deserialise that in Python and pass it to the underlying platform API, then that could work.

wilhelm_: How difficult?

JohnJansen: One endpoint.

simonstewart: Once you get hold of the underlying node, then you can pass it to nsIAccessible.

jamesn: I think you can do something similar in Chrome.

sam__: I don't really understand how accessibility works in Chrome.

<joanie> https://dl.dropboxusercontent.com/u/1643605/inspector.png

sam__: I can talk to the accessibility team about it though.

jessebeach: There's an automation in the background of Chrome that will give you information about those sort of things.

AutomatedTester: We have briefly discussed this before.
... What it if could give you the WebDriver serialisation and the accessibility element serialisation.

simonstewart: Yes we have discussed this before.

<simonstewart> https://github.com/SeleniumHQ/selenium/blob/master/cpp/webdriver-firefox/nsIAccessibleDocumentWrapper.h

joanie: I pasted another screenshot.
... Bottom right corner, there's a little accessibility section.
... Parent, label, clickable.
... That's what was discussed in regard to the intermediary layer.

<simonstewart> https://github.com/SeleniumHQ/selenium/blob/master/cpp/iedriver/Alert.cpp#L209

joanie: There's no specified API as far as I know.
... There's stuff in WebKit you can play with.
... How many years it takes for there to be a DOM API.
... This is do-able now.
... If you have something working, and it works really well, it wouldn't be too hard to convince Mozilla and Microsoft.

cyns: We don't currently have an intermediary layer. We go right in with C++.
... This kind of stuff is very useful to web developers.
... Then the other part is useful for testing browsers and specs.

joanie: If we had a platform-agnostic level, then we could hook into that...
... The name, description, role, all exists in the intermediary layer.

cyns: How do we make this happen?

AutomatedTester: Proper set of requirements, so we know exactly what we need to do.

jgraham: I think what you mean is "file a bug".

<simonstewart> https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=20860&hide_resolved=1

simonstewart: Two bugs please.
... Push it into level 2 or now.

cyns: Last year would be great!

JohnJansen: 2020 ok? (-:
... We're thinking about going to REC in January. Well, soon.

jgraham: This can't go in level 1.

simonstewart: Can it not?

cyns: I would love to start drafting it now.

JohnJansen: We could put it in now, mark it "at risk" and then remove it later.

jgraham: We can't put it in now because it will be removed.
... There are no implementations.

cyns: Having something drafted, and starting to play with the implementation, and use it for my own internal testing, would be quite useful.

wilhelm_: For the second level here, the more generic thing that gives you more information, you need to figure out where in the stack that belongs.
... If it's a DOM API it's easy for us to hook into.

cyns: Yes, that's what we're discussing.
... That was easy.

simonstewart: If you would like to argue, we can oblige.

cyns: We appreciate the help.
... Will sync up with JohnJansen.

wilhelm_: It's fun to see that other people are picking up on other baseline we're setting out.

https://bugzilla.mozilla.org/show_bug.cgi?id=1164427

<JohnJansen> scribe: JohnJansen

Issues in the Spec

<AutomatedTester> http://w3c.github.io/webdriver/webdriver-spec.html#issue-1

simonstewart: seva convinced us in SF that it would be very difficult to spec issue

1

jgraham: localends should perform HTTP requests that conform to this spec

simonstewart: don't we say that?

ato: no, I'll add it

jgraham: we don't say what a valid command is
... for the local end
... section 4 is about the remote end

<jgraham> Issue 1 is about defining what are the valid messages that a local end can send for each command and saying that they must only send such commands

<AutomatedTester> http://w3c.github.io/webdriver/webdriver-spec.html#issue-2

ato: we can remove issue 2, I don't feel we need the intro

<AutomatedTester> http://w3c.github.io/webdriver/webdriver-spec.html#issue-3

ato: seems valid

jgraham: the point is that if the request fails, what happens?

ato: makes sense

<AutomatedTester> http://w3c.github.io/webdriver/webdriver-spec.html#issue-4

ato: is there a good reference we can leverage here?

jgraham: the problem is that when we construct json object, it's incredibly verbose
... could this be less verbose?

simonstewart: we could define something in the spec for this

jgraham: seems like we don't really need this

ato: OK

simonstewart: we could just do a table

jgraham: nope

<AutomatedTester> http://w3c.github.io/webdriver/webdriver-spec.html#issue-5

ato: what does browser state mean here?

jgraham: global state of the browser... is this saying there needs to be 1 session per... probably just go

<scribe> ACTION: drop issue 5 [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action10]

<AutomatedTester> http://w3c.github.io/webdriver/webdriver-spec.html#issue-6

simonstewart: should be part of the page loading strategy

<simonstewart> https://w3c.github.io/webdriver/webdriver-spec.html#dfn-page-loading-strategy

simonstewart: following normal page loading strategy, you are already obeying the refresh
... don't have conservative anymore, so cut that

jgraham: do existing implementations do this?

AutomatedTester: Firefox doesn't it
... in Lyon we learned we don't

simonstewart: the paragraph is correct

ato: page loading strategies need to be tightened up

<scribe> ACTION: review page loading strategies [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action11]

ato: 7 is also to do with page loads

jgraham: I asked about this and response was that is sounds difficult to know this (knowing the back occurred and the page loaded)

simonstewart: particularly if it does a refresh and goes forward again
... depends on the page loading strategy

ato: shouldn't we just apply page loading strategies to this case?

simonstewart: if causes a page reload, then do this; otherwise, do something else

<scribe> ACTION: with the back command make sure we include if clicking the back button causes a full page navigation, then use page loading strategy; otherwise, return control immediately [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action12]

(no different from clicking a link)

<some time looking at HTML5>

http://www.w3.org/TR/2011/WD-html5-20110113/history.html

jgraham: issue 8 is about script causing the back to fail and timeout
... point is that it can take a long time for some reasons

ato: in the case of the alert, we can check for user prompt
... and handle it

jgraham: yes, but it might not do anything

ato: so then return an error

jgraham: the spec doesn't say that yet
... does the sentence sound right?
... issue 10 and 8 can be removed

<scribe> ACTION: resolve 10 and 12 [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action13]

jgraham: 13 is just a statement of fact
... actiont for 13 is that the spec needs to be finished

<scribe> ACTION: remove 13 [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action14]

jgraham: no alert happening at the current step?

<scribe> ACTION: check for user prompts on closing window [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action15]

issue 15

jgraham: step 2 and 3 look like a mistake, and 3 should be the THEN for the if in 2...

<scribe> ACTION: fix the steps [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action16]

issue 16

jgraham: legit
... you can only use elements from the current doc

ato: so need to check that element is associated with the current dom

<scribe> ACTION: link to the definition for this already in the spec [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action17]

issue 17

juangj: same argument as yesterday for get/set

ato: not about that, about if the browser can support this

jgraham: yes, text here is misleading. It is legit for an end point to say "unsupported operation"

AutomatedTester: mobile cannot resize

simonstewart: can get from mobile, but cannot set (get an error or a no op)
... but getting should always work

ato: so how do we say this?

<scribe> ACTION: issue 17 can go [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action18]

jgraham: I think set actually specifies this

ato: yes, yes it does

issue 18

simonstewart: out of bounds window sizes...

sam__: asking about maximize on Mac, which fullscreens instead of Max

ato: not fullscreen

JohnJansen: I was confused too, maybe wording needs work?

simonstewart: enbiggen?
... deshrink?

the must unlittle?

ato: you just want to be as big as possible

simonstewart: not the same as fullscreen, that's the point

juangj: mac changed what fullscreen means

jgraham: reads the spec
... nothing here can be reasonably interoperable

ato: same with fullscreen

<scribe> ACTION: need embiggen error [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action19]

imbiggen?

inbiggen?

<juangj> embiggen

imgibben?

<juangj> “inbiggen” is uncromulent bunk

ato: as large as it can?

simonstewart: then step 10 needs to return current size

jgraham: all of them should

simonstewart: you can always get it, but it's inefficient

jgraham: should return the result rather than success

<scribe> ACTION: follow jgraham's statement [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action20]

sam__: should it give an error

ato: no, we should make it as close as we can
... on linux you can go 1x1 pixel, but most sane OS limits it

simonstewart: that's clamping, so should we do that for minimum size?
... which means that steps 5 and 6 go away

<simonstewart> 5 and 7

ato: we need to handle the crazy stuff in the spec

<scribe> ACTION: drop issue 18 and remove steps 5 and 7 [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action21]

issue 19

ato: we are reworking, so we can drop 19 and 20

<scribe> ACTION: drop 19 and 20 [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action22]

issues 21, 22, and 23 are all things we need to do

issue 24 is irrelevant

jgraham: 25 is a statement of fact
... issue 26 is a statement of fact
... 27 and 28 have not been spec'd yet.

ato: uses terms from CSS

simonstewart: we want first visible client rect

<scribe> ACTION: issue 27 should use first visible client rect [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action23]

29 is the same as 27

juangj: 28 means finish this

<scribe> ACTION: delete 13.2 [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action24]

expunge it

<scribe> scribe: simonstewart

issue 31

Answer is "yes", it should work.

<scribe> ACTION: Answer 31 with "yes" [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action25]

Issue 33: should probably do what the unexpected alert handler does, and then return control to the user

jgraham: JS error case: what it says now is that for executeScript, it'll execute it and if there's an error thrown synchronously, that'll be returned to the user
... if that happens with async script, what happens?

simonstewart: then you'll hit the timeout of the async script

ato: we'll solve this with the console stuff

<scribe> ACTION: delete second para of issue 33 [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action26]

ato Issue 34: we need to read the spec again very carefully

<scribe> ACTION: Move issue 34 to step 7 [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action27]

ato: issue 40 is interesting
... if there's a prompt in safari, you can't change tab or window
... chrome allows windows, but not tabs
... just do what the browser does?

<scribe> ACTION: Add some prose to address issue 40 saying that we should do what the browser allows, and that we may need to return an error. [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action28]

Issue 41: yes, this is still a requirement

<scribe> ACTION: Add parameter to support issue 41 [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action29]

<scribe> ACTION: add prose to clarify that intermediate nodes must appear to be single threaded for each session. (that is, multiple sessions are fine, but each session should queue requests) [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action30]

<scribe> ACTION: Remove thread safety appendix [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action31]

<scribe> ACTION: remove normative language from appendix on Privacy [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action32]

<scribe> ACTION: acknowledgements should only mention each name once. [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action33]

<scribe> ACTION: Modify privacy appendix to state that sessions are advised not to share state. [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action34]

<gitbot> [13webdriver] 15AutomatedTester pushed 1 new commit to 06master: 02https://github.com/w3c/webdriver/commit/321c06c14163d75884fbc9cd9c7206f4b132009f

<gitbot> 13webdriver/06master 14321c06c 15AutomatedTester: clean up issues as discussed at W3C TPAC 2015...

<gitbot> [13webdriver] 15AutomatedTester merged 06master into 06gh-pages: 02https://github.com/w3c/webdriver/compare/0e48b3321838...321c06c14163

<juangj> Scribe: juangj

interaction

sam__: we’ve started implementing [in chromedriver] based on what’s in the spec so far
... there are a lot of open issues still. obviously that needs to be worked on and we can’t yet discuss in a lot of detail, but it would be nice to be in general agreement about what it’s going to say
... (questions about pause durations and symbols)
... if a navigation happens during an action chain, what should happen?

ato: would make sense to throw an error because you asked for something to happen and something unexpected happened

(some question about whether the page loading strategy is applicable if a low-level API causes a navigation)

simonstewart: example case where the final action in the chain is a click on a link; if a navigation occurs, then we should still follow the page loading strategy

ato: two questions: do we drop the remainder of the chain when a navigation occurs, and do we wait for the page load?
... what does selenium do here? if you have a low-level interaction chain and you click a link that takes you away from the document

simonstewart: it obeys the page loading strategy. it’ll probably attempt to finish the sequence of actions, because it’s in that block of code already. but that’s an implementation detail — next time there’s a setTimeout (on the next tick), it’ll relinquish control and then will wait for the page load to complete

ato: we should also obey the page load strategy, if selenium does

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

<AutomatedTester> http://www.w3.org/2015/10/25-webdriver-minutes.html

AutomatedTester: when we discussed this bug yesterday, we said that for low-level actions you should “do as i say”

simonstewart: for do-as-i-mean, the command should not return until after the page load is complete. for do-as-i-say, it should return immediately, but the next command should wait until the load is complete

sam__: if the action chain gets too long, local end is allowed to chop it up and send it in pieces. what if a navigation occurs in the first chunk — should the second chunk be dropped?

AutomatedTester: no, the second chunk should still be performed

even though the remainder of the first chain would have been dropped

simonstewart: the second chain is likely to fail after a navigation because the element you’re operating on no longer exists

juangj: so then the behavior can differ depending on the local end’s decision about where to break the chain

simonstewart: yes, weird stuff could happen
... in my experience, most people who use this low-level actions api don’t try to do that kind of weird stuff

sam__: when should the positions of elements be evaluated? what if an action in the chain causes an element to move?

simonstewart: when you’re about to do the command, that’s when you calculate the position of the element

JohnJansen: when you do parallel actions, let’s say you have 3. first 2 do touch, touch, zoom. the 3rd parallel action wants to do something to an element that was zoomed off the page

simonstewart: every tick that you need to interact with an element, you collect the elements you need to interact with and compute their location

ato: yes, you need to constantly reevaluate positions

simonstewart: if you’re trying to do an action chain that could make stuff move, you’re doing something inherently racy

(Doctor, my tests fail when I do this!)

<simonstewart> Ha!

AutomatedTester: (reading marionette’s implementation)

sam__: how do you test that?

ato: ….we don’t anymore. they’re broken.

sam__: (new sub-topic: pointers) when you do a pointerdown, what happens to mouse and touch events?

<AutomatedTester> https://w3c.github.io/pointerevents/#firing-events-using-the-pointerevent-interface

sam__: from a user’s point of view, you’re either touching or mousing, but if you’re synthesizing a pointer event, what other events are supposed to happen?

<AutomatedTester> https://w3c.github.io/pointerevents/#compatibility-mapping-with-mouse-events

AutomatedTester: see sec 11.1 of ^^

<AutomatedTester> http://www.w3.org/TR/touch-events/#mouse-events

<AutomatedTester> https://w3c.github.io/touch-events/#mouse-events

<scribe> (continued discussion of how to implement these events)

sam__: people working on input on chrome find this low-level actions stuff very interesting

<ato> jgraham: ++

sam__: would like to write tests using something similar to the WPT JS tests thing discussed yesterday
... we have someone working on the layout tests now. could possibly contribute to WPT as well

AutomatedTester: speak to jgraham about that

sam__: we had to add cross-domain rpc in order to implement this. does that need to be in the spec as well?

ato: you should be able to set access-control-allow-origin
... (also described something horrible he did in the prototype that he seemed pretty ashamed of)

sam__: anything else about the WPT runner we should discuss?

ato: well the project proposal isn’t quite done yet but we should talk further

that discussion to be continued wednesday

screen capture capabilities

ato: http://www.w3.org/TR/webdriver/#capabilities
... two capabilities defined: takesScreenshot and takesElementScreenshot. didn’t we decide at some point that this would be mandatory?
... there’s nothing in the ‘screen capture’ chapter that says this behavior is optional

simonstewart: headless implementations like phantomjs can’t do screenshots

ato: does that need to be conformant?

simonstewart: yes

wilhelm_: it can’t just render that somewhere?

ato: it knows where things are, but it doesn’t ever draw them to a canvas

JohnJansen: our headless implementation, you can still render to memory

ato: htmlunit is different though
... there are many other things in the spec that htmlunit doesn’t/can’t support
... the argument for making these caps optional in the first place was about full-page screenshots

simonstewart: not only that, but originally, we weren’t able to take screenshots at all in some browsers

ato: i think the screen capture chapter is sufficiently non-controversial. it can be reasonably implemented in all browsers

resolution: remove takesScreenshot and takesElementScreenshot capabilities

JohnJansen: we already removed this for css selectors and executing JS
... what about SSL certs? afaik all browsers can handle invalid ssl certs

AutomatedTester: that cap is about the ability to override the invalid cert warning (e.g., IE won’t do it)

<scribe> ACTION: rewrite the prose on acceptSslCerts capability [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action35]

<scribe> ACTION: specify what the “level of the specification” means, in the specificationLevel capability [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action36]

jgraham: this sort of versioned API never ever works, where you continually add stuff to the API instead of having genuinely new versions

simonstewart: the reason we have the capabilities in the first place is to say “here are the things i support”. you could be conformant with level 1, and then add, e.g., ‘getAccessibilityId’
... use of named capabilities is feature detection

ato: you still need the ability to distinguish between a remote end that is a selenium server and a webdriver server

discussing removal of the specificationLevel capability

ato: i don’t think it makes sense to have this specified because it implies you can request something that isn’t compliant

simonstewart: every new feature should just have a capability

jgraham: you don’t even need that, you can just check if the endpoint exists

JohnJansen: what if you make a breaking change to an endpoint? it’s not sufficient to check if it exists

simonstewart: if you do that, you make it a new endpoint
... there will be a handshake (describing mechanism)

JohnJansen: but how do you know in the handshake what version of the server you’re speaking to

(somebody): what this field should really be is protocolVersion, not specificationLevel

simonstewart: you can craft a way to detect whether you’re talking to a compliant server from the very first request
... right now, we can tell the difference between protocol versions. later on, if there’s a change that makes it not possible to determine, then we might need to do something

AutomatedTester: why isn’t it in /status; language bindings can call /status first before initiating a new session

simonstewart: that’s insane and nobody does that

jgraham: we have no plans to break the protocol right now. there’s no reason to try to do anything now about the hypothetical case where we break the protocol.

<AutomatedTester> https://github.com/SeleniumHQ/selenium/blob/master/java/client/src/org/openqa/selenium/remote/service/DriverService.java#L172

<ato> simonstewart: https://w3c.github.io/webdriver/webdriver-spec.html#dfn-status

questions on what the purpose of /status is

questions on where /status even came from in the json wire protocol

<wilhelm_> https://lists.w3.org/Archives/Public/public-browser-tools-testing/2015JulSep/0022.html

simonstewart: /status doesn’t give you anything. it’s about server management, and server management isn’t part of the protocol

jgraham: it’s not something your browser is concerned about, you don’t call microsoft.com/status before trying to connect to microsoft.com

simonstewart: suggest we take out the /status endpoint

AutomatedTester: everybody in oss land is whining that marionette doesn’t have this endpoint. everybody else does (chromedriver, edgedriver)

ato: how is this better than an http command that just waits until it’s able to connect

simonstewart: if you’re going to write a server process, it’s polite to have a mechanism for saying you’re alive, but it’s irrelevant to the spec
... it’s no different from calling new-session repeatedly until it succeeds

wilhelm_: it doesn’t have a side effect

simonstewart: but new-session is always the first thing you do after /status succeeds

jgraham: you should just poll the port

ato: jimevans said on irc that there are drivers that open the port before the browser is initialized

simonstewart: then ‘new session’ should fail

resolution: remove /status endpoint

simonstewart: there could be a note about this

JohnJansen: this could be done as a ‘MAY’ about implementing a ‘/status’ endpoint

ato: i don’t think we should say anything
... it seems like we’re assuming some drivers might be poorly implemented

jgraham: a side-effect-free way of checking that the server is up would be to ask it to quit a non-existent session

ACTION- 36

<scribe> ACTION: drop “specificationLevel” capability [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action37]

(apologies as i didn’t capture all of the nuances of the end of the discussion about why specificationLevel is no longer necessary)

Future direction of the WG and rechartering

<JohnJansen> scribe: JohnJansen

The Future

ato: writing a list of things that must happen to go to RC

<scribe> ACTION: paste list into the webdriver wiki and send mail with link [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action38]

AutomatedTester: we need to make sure that we spec that the capabilities are vendor prefixed
... for vendor prefixed capabilities, return vendor prefixed cababilities

<scribe> ACTION: wilhelm_ turn actions into bugs [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action39]

(they should block RC, so should be in bugzilla)

ato: q for microsoft: bounding box from the frame buffer

https://w3c.github.io/webdriver/webdriver-spec.html#screen-capture

ato: this might be to vendor specific (step 7 specifically)

JohnJansen: seems like it is to UA specific

ato: steps 4, 5, and 6 can go and replace with something agreeable

<scribe> ACTION: ato make chapter 18 less implementation specific [recorded in http://www.w3.org/2015/10/25-webdriver-minutes.html#action40]

ato: accessibility, mobile, console, and logging should be considered for FUTURE

jgraham: not sure we should take on mobile

simonstewart: people doing native implementations that will feed back into the spec

ato: there are web apis that firefox os implements, need to flesh out what we might need
... it won't be one big mobile spec

simonstewart: json wire protocol will feed the spec

wilhelm_: nothing platform specific

<simonstewart> https://github.com/SeleniumHQ/mobile-spec/blob/master/spec-draft.md

jgraham: if this is for webdriver to generate events for 'vibrate' (for example); if it's "click a button in iOS" that's not something we should do

AutomatedTester: orientation is something we might want

wilhelm_: locator strategies

simonstewart: logging includes what is going on with the overall session

ato: what does performance logging look like?

simonstewart: in wd protocol there is a mechanism for accumulating logs, including perf logs.
... and then we have permissions as well

ato: should we mock out mics, cameras?

wilhelm_: it's part of the bluetooth category

AutomatedTester: but out of scope for this group

ato: what about subtitles?

wilhelm_: we don't need that kind of detail now

beer?

yes.

shouldn't we have actions that have deadlines?

with a 6 month extension, we should target less than 6 months

(all agree)

ato: it's 50% of my job until Christmas
... we just need more people contributing

AutomatedTester: I'm taking interactions

simonstewart: i'll have time once <> launches

ato: most of my time will be on the test suite

AutomatedTester: let's get to Dec 15th and see where we are

pub

(all agree)

This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/gr/tr/
Succeeded: s/Leon/Lyon/
Succeeded: s/sentense/sentence/
Succeeded: s/meas/means/
Succeeded: s/enbiggen/embiggen/
Succeeded: s/irrelevatn/irrelevant/
Succeeded: s/loding/loading/
Succeeded: s/endpointf/endpoint/
Found Scribe: AutomatedTester
Found Scribe: wilhelm
Inferring ScribeNick: wilhelm
Found Scribe: juangj
Inferring ScribeNick: juangj
Found Scribe: sam
Inferring ScribeNick: sam
Found Scribe: juangj
Found Scribe: sam
Inferring ScribeNick: sam
Found Scribe: juangj
Inferring ScribeNick: juangj
Found Scribe: simonstewart
Inferring ScribeNick: simonstewart
Found Scribe: wilhelm
Inferring ScribeNick: wilhelm
Found Scribe: AutomatedTester
Inferring ScribeNick: AutomatedTester
Found Scribe: simonstewart
Inferring ScribeNick: simonstewart
Found Scribe: ato
Inferring ScribeNick: ato
Found Scribe: JohnJansen
Inferring ScribeNick: JohnJansen
Found Scribe: simonstewart
Inferring ScribeNick: simonstewart
Found Scribe: juangj
Inferring ScribeNick: juangj
Found Scribe: JohnJansen
Inferring ScribeNick: JohnJansen
Scribes: AutomatedTester, wilhelm, juangj, sam, simonstewart, ato, JohnJansen
ScribeNicks: wilhelm, juangj, sam, simonstewart, AutomatedTester, ato, JohnJansen
Present: Andreas Burns David DavidBurns JohnJansen Sam SamUong Simon Stewart Tolfsen Uong Wilhelm ato brsun jgraham jocelyn juangj zqzhang cyns Rich_Schwerdtfeger JamesNurthen Mark_Sadecki Joanmarie_Diggs matt_king jessebeach
Agenda: https://www.w3.org/wiki/WebDriver/2015-TPAC-F2F

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 25 Oct 2015
Guessing minutes URL: http://www.w3.org/2015/10/25-webdriver-minutes.html
People with action items: 34 acknowledgements add answer appendix ato check delete drop each fix follow gather issue johnjansen link merge modify move need note parameter paste privacy prose remove resolve review rewrite run sam_ samuong some specify wilhelm_ with

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.