17:04:14 RRSAgent has joined #webdriver 17:04:14 logging to https://www.w3.org/2017/11/09-webdriver-irc 17:04:23 RRSAgent: make minutes 17:04:23 I have made the request to generate https://www.w3.org/2017/11/09-webdriver-minutes.html jgraham 17:04:40 Agenda: https://www.w3.org/wiki/WebDriver/2017-TPAC-F2F 17:04:47 Meeting: Browser Tools- and Testing WG meeting, Thursday 9 November 17:04:58 q+ 17:04:58 Present+ jgraham 17:05:02 present+ ato 17:05:02 present+ jimevans 17:05:07 present+ clmartin 17:05:08 Zakim has joined #webdriver 17:05:10 present+ soareschen 17:05:12 q- 17:05:18 present+ AutomatedTester 17:05:23 present+ alrra 17:05:46 scribenick: clmartin 17:05:53 present+ simonstewart 17:05:57 JohnJansen has joined #webdriver 17:06:11 auchenberg has joined #webdriver 17:06:11 brrian: We are starting the meeting momentarily. 17:06:20 Present+ JohnJansen 17:06:38 juangj has joined #webdriver 17:06:50 Bbrian is in the car. I’m going to call him when we start. 17:06:58 OK 17:07:19 simonste_ has joined #webdriver 17:07:20 sho has joined #webdriver 17:07:23 present+ juangj 17:07:35 tboyles has joined #webdriver 17:07:56 https://www.w3.org/wiki/WebDriver/2017-TPAC-F2F 17:07:56 present+ 17:08:07 agenda: https://www.w3.org/wiki/WebDriver/2017-TPAC-F2F 17:08:24 ato: need to discuss what we have to complete first/prioritization of the agenda 17:08:34 alrra_ has joined #webdriver 17:08:40 present+ rbyers 17:08:58 present+ auchenberg 17:09:26 Hexcles has joined #webdriver 17:10:42 AutomatedTester: doing introductions 17:13:06 jrossi has joined #webdriver 17:13:19 lucast has joined #webdriver 17:14:35 AutomatedTester: Moving on to the next item in the list, we have a state of the union so we can describe where we are 17:14:37 titusfortner has joined #webdriver 17:16:05 simonstewart: We are currently at candidate rec. in order to transition from cr to pr (proposed rec) we need the w3c to give us the thumbs up. 17:16:08 snishimura has joined #webdriver 17:16:32 simonstewart: to do that we need proof of interoperable implementations of the standard. we have w3c versions of the protocol via iedriver and geckodriver 17:16:36 JohnJansen_ has joined #webdriver 17:16:37 jgraham: do we have a url? 17:16:59 simonstewart: we do and david will get you those. we need to come up with a convincing argument for why this is good enough or we need more demonstrations of interoperable implementations 17:17:06 simonstewart: that's where we are 17:17:20 simonstewart: do you have anything else to add david? 17:17:44 AutomatedTester: I don't think so. we have other things we want to move forward on but we want a better understanding of the process before we do that which is why there are a large number of pr's on the GitHub repo 17:17:55 AutomatedTester: they're on a separate branch 17:18:12 jgraham: for example we're waiting on new features that can be merged however they all need tests 17:18:23 Test results can be found here: https://w3c.github.io/webdriver/results/2017-10/html/all.html 17:18:39 ato: to expand on what jgraham just said, we now have a policy that any change to the spec needs to be coupled with tests going into the web platform tests which seems reasonable as we now have our test suite up and running 17:19:37 ato: I wrote an email to the mailing list because as an implementor i'm not concerned about it moving to rec so much as having a living document that reflects the current reality. there are pr's in the queue that actively prevent marionette from implementing and it's only going to get worse. automatedtester branched off so we can merge things from the queue into that branch 17:19:45 rbyers: i assume the test match the master branch? 17:19:50 ato: that's correct 17:20:01 rbyers: what are firefox's results? 17:20:09 simonstewart: I've posted a link to that 17:20:34 JohnJansen has joined #WebDriver 17:20:34 AutomatedTester: that's where we are currently. the key part is moving forward we need to see where everyone's implementations are 17:20:41 There's also live results here: https://wpt.fyi/webdriver 17:20:46 brendyna has joined #webdriver 17:21:01 AutomatedTester: we can see between geckodriver and iedriver what's passing/failing. feel like it's doing a bit of disservice as we don't have something for chrome 17:21:18 AutomatedTester: or for edge or for safari, we should expand on that 17:21:37 https://w3c.github.io/webdriver/results/2017-10/html/all.html 17:21:50 JohnJansen: mind pasting the link for the results? 17:21:59 simonstewart: that's really easy to generate btw 17:22:04 jgraham: if you want we can project the results 17:23:19 AutomatedTester: i'll start with geckodriver implementation. for the most part we are doing quite well. we've been from the wd spec tests passing a large majority of it. there are a few parts where some things have changed and we need to fix those up but in general terms it looks like if we kind of implement a major feature of the specification our implementation results goes up quite significantly which is around alert handling 17:24:06 AutomatedTester: which we don't have support for yet. it is a priority and we are going to be working on it sometime soon. i'm not sure how much detail people would want to go into from geckodriver's point of view but feel free to ask any questions on what you feel might be missing. i do think in general terms that the test suite needs to be expanded where possible because we need more coverage/better coverage 17:24:35 jgraham: there's two things, one is do we think that the testing could be better? yes. do we think that that should be a prerequisite? 17:24:50 AutomatedTester: no i don't think we should gate necessarily on this being a full test suite 17:26:31 ato: can i expand on that. as AutomatedTester said we are passing a majority as we wrote them, but i do suspect as more vendors right more tests will run into problems. over the last year we have made some strides on the spec, navigation, page load strategies, pointer interactability with help from google for edge cases 17:27:14 ato: in addition to that in the past year we've done lots of refactoring on how marionette does window tracking 17:27:32 ato: I've seen the light and think we'll make progress into the next year 17:28:04 Ah, I forgot to talk about wpt.fyi. 17:28:44 rbyers: let me do a quick framing from google. big picture - we aren't investing enough. this group knows sam, he's no longer at google. john started recently on our interop team but that focuses on our interop tests. i think we should be investing more but i want to understand the arguments/where everything else is to sell back to the larger org. with that john has been working on webdriver 17:29:15 kereliuk: one of the things that took a while is actions 17:30:18 kereliuk: i have to go through all the commands in our current implementation and verify that they conform to the spec. a lot of the code in chromedriver is written by people i have to track down. aside from that the next steps from me would be (once that is merged/good) is making sure i can get a good sense on the interop suite. ran into some issues, there's a lot of overhead to that like set window rec 17:30:29 kereliuk: very soon we should be able to have a nice interoperable implementation in the next 2-3 months 17:31:11 simonstewart: one of the things we've tried to do with the spec is make the delta between the json wire protocol/w3c as small as possible. new session/actions are where we diverted. a successful result for instance look the same. 17:31:31 simonstewart: hopefully when kereliuk says you need to go through and review that it's mostly painless. 17:31:46 kereliuk: I've done a solid 50% of that and most of what I've encountered is around error codes/error messages 17:31:57 jimevans: we don't properly check for the tlbc being closed 17:32:07 kereliuk: setting timeouts is different 17:32:09 simonstewart: yeah 17:32:32 kereliuk: should be some fixes in the next release for the ruby bindings 17:32:46 kereliuk: if anyone has any specific questions please ask 17:32:52 kereliuk: i'm the one who works on chromedriver right now 17:33:06 simonstewart: would you like if i flipped the selenium project to run the w3c tests against chromedriver? 17:33:14 AutomatedTester: how would one do that for chromedriver? 17:33:21 ato: i don't think a selenium discussion is relvenat 17:33:39 jgraham: a lot of the fixes won't be there as we're using the latest release chromedriver and not the latest master build 17:34:18 kereliuk: i want to have nightly release for a project like wpt. they are available now but you have to login with a google account. we did this so we could fix wpt quicker. 17:34:33 ato: sounds like there is a little plumbing we need to do 17:35:11 jgraham: for wpt.fyi in particular as some people are interested in the conformance report more than that, there's a url we can get at that has a link to the nightly and that is kept up to date and kereliuk could consider providing the same 17:35:43 rbyers: we should also be clear that at the moment our priority is not to pass all the wpt (web platform tests) but ensuring we can automate wpt with webdriver, which is why we did pointer events first. 17:35:50 rbyers: tell me if you think that's the wrong priority 17:36:27 alex: not on irc, i represent CoSmo, we develop a tool called kite to test for webrtc. we want to test with webdriver 17:36:51 alex: don't know you guys yet so come meet me at the break so we can work together on bugs when we find them for webrtc testing 17:36:56 ato: are we done with the chromedriver update? 17:36:57 https://bugzilla.mozilla.org/showdependencytree.cgi?id=721859&hide_resolved=1 17:37:42 dr_alex has joined #webdriver 17:38:34 JohnJansen: for edge we have an interesting case for wpt.fyi in that our webdriver has to match the branch/build we're testing against. we have fairly current availability on browserstack but there are still some hiccups but i can submit them locally and get the results. i have a guy debugging it right now back in redmond. i think the tests do a check for the session to see if it's a w3c session and if it's not it'll stop. we'll pass 80% right 17:38:34 now but we're not w3c compliant. 17:38:49 JohnJansen: we're at about 80% but i don't know if that accounts for the current failures 17:39:32 jgraham: for what it's worth previously for chrome i was happy to add a hack to wptrun which is what wpt.fyi is using in the tests to say you can start an old style session so you can have the tests run. in the end chromedriver fixed it but i'm personally not opposed a failure in new session fails the new session tests not stopping the rest from running 17:39:50 ato: i think for slightly different reasons that making everything run on wpt.fyi is the right priority for the working group 17:40:05 jgraham: i think having it run there is relevant for moving the specification forward but it's just good in general 17:40:20 rbyers: when you change code you want to see how that impacts results. 17:40:38 rbyers: can't see how you would move forward without those results. 17:41:15 ato: not disagreeing but we have internal tests we pass that fail in wpt.fyi because of issues in wpt.fyi 17:41:42 JohnJansen: wpt.fyi is new so we can't rely on it yet for results 17:42:14 jgraham: i don't think the people who are working on making the drivers better are not the same people working on bug fixing wpt.fyi. it makes sense that we both have people work on the driver to make the conformance better and also working on wpt.fyi 17:42:36 jgraham: i mean the shared testing stack for wptrunning, the fixtures, the build port, etc. 17:43:24 AutomatedTester: we can finish discussing wpt.fyi in a minute, want to get through impl status 17:44:11 JohnJansen: we need to prioritize. we've been looking at internally running the tests that exist on the w3c GitHub wpt repo as well as our internal so we make sure we don't break things as we move forward. i have no worry about the high level interop, it's in production/being used by lots of teams across msft. 17:44:26 JohnJansen: not concerned with rec moving forward/being able to be interoperable it's just a matter of prioritization/time 17:44:34 AutomatedTester: any more question for john? no. 17:44:45 brrian: i'm here now 17:44:56 JohnJansen: we were doing status, what is apple's impl status? 17:45:34 brrian: not there yet but it's started. we'll be using the same engine hooks that the gtk driver uses. 17:45:56 ato: we should get an update from jim 17:46:10 GTK WebDriver: https://blogs.igalia.com/carlosgc/2017/09/09/webdriver-support-in-webkitgtk-2-18/ 17:46:13 jimevans: one of the biggest challenges was that for a while the wpt tests used a js construct that ie didn't support 17:46:26 jimevans: got some stuff he needs to fix and get merged back in 17:46:38 jimevans: other than that it's a matter of allocating the time to fix up the bugs that are the failures in the test 17:46:57 jimevans: i'm committed to getting it done. if there is a failure in the tests right now then it's a bug. 17:46:58 JohnJansen: 17:47:15 JohnJansen: do you know any that can be fixed? are you worried about risky bugs/ 17:47:20 jimevans: you mean bugs from the impl standpoint? 17:47:23 JohnJansen: yeah 17:47:34 jimevans: no, only a couple that are real challenges such as fullscreen 17:47:45 boazsender has joined #webdriver 17:47:54 ato: i think that should be fine as the fullscreen endpoint is one of the few commands we allow an error if it's not supported 17:48:09 jimevans: right, i don't think i have anything blocking my impl. it's just a matter of fixing bugs. 17:48:26 jimevans: nothing i know of that would cause regression behavior that i know about 17:48:39 rbyers: can we also hear from the people using webdriver 17:48:48 rbyers: things like how well it's meeting needs in terms of functionality 17:49:13 rbyers: i'm trying to understand separate from moving the spec to rec how well we're doing 17:49:43 ato: it's a good question but the only impls we have right now are geckodriver/iedriver. most of the bugs we've had in the last 12 months have been due to selenium problems such as something hasn't been wired up in geckodriver or selenium 17:50:38 simonstewart: i think one of the things that's really important here is from a users point of view they're using selenium, they don't care about the protocol. they don't care if it's json wire of w3c, it all just works. the actions api are a significant step forward. 17:50:53 ato: the actions api is what we inherited from before in that selenium hasn't exposed everything 17:50:56 simonstewart: the java ones do now 17:50:59 ato: excellent 17:51:18 simonstewart: you can do new actions.tick and you can specify anything you want and it will run at the same time. 17:51:25 rbyers: that's not supported in any browser yet right? 17:51:34 simonstewart: geckodriver/iedriver support it and soon chrome 17:52:10 AutomatedTester: the new design is awesome because we can do new things. 17:52:18 jgraham: should we hear from the people using it now, we've gotten derailed 17:53:33 juangj: it's not perfect yet. it may be that complex gestures work with the new api but until it works in every browser people aren't interested in using it. from surveying existing actions users no one is making an action change longer than about 3 things as it's complex/risky. moving forward that should improve and it should meet peoples needs. rbyers mentioned people wanted pinch gestures and the like. optimistic about it meeting peoples 17:53:33 demands but that's still in the future. 17:53:54 juangj: there isn't a good way in expressing that in the old apis so until the new things are ready they're hesitant to move off of the old api 17:54:33 JohnJansen: from sharepoint they aren't ready to move off of it/emails i have from sharepoint guys they're happy with how it works right now and aren't keen on putting risk into the system at the moment until later. 17:54:41 rbyers: i feel like we're de-railed on actions 17:56:09 rbyers: how is adoption going for webdriver across google juangj ? 17:56:30 juangj: mobile is the biggest complaint we get, with mobile it's touch actions. as far as other things it's permission apis/geolocation 17:57:06 juangj: similar kinds of things where there is a user prompts outside of the DOM/in the browser chrome. although those aren't really things you need to cover in the test. 17:57:10 jgraham: you can disable that in chrome yeah? 17:57:11 juangj: yeah 17:57:24 simonstewart: fixing that comes under the door hangers 17:57:33 juangj: that particular feature you wouldn't expect webdriver to addres 17:57:36 ato: it's on the agenda 17:57:39 https://www.w3.org/wiki/WebDriver/2017-TPAC-F2F 17:57:40 https://www.w3.org/wiki/WebDriver/2017-TPAC-F2F 17:57:45 JohnJansen: can someone paste the agenda 17:58:04 RRSAgent: make minutes 17:58:05 I have made the request to generate https://www.w3.org/2017/11/09-webdriver-minutes.html AutomatedTester 17:58:24 juangj: when you say are people successfully using it? yes but they're coping with the features that are available. if there are grand features that people wish existed/have dreams they can do something they have given up as this is what we have/what we can do now 17:58:34 rbyers: what about interop, do they have issues with cross browser 17:59:01 juangj: from a webdriver perspective no, for interops sake most people expect that they will work across browsers and they mostly do except that they use the legacy firefox driver. among people who have migrated interop has been good. 17:59:19 simonstewart: how many selenium tests are still being run. when i left google every team had a project being run. 17:59:38 juangj: there are no tests using selenium, they use the api 18:00:02 juangj: there are several thousand webdriver tests 18:00:46 JohnJansen: internally the thing that i hear about the most is not a bug in webdriver. we've joked about having a conversation in visibility. the edge browser itself reports things as being obfuscated/not seen on the screen. displayedness is tough. 18:01:39 ato: like i said earlier to do with pointer interaction, we had google run geckodriver with a special capability that has the new pointer work and we have found more problems but those aren't problems in geckodriver but problems in the spec/impl of other things 18:01:52 rbyers: how often does juangj take new chromedriver release 18:02:19 juangj: they do cause problems, we don't take new chromedriver drops as quickly as kereliuk updates as they cause problems. if there's a bug fixed then someone inevitably was accidently relying on that bug. 18:02:28 jgraham: do you still have people using firefox 47/old firefox driver? 18:02:36 juangj: yes about a quarter of them are still using the firefox driver 18:03:25 juangj: some people were waiting of geckodriver to implement. mostly it's people procrastinating. there are a lot of tests relying on pointer interact ability not being implemented. 18:03:41 AutomatedTester: moving on to sauce labs 18:04:17 titusfortner: i think most of the interop things i see are timing issues between how the DOM is rendered. i don't anything specific to the protocol that causes issues. most users swapped from firefox to chrome. 18:04:24 titusfortner: maybe that will move back with w3c, i'm not sure 18:04:35 juangj: i see people moving from firefox to chrome as they wanted to avoid the change. 18:04:54 titusfortner: a lot of people defaulted to firefox when running locally because it didn't require an extra download. 18:05:25 simonstewart: i think people find the upgrade process from legacy firefox/selenium to be tough. they change everything at once and they get burnt and blame geckodriver unfairly. 18:05:35 juangj: it's a bit daunting, there are some cases where you can't change only one thing at a time. 18:05:47 RRSAgent, make logs public 18:05:53 AutomatedTester: are there any other questions for sauce labs 18:06:35 AutomatedTester: mike since you're back, we have an implementation updates/how people are working. people have offered to create impl reports. what are the things required of this group to move forward? what will be expected? how do we make everyones life simpler 18:06:41 RRSAgent: make minutes 18:06:41 I have made the request to generate https://www.w3.org/2017/11/09-webdriver-minutes.html ato 18:06:57 MikeSmith: we need to evaluate our exit criteria and see how we are doing 18:07:00 Chair: AutomatedTester 18:07:04 MikeSmith: can we look at the exact language in that 18:07:38 rbyers: it's similar to other groups. every test must be passing in at least 2 places. 18:07:58 AutomatedTester: so there are a number of things that are failing at the moment or we need to fix our failures. 18:09:23 jgraham: if you look at the current impl report there are two classes of things you see. one is things that are unimplemented, you're not going to convince anyone that something without two implementations can go to rec. if the goal is to get to rec in the shortest time possible we should drop the things that aren't implemented. 18:10:00 jgraham: for the other things we have implementations but we have a strange situation such as some of the tests failing in iedriver not because of the tests but because iedriver is buggy. 18:10:56 https://w3c.github.io/webdriver/results/2017-10/html/all.html 18:11:07 jrossi: i agree, one thing we've done in other working groups in the second phase is the opportunity to provide comments. for pointer events we didn't have two tests passing because it was a browser bug but if that's the case then plh was okay with that. 18:11:29 https://w3c.github.io/webdriver/results/2017-10/html/less-than-2.html 18:11:52 AutomatedTester: i don't feel like we need to remove things to ship. 18:12:31 jgraham: it depends on what you want to happen. if you want to reach rec before the time it would take to implement those features. it's quite meaningless to do. you move them from the rec to the living doc. 18:12:41 https://w3c.github.io/webdriver/results/2017-10/html/complete-fails.html 18:13:02 jgraham: i agree aesthetically it's not pleasing but the reality is that we'll be gated on getting to rec on having those things impl'd. 18:13:27 JohnJansen has joined #webdriver 18:13:48 rbyers: we did that for chrome, moved things that didn't work out of spec into incubation 18:13:54 simonstewart: seems like it's mainly around alert handling 18:14:27 jgraham: there are issues with the report 18:14:37 simonstewart: we need to update our drop from wpt 18:15:12 ato: about user prompts it wouldn't be extremely hard to add to firefox but when it comes to returning web windows/frames the serialization of that when returning from execute script, we won't be able to do that in a reasonable time 18:15:29 simonstewart: sounds like we should yank execute script window handles from level 1 18:15:37 simonstewart: and leave alerts there 18:15:54 jgraham: if we do that we need to get commitments 18:16:04 simonstewart: agreed we need to chat with people setting priorities 18:16:23 ato: don't care either way as we have something that works but the safe call seems to be yanking from level 1 and put it in master 18:16:32 rbyers: you should always yank it and if someone implements bring it back 18:17:01 simonstewart: the user expectation around returning window id's from script isn't there. 18:17:05 simonstewart: prompts however are 18:17:20 titusfortner: different drivers implements that differently 18:17:24 simonstewart: they all do it 18:17:28 titusfortner: chrome doesn't 18:17:38 ato: if that is true than that puts us in a slightly different position 18:17:47 titusfortner: we have bugs around this 18:18:17 jrossi: one of the things we did in pointer events was amending the test results table to add in link to everybody's issue tracker to see what's failing 18:18:40 ato: you mean for making the report more valuable to plh? 18:18:53 jrossi: more in a way to track where the pain points are but it would also be helpful for reporting to plh 18:19:44 MikeSmith: ideally as far as test results go we don't want to see any red. right now superficially for anyone who doesn't know anything about webdriver won't be confident about those results as there is a ton of red there. you can explain individually why it's there or. there are two things we can do is either yank the things that aren't there and re-generate the results and go back to cr 18:19:55 MikeSmith: if we make substantive changes to the spec we have to go back to cr 18:20:09 MikeSmith: we could make the argument that removing things shouldn't require going back to cr 18:20:23 MikeSmith: we need to wait 4 weeks after publishing a draft for comments to come in 18:20:44 MikeSmith: when we remove features from the spec it invalidates previous reviews. when someone approves the cr based on old version they need a heads up on us removing features. 18:20:53 MikeSmith: in practice people may not care but it's more time 18:21:16 MikeSmith: we're out of time already, so we'll need to take more time anyways, it's just a matter of what we need to do 18:21:34 MikeSmith: we can remove those features and restart the cr with the new test results which may mean we get through cr fairly quickly and move on 18:21:42 simonstewart: we should have a convo around priority setting and find out 18:21:57 AutomatedTester: we remove it from the spec and move it into master, it seems silly to remove the tests and then regen the report. 18:22:11 MikeSmith: we can keep the tests but to generate the impl report we'll need to generate from a subset of the tests 18:22:37 jgraham: right that's trivial, keep a set of tests that we know apply to level 1 and filter the rest out 18:23:01 MikeSmith: right we just need to filter them out. if we have a few cases of red that's okay but we need the report overall to look good/green. 18:23:08 ato: for example ie11 has a bug that's okay? 18:23:31 MikeSmith: right we can have that ready to go but normally this is explained over the phone and as long as we're confident in that explanation we should be okay 18:23:50 jgraham: sounds like we should get the latest chromedriver into the impl report as it might add passing results for tests 18:24:07 kereliuk: at least publicly you can go to the chromedriver website and click a link 18:24:18 jgraham: someone should generate those results 18:24:23 rbyers: is it different from what we have on wpt.fyi 18:24:30 kereliuk: trying to think of what was released previously 18:24:43 jgraham: wpt.fyi downloads it for each run 18:24:57 Latest stable release: https://sites.google.com/a/chromium.org/chromedriver/downloads 18:24:58 MikeSmith: okay so as far as discussion with plh goes he said he can be available after lunch. he can be available at 1 18:25:04 Latest master: 18:25:14 MikeSmith: he has something at 3 so if not 1 then some time before 3 18:25:15 https://sites.google.com/a/chromium.org/chromedriver/chromedriver-canary 18:25:31 MikeSmith: it's 10:30 so we should break? 18:25:38 jgraham: why are we still here? 18:25:41 AutomatedTester: we'll be back at 11 18:25:48 RRSAgent: make minutes 18:25:48 I have made the request to generate https://www.w3.org/2017/11/09-webdriver-minutes.html AutomatedTester 18:25:55 amending earlier statement that “there are no tests using selenium” — this is not accurate as I misinterpreted the question. The vast majority of browser tests that we run use WebDriver, and virtually all of those tests use Selenium. There may be a handful of people attempting to use the WebDriver API directly but they’re negligible. 18:26:04 for whatever that's worth. 18:32:06 Hexcles has joined #webdriver 18:59:02 Hexcles has joined #webdriver 19:02:10 boazsender has joined #webdriver 19:05:01 soareschen has joined #webdriver 19:07:19 we're resuming 19:07:31 tboyles has joined #webdriver 19:07:32 brendyna has joined #webdriver 19:07:32 AutomatedTester: moving on, the next steps are to fix up the agenda and items that we want to discuss 19:07:38 https://www.w3.org/wiki/WebDriver/2017-TPAC-F2F 19:07:40 titusfortner has joined #webdriver 19:07:56 AutomatedTester: there's a whole bunch of things at the bottom that people would like to discuss at some point today 19:08:38 AutomatedTester: We're going through the topic bank and move them up to what we think are important and flesh those out 19:08:50 isobe has joined #webdriver 19:09:30 clmartin: can we move new tab/delete history up, they're not controversial 19:09:38 simonstewart: in an equally uncontroversial world, file upload 19:09:49 ato: just to make it clear to everyone, we're now talking about features that will make it into webdriver in level 2 19:10:03 ato: this will be stuff that if potentially agreed to will go into the master branch 19:10:25 JohnJansen: for clarification, the full path to the branch that has v1 is that a branch or a url? 19:10:29 jgraham: what's the question? 19:10:38 JohnJansen: i want to make sure i'm looking at the v1 version of the spec or the v2 version of the spec 19:10:39 https://github.com/w3c/webdriver/tree/level-1 19:11:00 clmartin: master is latest? 19:11:03 simonstewart: master is the living spec 19:11:16 jrossi: do you want to add to the v1 branch, change the title to say level 1? 19:11:26 ato: i have an action item to fix the url 19:11:35 action: ato fix the urls for the spec 19:11:51 AutomatedTester: computer problems :( 19:12:06 simonstewart: are you building Mozilla? 19:12:09 AutomatedTester: i might be :) 19:12:23 AutomatedTester: stopping from the top, copy/paste/selection 19:12:41 rbyers: are we still talking about the agenda? do we want to summarize what we're going to do with devtools 19:12:58 simonstewart: can we break these into things that are amendments, brand new features and amendments to existing features 19:13:08 simonstewart: as right now we're randomly cherry picking 19:13:25 jgraham: if rbyers is here for the moment to talk about the debug protocol we should do that 19:13:54 rbyers: we're talking WebVR at some point, would we want this group to discuss the bigger picture of test adoption requirements? 19:14:03 jgraham: let's prioritize that first then 19:14:12 AutomatedTester: we'll start with re-chartering and proposed debug protocol stuff 19:14:33 AutomatedTester: as part of when we started the work to move to pr, i created the draft for re-chartering this group for this work 19:14:44 AutomatedTester: one of the things i have suggested which used to be part of this group was how we do debug protocols 19:14:58 I’ve updated the agenda: https://www.w3.org/wiki/WebDriver/2017-TPAC-F2F#Thursday 19:15:07 AutomatedTester: wilhelm originally added it for the opera debug work and now I've added it for the cdp 19:15:14 Topic: Rechartering and proposed debug protocol standardisation 19:15:32 AutomatedTester: last night there was an informal chat on if we were to do this how it would look. the consensus was to remove it from the working group charter and move it to an incubator group and build it out that way 19:15:55 q+ to speak about rechartering 19:15:57 AutomatedTester: because while people agree that working towards a standard for the debug protocol is what we want, the process around what we want to do in a meaningful way isn't there yet 19:16:07 AutomatedTester: which is what's expected when trying to do things through consensus 19:16:20 Christian has joined #webdriver 19:16:21 AutomatedTester: from that point of view we'll be setting up an incubator group, working with rbyers and others to set this up 19:16:25 MikeSmith: by that you mean a community group? 19:16:27 AutomatedTester: yeah 19:16:56 rbyers: key thing i wanted to see is, we create community groups when we want to collaborate, and the goal is to have a place where we can discuss/share docs/etc. 19:17:18 auchenberg: should we go ahead and make a suggestion here that we create an incubator group and each vendor can say whether they support that? 19:17:41 ato: yes and mike will talk about this later but that the debug protocol won't be a part of the re-charter 19:22:57 q+ 19:23:18 q- 19:23:26 ack MikeSmith 19:23:26 MikeSmith, you wanted to speak about rechartering 19:23:32 rbyers: we see good engineering as being more important as it needs to come first before the process/legal stuff 19:23:39 rbyers: the DevTools team in particular wants us to focus on code 19:24:42 jgraham: there's a few things there, one is the debug protocol stuff which is unrelated to the existing webdriver work which there is agreement on that happening separately. and then the other is that mike is saying we could also move all of webdriver into a community group and not have a working group until later when ready to publish. i'm not clear on what the tradeoffs are there on whether we can still have meetings 19:24:49 MikeSmith: we can still have space for those at TPAC 19:25:03 ack jrossi 19:25:16 jgraham: my understanding is that the space is limited for that 19:25:27 MikeSmith: no it should be viable. jrossi has a question 19:25:34 jrossi: we'll need to re-charter 19:25:38 MikeSmith: no we just need to extend 19:25:56 jrossi: i view the webdriver work as very different from cdp. cdp is very nascent, webdriver is fairly mature from an adopted perspective. 19:26:04 q+ 19:26:11 q+ 19:26:37 jrossi: our perspective would be continue webdriver in a working group but the DevTools stuff on the other hand is a perfect example of what should be incubated 19:26:50 AutomatedTester: webdriver has goals to move forward with 19:26:52 q? 19:27:36 jgraham: now that there exists a spec and it's clear what the requirement is for the editing process, the group has now learned how to write a spec/tests, we can potentially focus on a few things that everyone has agreed to implement in the short term and publish a new rec more often 19:28:01 jgraham: if we believe we can move towards that model then it doesn't make sense to shut down the working group and then spin it up again. it just makes sense to publish stuff more often. personally i'd like to see it go in that direction 19:28:11 AutomatedTester: i'd like to see it go in that direction for webdriver 19:28:12 ack ato 19:28:19 AutomatedTester: ato 19:28:30 ato: what is the cost from Microsoft to move from a working group to a community group? 19:28:52 jrossi: any group we join requires a legal process, it's totally doable, but webdriver's scope/deliverables are fairly straightforward/rubber stamped 19:29:05 jrossi: if there was a good consensus we could make that happen 19:29:15 rbyers: if we do incubation in the wicg there's no additional cost to the user? 19:29:24 jrossi: there is 19:31:28 ack ato 19:31:29 ato: i think speaking for myself that over these 6 years there has been overhead in having a wg (working group) for webdriver and the value isn't clear to me. however i see jgraham's point that we now have the right information. so if we adopt a model where we can ship faster that seems reasonable. that said the wg model for webdriver has historically been important because we started with this not having all the browser vendors onboard. 6 19:31:29 years ago Microsoft/apple were very different so historically having the patent protection was important. if browser vendors are happy i'm okay to continue the current model, i just want this to move forward and have investment from everyone 19:31:32 ack auchenberg 19:31:34 AutomatedTester: auchenberg 19:31:49 q? 19:32:02 q+ 19:32:17 auchenberg: i'd like to separate the convos here. there's one about webdriver and it's future and one about cdp and it's future. there are a lot of people here for cdp incubation. my suggestion is we move the incubation work for cdp forward and then allow the webdriver work to continue after that. 19:32:25 AutomatedTester: so rbyers wants the vendors to agree 19:32:33 rbyers: i just want to see who want to work in the wicg 19:32:54 ato: i'd note this group doesn't have everyone who's interested in working in the wicg. we have a DevTools team and we don't want to speak for them. 19:33:01 rbyers: i just want to see who has interest 19:33:10 jgraham: the point is to get the official consent 19:33:38 brendyna: Microsoft agrees 19:33:40 Resolution: CDP is going into an incubator group/CG. There is sufficient support from vendors and independent parties. 19:33:43 rbyers: Google agrees 19:33:48 titusfortner: Sauce agrees 19:33:56 boazsender: Bocoup agrees 19:33:57 q+ boazsender 19:34:01 ack ato 19:34:08 rbyers: next step is get a repo created and continue the convo on an email thread 19:34:13 q- boazsender 19:34:21 JohnJansen: do community groups have chairs? 19:34:34 rbyers: no, wicg does but not per subset 19:34:40 brendyna: one last question, do we have Mozilla interested/ 19:34:51 AutomatedTester: i think so but since Harald isn't here I don't want to speak for him 19:35:01 AutomatedTester: the general consensus is yes but need to verify 19:35:05 auchenberg: any comment from apple? 19:35:11 brrian: i'd need to ask the DevTools team 19:35:20 AutomatedTester: fair, we got the two we needed and we can move forward 19:35:24 jgraham: we can move forward now 19:35:41 rbyers: second one was about the process for other groups to ... 19:35:47 ato: one second, can we have a resolution on what we're doing with this wg 19:35:54 JohnJansen: yeah 19:36:13 jgraham: it sounds like Microsoft want to keep publishing recs and that therefore means there has to be a wg 19:36:28 JohnJansen: we care about recs 19:36:38 RRSAgent: make minutes 19:36:38 I have made the request to generate https://www.w3.org/2017/11/09-webdriver-minutes.html AutomatedTester 19:36:47 jgraham: so does it make sense to continue the wg or drop out and spin something else up 19:37:15 JohnJansen: keep the working group, don't drop other things. we should extend the charter in a way that allows apple/Microsoft to continue their participation in a way that it's royalty free 19:37:33 AutomatedTester: are we happy to do the extension? Microsoft has agreed, Mozilla will, my sense is apple needs it 19:37:38 brrian: we need it 19:37:40 AutomatedTester: that's fine 19:37:54 jrossi: do we want to re-charter for what we do after webdriver 19:38:10 jgraham: MikeSmith what's the difference between extending and re-chartering? 19:38:31 MikeSmith: we need to extend first, then get to rec, then declare victory. that's separate from re-charter 19:38:48 MikeSmith: after we extend, if we're going to have another charter. we can't extend the same charter we've had for 6 years. 19:39:04 MikeSmith: i'd also say it's not a given that if we decide we want to re-charter, that the w3c will say we can re-charter 19:39:17 MikeSmith: we'll need the w3c to decide if it's something we want to re-charter for 19:39:44 MikeSmith: w3c will take into account if vendors want to continue, and if we do then that'll be take into account 19:39:59 AutomatedTester: how do we do webdriver extensions for other wg's to add to webdriver for testing 19:40:20 AutomatedTester: will it be better to have a wg for that scenario or will this fizzle out and hope you speak to the right people? how does that play out? 19:41:08 MikeSmith: it doesn't make any difference. e.g. in reality the technical group for html has been outside of the w3c so it's quite possible to have solid technical communication about work that isn't in the w3c. whether it helps across wg's i'm not sure it makes a difference. 19:41:37 Hexcles has joined #webdriver 19:41:45