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