21:34:01 RRSAgent has joined #webdriver 21:34:01 logging to http://www.w3.org/2015/10/25-webdriver-irc 21:34:26 rrsagent, this meeting spans midnight 22:00:16 Good morning, wilhelm 23:29:44 kurosawa has joined #webdriver 23:37:58 kurosawa_ has joined #webdriver 23:38:37 kurosawa_ has joined #webdriver 23:41:13 JohnJansen has joined #webdriver 23:41:23 zqzhang_ has joined #webdriver 23:42:48 JohnJansen has joined #webdriver 23:46:05 wilhelm_: good morningーI'm around on IRC if/when needed 23:46:19 wilhelm has joined #webdriver 23:46:59 sam has joined #webdriver 23:51:40 Meeting: Browser testing & tools WG, TPAC 23:51:51 Agenda: https://www.w3.org/wiki/WebDriver/2015-TPAC-F2F 23:52:01 RRSAgent, draft minutes 23:52:01 I have made the request to generate http://www.w3.org/2015/10/25-webdriver-minutes.html wilhelm_ 23:52:10 RRSAgent, make log public 23:53:29 simonstewart has joined #webdriver 23:55:43 juangj has joined #webdriver 23:56:06 jinbyung has joined #webdriver 23:57:19 simonstewart has joined #webdriver 00:02:22 juangj has joined #webdriver 00:05:40 juangj has joined #webdriver 00:08:40 present+ 00:08:51 present+ JohnJansen 00:08:55 present+ Andreas Tolfsen 00:08:58 present+ jgraham 00:08:59 present+ David Burns 00:09:00 present+ juangj 00:09:01 present+ Sam Uong 00:09:02 present+ Simon Stewart 00:09:21 RSSAgent, make minutes 00:09:24 RRSAgent, draft minutes 00:09:24 I have made the request to generate http://www.w3.org/2015/10/25-webdriver-minutes.html wilhelm 00:09:39 kurosawa has joined #webdriver 00:10:00 jimevans has joined #webdriver 00:10:14 Present+ Wilhelm 00:10:37 present+ ato 00:10:59 present+ DavidBurns 00:11:21 RRSAgent, draft minutes 00:11:21 I have made the request to generate http://www.w3.org/2015/10/25-webdriver-minutes.html ato 00:11:28 Agenda: https://www.w3.org/wiki/WebDriver/2015-TPAC-F2F 00:11:36 present+ SamUong 00:11:57 scribe: AutomatedTester 00:12:19 RSSAgent, draft minutes 00:14:09 simonstewart has joined #webdriver 00:14:20 https://www.w3.org/wiki/WebDriver/2015-TPAC-F2F 00:14:46 Scribe: wilhelm 00:14:52 Topic: State of the union 00:15:19 AutomatedTester: The main things changed in the spec since the last meeting is that we have proper, prescriptive langauge in the spec now. 00:15:22 AutomatedTester: It's a lot better. 00:15:39 AutomatedTester: The general gist has not changed, just the format, so that you can actually implement things. 00:15:43 AutomatedTester: ato has done a big chunk of the work. 00:16:00 AutomatedTester: I believe our charter ends at the end of this year. We need a final push to finish the last little bits done. 00:16:05 AutomatedTester: So we can move forward to REC. 00:16:32 AutomatedTester: THat should be the main part of our discussion today and tomorrow. 00:17:02 JohnJansen: THe test suite is an important point to get to REC. 00:17:17 ato: We can also start the REC process before the test suite is finished. 00:17:40 AutomatedTester: We have three diverging implementations, and need the test suite to rein things back in. 00:17:57 AutomatedTester: We can move things about on the agenda. 00:18:17 Topic: Agenda review 00:19:01 sam: I put the Bluetooth in the agenda. Interest from platform implementors. 00:19:25 sam: Jeff from GOogle is chairing the Bluetooth work. 00:19:37 sam: I don't know if this is for the first level of the spec. 00:19:46 simonstewart: We have places in the spec for extensions. 00:20:28 sam: They need a test suite for this. COuld be an extension. 00:21:01 ato: One of the things we want to achieve is to allow other platform techs to make their specs testable. 00:21:25 ato: We talked about mobile related things, punting most of them until we have the core spec finished. 00:21:41 ato: Re: bluetooth, USB, someone should come up with a strawman proposal. 00:21:50 jgraham: It would be good if they come here. 00:22:25 sam: Jeff can come in tomorrow. 00:23:01 sam: This could start as a vendor-specific feature. 00:23:13 https://w3c.github.io/webdriver/webdriver-spec.html#protocol-extensions 00:23:14 AutomatedTester: There is an example in your code for launching web apps. 00:23:30 ato: We decided to punt other things: Shadow DOM, logging. 00:24:00 jgraham: FOr the agenda for tomorrow: What future work is there for this group? W3C process, charter. 00:24:23 ato: I added an agenda item: window focus. DOM events queued. 00:25:28 JohnJansen: Accessibilty testing with WebDriver. 00:25:49 JohnJansen: Accessibility WG is meeting nearby. 00:26:33 simonstewart: Every year we have a discussion about this. There is overlap. 00:27:03 AutomatedTester: We have invited them over previously. 00:28:09 ato: I think it makes sense to talk about the level 2 stuff to avoid conflict with level 1. 00:28:32 JohnJansen: Should there be a v2 spec draft? 00:28:41 jgraham: I'm very dubious about that. 00:28:57 AutomatedTester: There is a top-level bug you can raise bugs against. 00:29:20 ato: We also haven't talked about how to do extensions to the spec later. One spec, or multiple? Per feature? 00:29:23 https://www.w3.org/Bugs/Public/show_bug.cgi?id=24121 is the L2 Bug 00:30:47 simonstewart: We should talk about concrete steps to get to LC. 00:31:22 (Discussion about specific screenshot issue, wrt. scrolling.) 00:32:09 JohnJansen: Our screenshot implementation was based off Chrome, many complaints. 00:32:26 JohnJansen: We talked about an optional parameter. 00:32:46 AutomatedTester: There's also screenshot of element. Should we scroll to the element? 00:35:45 RRSAgent, make minutes 00:35:45 I have made the request to generate http://www.w3.org/2015/10/25-webdriver-minutes.html MikeSmith 00:36:41 https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=20860&hide_resolved=1 00:36:58 Topic: Open issues 00:37:07 AutomatedTester: Should we skip issues on click, etc.? 00:37:23 https://www.w3.org/Bugs/Public/show_bug.cgi?id=20947 00:37:23 https://www.w3.org/Bugs/Public/show_bug.cgi?id=20947 00:37:25 https://www.w3.org/Bugs/Public/show_bug.cgi?id=20947 00:38:25 simonstewart: Do as I say: Don't wait. Fire away the event. 00:38:51 simonstewart: 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. 00:39:07 simonstewart: Super-racy condition. 00:39:08 simonstewart: Because page load hasn't started. 00:39:26 jgraham: This is not super easy. 00:39:31 simonstewart: It is. 00:39:34 jgraham: With a short gap, you can still lose. 00:40:21 ato: Why can't we do something like: add mutation observer, listens to the document.. 00:40:25 simonstewart: Onbubble may be cancelled. WHere would you put it? 00:40:39 jgraham: It seems very unsatisfactory to wait an arbitrary amount of time. 00:40:59 jgraham: Leverage that the person using the API probably knows what to expect. 00:41:30 simonstewart: Test authors often don't understand implicit waits. 00:42:23 simonstewart: (Describing how this has been solved in different implementations.) 00:42:37 wilhelm has joined #webdriver 00:43:03 jgraham: Wait for the event loop to be processed. 00:43:17 jgraham: Event handler for that click event? 00:43:35 jgraham: Let one cycle of the event loop run or wait for the click handler to run. 00:44:13 ato: Sounds like a good solution. 00:45:04 jgraham: (Comments on the bug.) 00:45:13 https://www.w3.org/Bugs/Public/show_bug.cgi?id=21184 00:46:26 ato: (Reads the bug description.) 00:48:18 Scribe: juangj 00:48:43 (some discussion happened while wifi was dead) 00:48:54 wilhelm__ has joined #webdriver 00:48:57 simonstewart: should click in the middle of the first visible client rect 00:50:32 johnjansen: center of client rect may be obscured 00:50:32 . 00:50:35 wilhelm__ has joined #webdriver 00:50:44 simonste_ has joined #webdriver 00:50:52 https://irccloud.mozilla.com/file/HblZkA5l/wilhelms.png 00:51:07 samuong: there’s a special case [in chromedriver] for tags, and for circles etc. we try to figure out the center 00:51:21 Present+ Simon Stewart 00:51:45 samuong: i think this is a special case because of the way chrome gives you the clientrects for these elements? 00:52:02 not quite sure how firefox does it 00:52:11 ato: do you have a test case for this? 00:52:13 samuong: i’ll make one 00:52:49 ACTION: samuong make a test case for element clicking 00:52:55 RRSAgent, draft 00:52:55 I'm logging. I don't understand 'draft', ato. Try /msg RRSAgent help 00:53:00 RRSAgent, draft minutes 00:53:00 I have made the request to generate http://www.w3.org/2015/10/25-webdriver-minutes.html wilhelm__ 00:53:31 https://www.w3.org/Bugs/Public/show_bug.cgi?id=22653 - resolved already 00:53:58 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23868 00:54:49 simonstewart: (explains original reasoning for this) 00:55:03 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23876 00:55:04 simonstewart: i’m happy to not do it that way 00:55:09 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23876 00:55:47 automatedtester: yes, should probably special case this. it comes up regularly in #selenium IRC 00:56:31 ato: we’ve already reached a conclusion on this (comment 1) and it just hasn’t made it into the spec yet 00:57:07 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 00:57:53 https://www.w3.org/Bugs/Public/show_bug.cgi?id=24794 00:59:01 (discussion about whether this text even still exists in the spec — it doesn’t) 00:59:09 the original motivation was that some browsers couldn’t do HTTPS 00:59:30 https://www.w3.org/Bugs/Public/show_bug.cgi?id=24816 00:59:58 sam has joined #webdriver 01:00:33 ato: (reading the current text on alerts in the spec) 01:00:55 simonstewart: so you’re saying that the “are you sure you want to navigate away” prompt gets implicitly dismissed? 01:01:26 ato: you can get an ‘unexpected alert’ 01:01:38 jgraham: as far as i can tell, this text doesn’t actually specify anything 01:02:03 jgraham: there are two cases. case where you do an explicit ‘get’, and the case where you do something else that causes navigation to happen 01:02:25 simonstewart: should handle the same way; if the dialog pops up, should be handled the same way by the prompt handler 01:03:46 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 01:04:14 jgraham: then i dont understand the sentence that says the prompts are dismissed implicitly on navigation 01:04:29 jgraham: what you’re saying you want [about no special casing of this alert] and what the spec says are different 01:05:00 jgraham: 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 01:05:51 ato: problem here is we’re trying to specify a blocking api but some of the things here happen asynchronously 01:06:46 jgraham: not every endpoint can cause an alert. just navigation, executescript, … 01:07:02 simonstewart: you could imagine some bastard doing some sort of setTimeout thing to cause an alert when getting cookies 01:07:09 jgraham: it’s specified that you have direct access to cookies 01:07:30 ato: does that mean we need to add a list of the commands [that can cause alerts]? 01:07:59 jgraham: interactions, get, executescript, … back/forwards … ok this is a bit of a nightmare 01:08:35 kurosawa has joined #webdriver 01:08:47 ato: the html5 on this topic is interesting. ‘alerts’ and ‘user prompts’ are not synonymous 01:09:18 ato: this also handles the old IE thing, showModalDialog 01:09:35 JohnJansen: edge has this new thing too, about whether you want to switch apps 01:09:59 jgraham: so the conclusion here is that there’s more work needed 01:11:19 https://www.w3.org/Bugs/Public/show_bug.cgi?id=24818 01:12:03 ato: tempted to just resolve this bug because we haven’t really started working on it 01:12:09 ato: not sure why he wants to remove this 01:12:28 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 01:13:36 samuong: can’t find the word “alias” in the spec; it looks like that part of the bug is no longer true 01:13:46 https://www.w3.org/Bugs/Public/show_bug.cgi?id=24828 01:14:17 https://www.w3.org/Bugs/Public/show_bug.cgi?id=24832 01:15:33 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 01:15:45 jgraham: surely we didn’t mean to put a requirement in the appendix 01:17:03 simonstewart: do we need this section? [appendix C on “security”] 01:17:13 jgraham: i’m very unhappy about this saying there “must be a configuration option" 01:17:47 jgraham: would like a word that means “should” but isn’t “SHOULD” 01:18:03 jgraham: want to rewrite this to be non-normative, purely informative text 01:20:12 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 01:20:33 simonstewart: didn’t this section used to say something about fingerprinting? 01:21:02 (yes, it’s in sec. 3 now; “webdriver-active flag”) 01:21:26 refreshment break 01:21:33 back at :45 01:42:40 Kang has joined #webdriver 01:44:11 kurosawa has joined #webdriver 01:44:16 juangj has joined #webdriver 01:45:57 sam has joined #webdriver 01:46:46 RRSAgent: draft minutes 01:46:46 I have made the request to generate http://www.w3.org/2015/10/25-webdriver-minutes.html juangj 01:49:27 wilhelm has joined #webdriver 01:50:09 sam: returning to that thing, it looks like that’s a chrome-specific thing that other browser don’t need to worry about 01:50:40 scribe: sam 01:51:11 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25012 01:52:12 simon: this is used by people who want to set timeouts back to an original value 01:52:34 james: we should have a getter for every setter; write-only is not good 01:54:27 nsakai has joined #webdriver 01:55:19 andreas: useful for marionette users when using a context manager, and restoring to the original state 01:57:38 andreas: some users also have multiple local ends controlling a single browser session 01:59:10 simon: i understand the symmetry arguent (getters for all setters), but no one has ever asked for this 01:59:19 david: it's a frequent request 02:01:12 johnjansen: we resolved this last time, and decided to handle it in level 2 02:07:36 kiyoung has joined #WEBDRIVER 02:08:42 simon: we can add it in level 1 02:09:45 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25058 02:10:21 simon: we should better define spaces, and include unicode spaces 02:11:23 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25106 02:11:38 Resolution: We’ll resolve it as a duplicate. 02:14:00 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25285 02:16:23 simon: booleans need to be handled properly, there are lots of tests out there that require it 02:16:41 james: attributes need to be returned as a list, so this is going to make it difficult to separate null/false 02:17:16 simon: browser vendors could be responsible for keeping their drivers up-to-date 02:19:08 james: even for browser vendors, it's difficult to keep track of what is implemented and what isn't 02:20:35 james: it'll be confusing when attributes are set to the empty string, or something else that's falsy 02:22:40 simon: we can think about renaming this later, but if you want the html attribute call the javascript, otherwise the existing way works ok 02:25:18 simon and james agree that remote ends should keep track of which attributes are boolean 02:29:13 david: with web components we don't have element attributes and idl attributes in sync 02:29:56 andreas: e.g. a custom input element could have its own disabled attribute 02:31:07 james: we don't have a list of boolean attributes for custom elements 02:31:33 simon: it's worse to break existing tests, so we should maintain the existing behavior 02:32:32 andreas: we could fix this by calling get property, then get attribute 02:32:50 simon: this would be grossly inefficient for use cases like sauce labs' 02:34:00 sam: I’m Andreas by the way. 02:36:23 resolution: leave it the way it is 02:39:34 Scribe: juangj 02:41:24 scribe: sam 02:42:36 action: add note to explain why we're returning a string "true" in section 12.3 02:42:54 ^ ato 02:43:33 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25293 02:43:34 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25317 02:47:45 resolution: punt this to level 2 02:47:48 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25306 02:48:45 https://bugzilla.mozilla.org/show_bug.cgi?id=883555 02:49:16 james: bug title differs from link in bug 02:49:26 james: if a string has bidi text, webdriver shouldn't modify that 02:53:25 resolution: bug is invalid, we shouldn't strip these out 02:53:37 https://bugzilla.mozilla.org/show_bug.cgi?id=883555 02:53:43 http://www.w3.org/TR/findtext/ 02:58:15 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25307 03:06:38 resolution: someone needs to define "effective css whitespace" 03:06:47 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25308 03:06:49 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25308 03:13:34 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 03:13:45 resolution: close the bug and have a note 03:14:59 https://w3c.github.io/webdriver/webdriver-spec.html#dfn-json-clone 03:15:18 http://rocallahan.github.io/innerText-spec/index.html 03:15:35 ^ this doc says that innerText will handle text transforms 03:15:39 james: this might require firefox nightly 03:20:05 simon: ideally we would return what the user sees when getting the visible text, but currently there is no good way to do this 03:20:19 simon: we can implement this when a better method is available 03:22:50 wilhelm: firefox, chrome, edge implement innerText differently in terms of text transforms 03:26:32 https://drafts.csswg.org/css-text/#text-transform-property 03:29:04 simon: we shouldn't be breaking existing tests by changing this 03:29:40 james: someone should go through the spec for innerText and webdriver and finding out what makes a difference here 03:29:49 johnjansen: this is something that css/html should be doing 03:31:07 Test case for copy and paste: https://jsbin.com/sigoxopamo/edit?html,output 03:32:54 action: run the selenium test suite using roc's innerText and see how many fail 03:33:27 http://rocallahan.github.io/innerText-spec/index.html 03:33:29 reminder: http://rocallahan.github.io/innerText-spec/index.html 03:34:01 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25418 03:35:55 This is what the spec says about extension commands: https://w3c.github.io/webdriver/webdriver-spec.html#protocol-extensions 03:38:39 webdriver doesnt' have the same problems as css vendor prefixes, so this might not apply 03:41:01 resolution: this doesn't need to change 03:41:26 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25678 03:41:47 jason: this is gone from the spec now, and there's new text about focus not being relevant 03:42:11 http://www.w3.org/TR/html5/editing.html#focus 03:42:29 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25682 03:42:41 resolution: close 25678 03:43:20 https://www.w3.org/Bugs/Public/show_bug.cgi?id=26031 03:44:26 26031 is a dupe 03:44:41 https://www.w3.org/Bugs/Public/show_bug.cgi?id=26137 03:44:59 james: i've fixed this, will close 03:45:24 https://www.w3.org/Bugs/Public/show_bug.cgi?id=26266 03:45:36 james: this is out of scope, move to level 2 03:47:45 https://www.w3.org/Bugs/Public/show_bug.cgi?id=26287 03:48:02 use case is doing a file transfer when local and remote ends are on separate hosts 03:49:56 simon: the remote driver already does something like this 03:50:17 resolution: document this in the spec 03:52:43 https://www.w3.org/Bugs/Public/show_bug.cgi?id=26900 03:54:21 https://www.w3.org/Bugs/Public/show_bug.cgi?id=27244 03:54:39 this isn't really doable, e.g. for the back command shortcut 03:54:55 in chrome on mac, it's cmd+leftarrow, on linux/windows it's alt+leftarrow 03:54:58 resolution: wontfix 03:55:22 https://www.w3.org/Bugs/Public/show_bug.cgi?id=27658 03:55:45 https://www.w3.org/Bugs/Public/show_bug.cgi?id=27662 03:57:02 https://www.w3.org/Bugs/Public/show_bug.cgi?id=27664 03:58:31 this hasn't been rewritten yet, so we'll discuss once this section has been rewritten 04:23:10 kurosawa has joined #webdriver 04:43:05 zqzhang_ has joined #webdriver 04:59:15 kimwooglae has joined #webdriver 05:00:05 sam_ has joined #webdriver 05:06:39 simonstewart has joined #webdriver 05:11:14 JohnJansen has joined #webdriver 05:11:39 kimwooglae has joined #webdriver 05:16:15 returned from Lunch 05:16:15 wilhelm has joined #webdriver 05:17:10 resolution: the coffee here is bad 05:17:35 scribe: juangj 05:20:12 https://www.w3.org/Bugs/Public/show_bug.cgi?id=27665 05:20:42 resolution: 27665 is out of scope; you should ask for the input devices you want in desired caps 05:22:03 https://www.w3.org/Bugs/Public/show_bug.cgi?id=28002 05:22:50 simonstewart: what you should do, is if you can’t start another session, just don’t start a session and return an error 05:23:23 jgraham: there’s an implementation-dependent maximum, which for most endpoint nodes is 1 05:23:31 simonstewart: why is this relevant? 05:24:33 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 05:24:41 simonstewart: there’s already a “session not created” error 05:25:11 ato: that’s not implementable. you’re saying just to return that error if anything bad happens 05:25:25 jgraham: specifying this behavior makes the spec more explicit 05:26:02 ato: this is not irrelevant; it’s a concrete use case that we had to implement for marionette 05:26:18 simonstewart: what about browsers that support multiple users 05:26:41 jgraham: it doesn’t make sense to have two simultaneous sessions because of the amount of global state in a browser 05:27:00 simonstewart: not going to argue but it’s pointless language 05:27:16 (resolved fixed) 05:27:23 https://www.w3.org/Bugs/Public/show_bug.cgi?id=28143 05:27:26 https://www.w3.org/Bugs/Public/show_bug.cgi?id=28143 05:27:48 https://www.w3.org/Bugs/Public/show_bug.cgi?id=28194 05:28:53 https://www.w3.org/Bugs/Public/show_bug.cgi?id=28195 05:29:27 some browsers behave differently if you give a valid selector and nothing is matched, vs. if you give a malformed selector 05:29:39 simonstewart: said that thing ^ 05:31:25 https://www.w3.org/Bugs/Public/show_bug.cgi?id=28407 05:31:54 ato: yes, it’s possible to have an interactable element that is obscured by another element 05:32:49 jgraham: it’s still possible to focus an element if you can’t click on it 05:33:06 simonstewart: keyboard actions still make sense, mouse not so much 05:33:38 jgraham: this is still a question about visibility so let’s skip it now 05:34:16 https://www.w3.org/Bugs/Public/show_bug.cgi?id=28746 05:35:40 jgraham: what the spec is trying to say is, “do what you think is right”, but you can’t really specify this in detail 05:35:56 jgraham: resize the window and try to make it this size 05:36:09 simonstewart: usually you want to view the webpage with a certain size viewport 05:36:41 jgraham: including the chrome is what webdriver has historically done 05:37:34 jgraham: 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 05:38:25 https://www.w3.org/Bugs/Public/show_bug.cgi?id=28754 05:39:08 JohnJansen: the text here is just missing an “else” 05:40:19 ato: i think i fixed this already with a PR 05:40:55 https://www.w3.org/Bugs/Public/show_bug.cgi?id=28756 05:41:15 jgraham: this is about findElement so it’s probably still valid as we’ve yet to rewrite that section 05:42:20 https://www.w3.org/Bugs/Public/show_bug.cgi?id=28760 05:43:28 JohnJansen: the param would be optional and default to ‘click' 05:43:33 sam_: even on a mobile phone? 05:44:22 should be browser-dependent? 05:44:37 JohnJansen: browser doesn’t know if it’s on a touch device 05:45:33 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 05:45:36 AutomatedTester: not sure what chrome does 05:46:12 JohnJansen: on a laptop like [his], you can use keyboard and touch pretty interchangeably 05:46:26 sam_: mac chrome is probably the only one where touch doesn’t work in a desktop environment 05:46:55 sam_: chrome will generally try to do a tap 05:47:16 jgraham: that makes sense — if you explicitly ask for a tap, the browser should try to do a tap 05:47:40 simonstewart: general agreement with john/the bug) 05:48:04 simonstewart: and if you ask for a ‘click(“touch”)’ and that’s not supported, do what i mean 05:49:00 resolution: don’t spec “tap()”. spec click with an optional input source, e.g., “click(‘touch’)”, and if omitted, use the platform default 05:49:12 AutomatedTester: where does the platform default come from? that needs to be specified somewhere 05:49:50 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 05:50:13 I know. Ask me. It's awesome. 05:51:52 https://www.w3.org/Bugs/Public/show_bug.cgi?id=28802 05:51:57 simonstewart: acknowledged. punt it. 05:52:13 simonstewart: nobody implements it right now… well, firefox does because salesforce added it…? 05:52:23 (bug moved to level 2) 05:52:43 JohnJansen: https://w3c.github.io/webdriver/webdriver-spec.html#dfn-scrolled-into-view 05:53:16 https://www.w3.org/Bugs/Public/show_bug.cgi?id=28968 05:53:16 https://www.w3.org/Bugs/Public/show_bug.cgi?id=28968 05:55:32 https://www.w3.org/Bugs/Public/show_bug.cgi?id=29054 05:55:39 all: ….. yep 05:56:42 https://www.w3.org/Bugs/Public/show_bug.cgi?id=29070 05:57:05 all: ok, but why is this even called “sendKeys” instead of “keys” 05:57:22 sam_: isn’t it called “value” in the open source protocol? 05:57:48 (yes, it is) 05:58:12 simonstewart: the reason the API is named “Send Keys" is because you’re emulating keyboard input 05:58:31 simonstewart: ...and also because that was the name of the win32 api 05:59:09 all-lowercase is fine 05:59:18 simonstewart: the other option is to specify that URLs are case-insensitive 05:59:21 jgraham: noooo 05:59:41 ato: ALL CAPS! “SEND KEYS! DO WHAT I MEAN!” 06:00:49 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 06:01:17 jgraham: “screenshot” and “fullscreen” are one word 06:01:36 resolution: just leave “sendKeys” as camelCase, because that’s easier 06:02:51 https://www.w3.org/Bugs/Public/show_bug.cgi?id=29168 06:03:59 JohnJansen: this might be because of a security issue, where you don’t want to divulge the actual reason for the error 06:04:27 simonstewart: could be “unsupported operation” 06:05:38 JohnJansen: not sure that you always can know for sure that it’s an ssl error 06:05:44 jgraham: surely the browser knows 06:05:55 ato: isn’t “unknown error” really unhelpful to users? 06:06:00 jgraham: should probably coin a new error code for this 06:06:36 JohnJansen: not positive that browser knows for sure — it can know that it can’t authenticate but it might not know the exact reason 06:06:50 jgraham: it must know because it can pop up a dialog explaining what happened 06:07:25 jgraham: 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 06:08:18 simonstewart: defining an error code for every possible browser-specific error screen isn’t a good path forward 06:08:23 ato: also that’s not standardized 06:09:47 ato: 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 06:09:55 jgraham: but you should still try to return an informative error message 06:10:11 ato: should we have some text about the general purpose of “unknown error” 06:11:59