08:54:47 <RRSAgent> RRSAgent has joined #webdriver
08:54:47 <RRSAgent> logging to http://www.w3.org/2016/09/20-webdriver-irc
08:54:52 <ato> RRSAgent: please listen
08:54:58 <ato> Meeting: WebDriver F2F TPAC 20 September 2016
08:55:03 <ato> Chair: AutomatedTester
08:55:06 <ato> Agenda: https://www.w3.org/wiki/WebDriver/2016-TPAC-F2F
08:55:10 <ato> RRSAgent: please draft the minutes
08:55:10 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/20-webdriver-minutes.html ato
08:56:04 <mikepie_> mikepie_ has joined #webdriver
08:56:06 <ato> Scribe: ato
08:56:13 <ato> Scribe: Andreas Tolfsen
08:56:15 <ato> ScribeNick: ato
08:56:36 <ato> Topic: W3C process and moving towards Rec
08:56:48 <ato> plh: There have been changes to the process.
08:56:55 <ato> plh: There is a lot of leeway.
08:57:21 <ato> plh: Please don’t ask me what the process is, but ask me what you want to do.
08:57:38 <ato> plh: Tell me what you want to do, and I will try to make the process getting there as pain-less as possible.
08:58:09 <ato> AutomatedTester: We’re quite confident that the spec will be done by March.
08:58:16 <ato> AutomatedTester: We’re more unsure where implementations will be.
08:58:29 <ato> AutomatedTester: As we implement things, we will find bugs. There will be bugs everywhere.
08:58:34 <ato> AutomatedTester: What would happen in that situatioN?
08:58:49 <ato> AutomatedTester: Obviously we can apply for an extension, which hopefully wouldn’t be that much of an issue.
08:58:57 <ato> plh: Depends how many times you’ve applied for an extension.
08:59:02 <ato> simonstewart: Many.
08:59:08 <ato> plh: That may be a problem.
08:59:18 <ato> AutomatedTester: The specification seems to go into an immutable state.
08:59:23 <ato> AutomatedTester: What is the process for an errata?
08:59:38 <ato> plh: Don’t move to Rec before you have a good answer to how you are going to maintain it.
08:59:57 <ato> plh: Figure out how you will do that first, please.
09:00:19 <ato> plh: You should already publish your draft for your next version before you mvoe to Rec.
09:00:31 <ato> plh: We want to avoid that specs are unmaintained.
09:00:43 <ato> plh: We want you to have a draft for the next version already, before you move to Rec.
09:00:51 <ato> plh: Version links, completely broken.
09:01:44 <ato> AutomatedTester: It’s easy iterating over what we have in Github.
09:01:49 <ato> plh: That’s what I expect. For you to continue iterating.
09:02:09 <ato> plh: Should you continue as an incubator? [???]
09:04:32 <ato> plh: Please continue maintaining your GitHub repo.
09:04:42 <AutomatedTester> present+ AutomatedTester
09:05:27 <ato> plh: Depending on whether your changes are substantive or not, you can push to rec every month.
09:05:32 <ato> plh: People will think you are crazy, but you can.
09:06:14 <ato> plh: What kind of guarantees do you want to provide the world about your API? Also for implementors.
09:07:50 <ato> ato: I don’t think anyone is suggesting we will push API changes to a new version of the Rec.
09:08:12 <ato> plh: No, but if you find a security issue in your spec, we will need to update the spec.
09:08:24 <simonstewart> simonstewart has joined #webdriver
09:08:56 <ato> AutomatedTester: Say we got to the point where we feel our specification is ready, but we are waiting for implementors to implement it.
09:09:00 <ato> AutomatedTester: And our charter expires.
09:09:02 <ato> AutomatedTester: What happens?
09:09:32 <ato> plh: Implementors want guarantees about stability of API.
09:09:41 <ato> plh: The director doesn’t expect things to be perfect.
09:10:00 <ato> plh: He expect it to be good enough.
09:10:11 <jgraham> 
09:10:49 <ato> plh: Most WG develop test suites.
09:10:53 <ato> plh: To give reassurance.
09:11:16 <ato> plh: How many tests to write? I don’t know.
09:12:34 <ato> AutomatedTester: Not all vendors are running WPT.
09:13:27 <ato> AutomatedTester: Even within Mozilla we don’t run the WebDriver spec tests.
09:14:08 <ato> plh: I thought the goal of WebDriver was to get past that.
09:14:31 <ato> AutomatedTester: We have a test suite that is divergent from the spec.
09:14:32 <plh_> plh_ has joined #webdriver
09:14:33 <ato> ato: That is not the case…
09:15:01 <ato> AutomatedTester: Potentially we get to a point where our test suite is ready, we have this divergent test suite, and we’re fixing a more spec-based test suite.
09:15:36 <ato> plh: Meaning that you’re confident you have to conforming implementations?
09:15:50 <ato> AutomatedTester: Well that’s what I mean. How do we know?
09:16:29 <ato> AutomatedTester: We can use the Selenium project’s test suite.
09:17:03 <ato> jgraham: I think from this point of view the Selenium test suite is irrelevant.
09:17:25 <ato> jgraham: I understand that there are issues running the tests in CI
09:17:57 <ato> jgraham: But if you think pushing the specification to Rec is important, you need to push internally in your company to run those tests.
09:18:11 <ato> plh: You don’t need to run it in CI.
09:18:15 <ato> AutomatedTester: No but if you want to prove it…
09:18:57 <ato> plh: Do you know what you’re missing?
09:19:05 <ato> jgraham: We’re missing _the_ test suite.
09:19:15 <ato> plh: I thought you had some test.
09:19:33 <ato> jgraham: We did, but they were imported from Selenium and were incorrect and have been removed.
09:19:47 <ato> jgraham: There’s now no infrastructure blocker for someone going in an writing tests for this.
09:19:52 <ato> jgraham: The question is just people doing it.
09:20:30 <ato> jgraham: There are people in this room that want to keep the March deadline, and I hope they are stepping up to the task of writing tests before that time.
09:20:47 <ato> JohnJansen: Yes, I like having a deadline. That forces us to be active.
09:22:10 <ato> AutomatedTester: I don’t think we need any W3C resources.
09:22:21 <ato> plh_: W3C wants to help. WebDriver is important.
09:23:00 <ato> jgraham: For Mozilla, there are a series of technical steps we need to take to make it possible to run these tests in our CI.
09:23:42 <AutomatedTester> judg3dr3ddb34r1234
09:23:42 <ato> jgraham: It will then, as we do implementation, we will then fill out the test suite.
09:23:49 <AutomatedTester> doh
09:24:08 <ato> plh_: But you can’t expect this to happen organically.
09:25:21 <ato> AutomatedTester: I can start splitting out the specification in parts that need support.
09:25:36 <ato> plh_: You need to find out where the gaps are in your specification.
09:26:11 <ato> Action: AutomatedTester to create a project plan for tests
09:26:52 <ato> plh_: We can provide you with a generic testing plan.
09:27:01 <sam_u> sam_u has joined #webdriver
09:27:02 <ato> plh_: It’s not written anywhere either.
09:27:07 <ato> AutomatedTester: I don’t think we need that.
09:27:28 <ato> AutomatedTester: We need people not to step on each others’ toes.
09:27:46 <ato> AutomatedTester: It’s always possible hire contractors.
09:28:04 <mikepie> mikepie has joined #webdriver
09:28:49 <JohnJansen> JohnJansen has joined #webdriver
09:28:55 <JohnJansen> present+ JohnJansen
09:29:13 <ato> RRSAgent: please draft minutes
09:29:13 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/20-webdriver-minutes.html ato
09:29:15 <simonstewart> present+ simonstewart
09:30:26 <ato> JohnJansen: You want to make sure that everyone is looking at the proper version.
09:30:41 <ato> plh_: Yes, and the “proper” version is different to different people.
09:30:49 <ato> plh_: There is no single answer.
09:32:31 <ato> plh_: Are you in CR?
09:32:34 <ato> JohnJansen: No.
09:32:43 <ato> AutomatedTester: We have two major things that are being landed at the moment.
09:33:07 <ato> AutomatedTester: Actions and changes to New Session, and there might be one or two things that have come out of the last few days.
09:33:12 <ato> plh_: Give me a time estimate.
09:33:27 <ato> jgraham: MikeSmith said you try to stay in CR for as little time as possible.
09:33:50 <plh_> plh_ has joined #webdriver
09:34:09 <sam_u> sam_u has joined #webdriver
09:34:18 <ato> plh_: We need _reasonable_ amount of time to review the document.
09:34:25 <ato> AutomatedTester: I’ll pull a date out of my head. January.
09:35:08 <ato> plh_: Who is it relevant to? Who do we ask?
09:35:14 <ato> plh_: Who needs to read this in CR?
09:35:18 <ato> AutomatedTester: I don’t know.
09:35:35 <JohnJansen> JohnJansen has joined #webdriver
09:35:37 <ato> AutomatedTester: We’re not changing JS APIs.
09:35:39 <simonstewart> simonstewart has joined #webdriver
09:37:08 <ato> plh_: We want the review to discover serious issues with your spec. Like if certain groups or people can’t use it.
09:37:58 <ato> AutomatedTester: In the charter it says [reads from charter].
09:38:14 <ato> plh_: I think probably security review is going to be one of the most important.
09:38:33 <ato> AutomatedTester: Vendor security teams have reviewed things underway.
09:38:40 <ato> AutomatedTester: Does that make any difference?
09:38:48 <ato> plh_: We have missed problemsin the past.
09:38:58 <ato> plh_: It’s not going to be enough.
09:39:18 <ato> RRSAgent: please make the log world-visible
09:39:18 <RRSAgent> I'm logging. I don't understand 'please make the log world-visible', ato.  Try /msg RRSAgent help
09:39:30 <ato> RRSAgent: please make it world-visible
09:39:30 <RRSAgent> I'm logging. I don't understand 'please make it world-visible', ato.  Try /msg RRSAgent help
09:39:55 <ato> RRSAgent: please make these logs world-visible
09:40:02 <ato> RRSAgent: please draft the minutes
09:40:02 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/20-webdriver-minutes.html ato
09:40:24 <ato> present+ ato
09:40:36 <ato> AutomatedTester: More questions?
09:40:43 <ato> plh_: I have one for you.
09:41:00 <ato> plh_: When MikeSmith was saying keep the CR as late as possible…
09:41:19 <ato> plh_: Don’t go into CR until you know how to get out of it.
09:41:24 <ato> plh_: There is a price to be paid to be in CR.
09:41:35 <ato> plh_: It is more painful to change the specification once it’s in CR.
09:41:44 <ato> plh_: Because you have patent commitment &c.
09:42:12 <ato> AutomatedTester: Thank you.
09:42:15 <ato> plh_: Thank you.
09:42:25 <ato> AutomatedTester: Break now
09:46:26 <Ms2ger> Ms2ger has joined #webdriver
10:01:35 <juangj> juangj has joined #webdriver
10:08:25 <simonstewart> simonstewart has joined #webdriver
10:12:16 <AutomatedTester> present+ AutomatedTester
10:12:17 <brrian> present+ bburg
10:12:17 <sam_u> present+ sam_u
10:12:23 <mikepie> present+ mikepie
10:12:33 <brrian> present+ brrian
10:12:53 <wilhelm_> present+ wilhelm_
10:13:40 <juangj_> juangj_ has joined #webdriver
10:14:16 <juangj_> juangj_ has joined #webdriver
10:14:28 <juangj_> present+ juangj
10:14:39 <juangj_> Scribe: juangj_
10:15:13 <rniwa_> rniwa_ has joined #webdriver
10:15:20 <juangj_> Topic: Handshake strictness and Postel’s Law
10:16:15 <juangj_> simonstewart: reminder that as a general principle, you should ignore requests that contain extra stuff
10:16:25 <juangj_> jgraham: yes that’s how the spec has always been written
10:16:41 <juangj_> simonstewart: don’t expect this is contentious, just mentioned it because there have been bugs
10:16:47 <juangj_> Topic: /status endpoint
10:17:27 <juangj_> simonstewart: particularly for large server processes, you start the server and it goes and does a bunch of stuff while you have some coffee
10:17:51 <juangj_> simonstewart: it’s possible that the httpd is accepting connections while this stuff is happening, even though it’s not really ready to serve
10:18:03 <juangj_> simonstewart: nice to have an endpoint that says ‘200 ok’ when ready
10:18:25 <juangj_> ato: any reason not to just not respond to the request and block until ready?
10:18:39 <juangj> Scribe: juangj
10:18:50 <juangj> simonstewart: hard in practice
10:20:36 <juangj> simonstewart: other use cases are for grid, for nodes to come up but indicate whether theyre really healthy
10:20:54 <juangj> juangj: argument against /status in sapporo was that it’s an implementation detail of server management
10:21:09 <juangj> juangj: however, intermediary nodes are arguably in the business of server management, so it would be convenient
10:21:17 <juangj> ato: still don’t quite get the use case here
10:22:14 <juangj> simonstewart: useful for things like grid to detect end node health; generally not useful for endpoitn nodes themselves
10:22:29 <juangj> ato: is there some more rest-ful way we can do this, with a HEAD request perhaps
10:23:07 <juangj> jgraham: if we did this, there should be agreement on what the response should look like and how it behaves in different situations
10:23:21 <juangj> ato: not sure what an endpoint gives us that a HEAD request doesn't
10:23:24 <juangj> simonstewart: HEAD request to where
10:24:09 <juangj> ato: HEAD to /session? or to /
10:24:51 <juangj> sam_u: seems like we’re just discussing the name of the endpoint now, not whether it’s valuable
10:25:18 <juangj> ato: i see the use case for distributed systems, but…
10:26:53 <juangj> ato: much of this depends on what it means to be “OK"
10:27:53 <juangj> ato: not convinced an http status can convey the several states
10:28:31 <juangj> jgraham: in principle this is useful. there should be an applicable http status somewhere, there are a lot of them
10:28:59 <juangj> jgraham: if there was an http status that was unambiguously what we want for alive-but-not-healthy cases, that would be more theoretically pure
10:29:35 <jimevans> jimevans has joined #webdriver
10:29:43 <juangj> simonstewart: in cases where you’re ok and ready to start new sessions, 200 is fine, and in all other cases 503 is probably fine
10:30:51 <juangj> simonstewart: states are, e.g., “able to create new sessions”, “running, but unable to create sessions”, perhaps “shutting down” (e.g., draining a cluster of nodes) — might want to distinguish between reasons for being unable to create
10:32:04 <juangj> jgraham: hm, actually, http status really applies to the current request. returning 503 is strange when we were clearly able to handle the /status request, even though it theoretically would not be able to handle a request to a different endpoint
10:32:23 <juangj> sam_u: no reason you couldn’t say whatever you want to say in the body of the 200 response
10:33:03 <juangj> ato: if there are going to be 4-ish states, then yes we should just put info in strings in the body
10:34:25 <juangj> sam_u: do we still want, e.g., architecture, os name, in the /status response? (it’s in there in the json wire protocol)
10:34:38 <juangj> ato: doesn’t really make sense for an intermediary node, which has multiple sessions
10:35:13 <juangj> simonstewart: what’s actually important is just to know whether the node can create new sessions so local ends can poll for it
10:35:30 <juangj> ato: [looking for relevant status codes]
10:35:50 <juangj> jgraham: i thought we agreed to just use 200, with a json blob and status field
10:37:06 <juangj> jgraham: could we just have a json blob, either {“ready”: true} or {“ready”: false}? and return ‘ready’ if a request to ‘new session’ would currently succeed
10:37:34 <juangj> ato: wonder if we could supplement with additional, implementation-defined message
10:39:38 <juangj> ato: of course we can’t stop intermediaries from adding more fields, but “ready” and “message” at least seem sufficient
10:39:54 <juangj> sam_u: for the “ready” boolean, how sure do we need to be that we’re actually ready?
10:40:09 <juangj> sam_u: e.g., chrome doesnt start up well when windows isn’t logged in
10:40:26 <jimevans> jimevans has joined #webdriver
10:40:34 <juangj> ato: thought we decided this was only useful for intermediary nodes?
10:41:01 <juangj> jgraham: don’t think we decided that
10:41:49 <juangj> ato: not sure there’s a use case for this in an end node then. you could just attempt to create a session and get a ‘not created’ error
10:42:19 <juangj> sam_u: don’t want to actually have to create a new session just to find out if you *could* create it
10:42:49 <juangj> jgraham: don’t think we should define endpoints that only apply to intermediaries. intermediary and endpoint nodes should serve the same endpoints
10:43:23 <juangj> simonstewart: simple use case for endpoint node would be to return ready=false when you’ve reached the maximum session count
10:43:47 <juangj> sam_u: perhaps ready=false says it will definitely fail, ready=true means give it a shot, but doesn’t promise it will definitely succeed
10:44:06 <juangj> jgraham: necessarily must be purely informational; there is always a race here
10:44:49 <juangj> ato: 2 conditions: would “POST /session” succeed, and has max session count been reached
10:45:47 <juangj> juangj: is it required to fail when your’e at the limit, or are you permitted to kill an old session and make a new one?
10:45:50 <juangj> jgraham: it should be a fail
10:46:53 <juangj> proposed resolution: add /status endpoint. response is {“ready”: boolean, “message”: implementation-defined explanatory string}
10:47:03 <juangj> juangj: is “message” actually optional or is it required, but possibly empty?
10:47:08 <jimevans> jimevans has joined #webdriver
10:47:18 <juangj> ato: i guess we don’t have any optional keys
10:47:56 <juangj> RESOLUTION: add /status endpoint. response has two keys: {“ready”: boolean, “message”: implementation-defined explanatory string}. ready = true if the node believes that a ‘POST /session’ will succeed in creating a new session
10:47:56 <ato> juangj: r+
10:49:12 <juangj> ato: do we want to do something similar with ‘GET /sessions’?
10:49:25 <juangj> ato: it’s convenient but there is no clear use case right now
10:49:49 <juangj> jgraham: in the absence of clear use case, i’m opposed from a security standpoint, because it could make hijacking sessions easier
10:50:45 <juangj> simonstewart: we do do this in Selenium server already, at /wd/hub; shows a list of active sessions so you can quit them more easily
10:51:12 <juangj> AutomatedTester: definitely useful for intermediary nodes so you can clean up sessions that you thought should be dead. not clear this is useful for endpoint nodes
10:51:53 <juangj> ato: you could specify this, and then perhaps in endpoint nodes you could return 403 Forbidden
10:52:28 <juangj> AutomatedTester: concern that if endpoints return garbage here, then it breaks transparency
10:53:52 <juangj> AutomatedTester: there’s also no reason to put something in the spec that people aren’t willing to implement
10:54:04 <juangj> simonstewart: people could talk to their infosec teams
10:54:31 <juangj> jgraham: wary of adding new features and more work at this point
10:54:43 <juangj> brrian: i did used to have this endpoint and apple infosec did not like it
10:54:54 <juangj> jgraham: oh well then that settles that, doesn’t it?
10:55:50 <juangj> RESOLUTION: we will not add a /sessions endpoint for a list of active sessions, because of security concerns about divulging active sessions
10:56:04 <juangj> sam_u: are session IDs supposed to be secret in general?
10:56:41 <juangj> brrian: can’t keep them perfectly secret because people can sniff local traffic, of course. but having a /sessions endpoint means a webpage could grab it more easily
10:57:04 <juangj> ACTION: simonstewart to mention sensible use of TLS in the Security appendix
10:57:23 <juangj> Topic: Plans for a test suite
10:57:53 <juangj> AutomatedTester: we need to work out what we currently have in the test suite, which i appreciate is not much
10:58:05 <juangj> AutomatedTester: should create something to track who is working on what, and share what still needs to be done
10:58:27 <juangj> AutomatedTester: figure out who has what tests, where, and how to migrate them to a common place
10:59:08 <juangj> AutomatedTester: assuming for chrome’s tests, like mozilla’s, it’s non-trivial to migrate them?
10:59:10 <juangj> sam_u: [agrees]
11:00:29 <juangj> ato: skeptical of just mass-migrating tests from the selenium test suite
11:01:00 <juangj> ato: should certainly run the selenium tests as a reference, but really important is that we ensure normative language is covered appropriately
11:01:37 <juangj> simonstewart: vast majority of our users are selenium users, so selenium tests are an indication we can migrate people without blowing up every test in the world
11:02:04 <juangj> ato: but also important to have tests to ensure conformance of implementations
11:02:14 <juangj> simonstewart: both things important
11:02:36 <juangj> JohnJansen: in your experience, is there value in starting with the old tests?
11:03:23 <juangj> ato: no, don’t think so. better to examine spec text/structure, consider each step of each algorithm and consider ways to break them
11:04:09 <juangj> AutomatedTester: example: marionette was returning floats for element coordinates, selenium was expecting ints
11:05:05 <juangj> AutomatedTester: main takeaway is that we need to have a project plan so that we don’t step on each other toes. obviously won’t work to just say “work on whatever you want to work on"
11:05:40 <juangj> ato: want to avoid situation where we import a mass number of tests into WPT that haven’t been reviewed carefully, and where we don’t know which parts of the spec each test is intended to cover
11:06:16 <juangj> jgraham: less concerned about that. for our particular case, much more so than with the general web platform, we could get pretty far just with code coverage
11:08:54 <juangj> JohnJansen: how would we implement this plan? just like a wiki table of spec sections?
11:09:12 <juangj> [general discussion of the plan for the plan]
11:11:06 <juangj> ato: the old tests are still in the WPT repo. you can still go look at them for reference if you want. we can delete once we have spec coverage of those areas
11:11:33 <juangj> brrian: can you talk about the organization of the tests? right now there are 2 big files — are you envisioning more, smaller files?
11:11:42 <juangj> ato: was thinking one file per chapter
11:12:00 <juangj> simonstewart: how about directory per chapter? some complex things like Actions will be gargantuan
11:12:20 <juangj> ato: let’s not worry about that at the moment. we can modify that when it becomes a problem
11:12:53 <juangj> brrian: doesn’t seem like it would scale. one file = one person working at a time?
11:13:13 <juangj> jgraham: not really worried about the merge for people just contributing new tests
11:13:54 <juangj> [questions about actually checking out the repository]
11:14:04 <juangj> [disbelief about some ridiculous git nonsense]
11:16:34 <juangj> [debate about merits of embedding data: URIs in tests vs. putting HTML in separate files]
11:27:03 <ato> RRSAgent: please draft the minutes
11:27:03 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/20-webdriver-minutes.html ato
11:27:40 <juangj> Topic: Promises in executeScript
11:28:09 <juangj> simonstewart: i’m not sure how i’d do this in a local end that isn’t JS
11:28:41 <juangj> some confusion about what the proposal actually is
11:28:53 <juangj> AutomatedTester: (reading the bug out loud)
11:29:11 <JohnJansen> https://www.w3.org/Bugs/Public/show_bug.cgi?id=28060
11:29:39 <juangj> jgraham: we clearly are not going to remove executeAsyncScript
11:29:40 <jimevans> jimevans has joined #webdriver
11:30:03 <juangj> jgraham: if we want to finish anything, this is not the time to be writing a new algorithm to deal with this
11:30:16 <juangj> ato: FTR i do think it’s an interesting idea
11:30:47 <juangj> jgraham: this seems nice but should be traiged to level 2
11:31:28 <juangj> jgraham: to clarify, proposal is that the promises should be settled entirely on the remote end
11:31:39 <gitbot> gitbot has joined #webdriver
11:31:39 <gitbot> [13webdriver] 15jgraham opened pull request #332: Implement a GET endpoint for the timeouts (06master...06get_timeouts) 02https://github.com/w3c/webdriver/pull/332
11:31:39 <gitbot> gitbot has left #webdriver
11:31:50 <gitbot> gitbot has joined #webdriver
11:31:50 <gitbot> [13webdriver] 15jgraham opened pull request #333: Add a status endpoint. (06master...06status) 02https://github.com/w3c/webdriver/pull/333
11:31:50 <gitbot> gitbot has left #webdriver
11:32:43 <juangj> juangj: currently possible to deal with promises using executeAsync; just .then(callback)
11:32:52 <juangj> but not necessary to add special functionality for it now
11:33:16 <juangj> RESOLUTION: defer bug 28060 to level 2
11:35:40 <JohnJansen> scribe: JohnJansen
11:35:48 <JohnJansen> Topic: GetText()
11:36:26 <JohnJansen> current situation is that there has not been any review of the HTML spec
11:36:44 <JohnJansen> rniwa_: it is currently not interoperable
11:37:10 <JohnJansen> jgraham: it has landed
11:37:11 <jimevans> jimevans has joined #webdriver
11:37:19 <JohnJansen> juangj: there are still interop concerns
11:37:21 <JohnJansen> ... white space
11:37:33 <JohnJansen> ... probabably solvable when comparing text to known constant
11:37:46 <JohnJansen> ... work we'd like to not have to ask
11:37:58 <JohnJansen> ... ran some tests on google codebase that will fail
11:38:09 <JohnJansen> AutomatedTester: multiple browsers?
11:38:15 <JohnJansen> juangj: firefox and chrome
11:38:31 <JohnJansen> ato: concern is also innerText
11:38:47 <JohnJansen> ... even though it might not be interop amongst browsers
11:39:06 <JohnJansen> ... don't want to spec the javascript result for visible text
11:39:12 <JohnJansen> ... it is an approximation
11:39:52 <JohnJansen> AutomatedTester: as CSS progresses hopefully a platform API covers those
11:40:00 <JohnJansen> ... difficult for us to play "catch up"
11:40:24 <JohnJansen> ... groups driving things forward
11:40:37 <JohnJansen> ... what we consider visible now, might change
11:41:01 <JohnJansen> AutomatedTester: so we should normatively reference those specs
11:41:10 <JohnJansen> juangj: do we expect browser to converge?
11:41:21 <JohnJansen> AutomatedTester: guessing so, that's why it was added to HTML
11:41:37 <JohnJansen> AutomatedTester: but no idea right now
11:41:55 <JohnJansen> rniwa_: vendors are likely working towards interop
11:43:20 <JohnJansen> ato: if we spec something ourselves, it might not be the right thing for the future
11:43:28 <JohnJansen> ... remove it entirely or norm ref the html spec
11:43:49 <JohnJansen> juangj: as Jim says, there is concern with futureproofing
11:44:49 <JohnJansen> AutomatedTester: with getText() we have a path for interop, with isDisplayed, we don't
11:45:04 <JohnJansen> simonstewart: this is not a trivial thing to fix
11:45:18 <JohnJansen> ... real world backcompat concerns that will hinder adoption
11:45:31 <JohnJansen> wilhelm_: this is a case where quirks mode approach might help
11:46:12 <JohnJansen> simonstewart: the javascript representation works right now, and would allow vendors to move slowly toward interop
11:46:25 <JohnJansen> ato: we would be using somethign not standards compliant
11:46:35 <JohnJansen> s/somethign/something
11:46:55 <JohnJansen> jgraham: there is nothing saying you have to use the C++ algorithm of getText
11:47:06 <JohnJansen> ... you could use script injection that is equivalent
11:47:35 <JohnJansen> jgraham: in the end node you can do whatever you like
11:47:50 <JohnJansen> ... that is indistinquishable from the algorithm
11:48:13 <JohnJansen> simonstewart: output of innertext is not the same as the algorithm
11:48:50 <JohnJansen> simonstewart: are there other specs that depend on this?
11:49:00 <JohnJansen> jgraham: no, but if it breaks website, they get priority
11:49:10 <JohnJansen> rniwa_: innertext is very important to us
11:49:24 <JohnJansen> ... we could not change it would break user expectations
11:49:36 <JohnJansen> ato: better then to have a migration path
11:50:13 <JohnJansen> rniwa_: likely we would argue very hard not to change out implementation
11:51:06 <JohnJansen> ... lot of uses on the web [lists...]
11:51:55 <JohnJansen> AutomatedTester: selenium's version does not consider a lot of specs currently
11:52:06 <JohnJansen> simonstewart: that's why we are where we are
11:52:22 <JohnJansen> AutomatedTester: lots of cases where you "copy" and selenium gets it wrong
11:52:29 <JohnJansen> simonstewart: no, it's correct for Selenium
11:53:22 <JohnJansen> simonstewart: lots of test examples with single word, new line, new lines
11:53:32 <JohnJansen> ... built up a lot of code for this
11:53:49 <JohnJansen> ... but we have not defined behavior for some stuff (css text)
11:54:21 <JohnJansen> jgraham: is this the argument:
11:54:40 <JohnJansen> ... this is not implementable
11:55:23 <JohnJansen> ... we will not implement because it will break too much stuff, then we cannot have this in the spec
11:55:38 <JohnJansen> ... if you want to know what the text is actually like, then use script
11:55:46 <JohnJansen> simonstewart: it's not either/or
11:55:50 <JohnJansen> ... we can have a solution
11:56:31 <JohnJansen> simonstewart: we need to specify this with consideration for the current users who have written tests for 10 years
11:56:42 <JohnJansen> ... it would be nice to have something interoperable
11:56:55 <JohnJansen> ... but at no point can we throw existing users under the bus
11:57:12 <JohnJansen> ... therefore 'quirks mode' seems good
11:57:21 <JohnJansen> jgraham: that's two endpoints, then
11:57:35 <JohnJansen> ... essentially we are being told we have to have the selenium text
11:57:43 <JohnJansen> ato: maybe use capabilities?
11:57:59 <JohnJansen> ... if you are conformant with innertext, then use innertext
11:58:19 <JohnJansen> ... at some point in the future Selenium 4
11:58:38 <JohnJansen> simonstewart: we've made an effort to keep our changes from breaking users
11:58:56 <JohnJansen> ato: we need to have some migration path
11:58:59 <JohnJansen> simonstewart: agree
11:59:18 <JohnJansen> ato: at some point we need to move to the standard
11:59:50 <JohnJansen> simonstewart: I think we can define it simply by including the javascript as an appendix
12:00:17 <JohnJansen> ... we can recommend to users
12:00:35 <JohnJansen> jgraham: dislike "capability" and sort of dislike "javascript" in the appendix
12:01:08 <JohnJansen> ... we should be able to find evidence of people using innerText
12:01:18 <JohnJansen> ato: people won't be using it because it's not conformant
12:02:22 <JohnJansen> jgraham: seems like we can only ship the selenium solution because people don't want the un-interopable solution
12:02:41 <JohnJansen> JohnJansen: people want innertext to be interoperable, they do want to use this, but cannot
12:03:13 <JohnJansen> simonstewart: we need the old as well as a way to move forward
12:03:34 <JohnJansen> wilhelm_: if we don't have it, we will patch it forever
12:03:46 <JohnJansen> jgraham: seems like that could wait 6 months
12:03:54 <jimevans_> jimevans_ has joined #webdriver
12:04:01 <JohnJansen> ... why are we talking about this in v1
12:04:21 <JohnJansen> rniwa_: it will not be interoperable in the next 3 years
12:04:48 <JohnJansen> ato: we are trying to be standard for the future and backward compat
12:04:57 <JohnJansen> jgraham: right, so let's wait
12:05:17 <JohnJansen> ... let's not add work TODAY for work that will not be useful for YEARS
12:06:09 <JohnJansen> rniwa_: it's also likely if we do this today, people will write ua sniffing and will break in the future
12:06:47 <JohnJansen> jgraham: we would never change what Selenium does today
12:07:22 <JohnJansen> ... when in years' time we have users asking for this
12:07:31 <JohnJansen> ... then we add innertext at that point
12:08:18 <JohnJansen> simonstewart: there are places where we say "browser can do what it wants..."
12:08:26 <JohnJansen> jgraham: very few
12:09:13 <JohnJansen> simonstewart: this applies to link text and partial link text
12:09:22 <JohnJansen> ... as well
12:09:45 <JohnJansen> jgraham: if we add this then the endpoint changes
12:10:10 <JohnJansen> ... maybe at that point you look at a global session setting
12:10:26 <simonstewart> jimevans: nope
12:10:44 <simonstewart> The current proposal is to put the Selenium JS for “get text” into an appendix
12:10:49 <simonstewart> and then use that for now
12:11:34 <JohnJansen> simonstewart: writing this as prose is not going to work, should just have the code sample
12:12:20 <JohnJansen> wilhelm_: how sane is the current algorithm?
12:12:40 <JohnJansen> rniwa_: not very
12:12:47 <JohnJansen> ... just found two bugs today in it
12:13:42 <JohnJansen> RESOLUTION: Include the current Selenium solution in the spec and revisit innerText for V2
12:15:26 <JohnJansen> ato: we will likely end up with the same situation with even more tests in the future
12:15:40 <JohnJansen> jgraham: true, but the innertext solution is not currently a solution
12:17:14 <JohnJansen> simonstewart: should we submit our tests to the HTML working group?
12:17:26 <JohnJansen> JohnJansen: yes. if we have good tests that will help them, we hsould
12:17:58 <JohnJansen> wilhelm_: our selenium algorithm may actually INFORM the html spec and help
12:18:20 <JohnJansen> simonstewart: we don't WANT the selenium solution, but need it.
12:19:52 <JohnJansen> ACTION: figure out if our algorithm and tests help with innertext interop
12:20:25 <JohnJansen> Done
12:20:29 <JohnJansen> break for lunch
12:20:33 <JohnJansen> until 2
12:22:58 <Zakim> Zakim has left #webdriver
12:23:45 <jimevans> jimevans has joined #webdriver
12:29:25 <juangj_> juangj_ has joined #webdriver
12:51:45 <JohnJansen> RRSAgent, make minutes
12:51:45 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/20-webdriver-minutes.html JohnJansen
13:02:26 <sam_u> sam_u has joined #webdriver
13:04:35 <kochi> kochi has joined #webdriver
13:05:20 <chongz> chongz has joined #webdriver
13:08:48 <simonstewart> simonstewart has joined #webdriver
13:08:58 <simonstewart> scribe: simonstewart
13:09:10 <simonstewart> topic: extensions
13:09:21 <simonstewart> [AutomatedTester looks around]
13:10:05 <simonstewart> mikepie introduces himself. Works as MS with JohnJansen. He and kmag2 are part of the browser extension WG
13:10:16 <hwlee> hwlee has joined #webdriver
13:10:18 <simonstewart> mikepie: thinks there are some use case where webdriver is good for extensions
13:10:28 <simonstewart> mikepie: where people want to test extensions on sites
13:10:37 <simonstewart> mikepie: where extensions need to be tested cross-browser
13:10:46 <simonstewart> mikepie: testing combinations of extensions
13:10:57 <simonstewart> mikepie: offer coimpliance tests for extension support
13:11:07 <simonstewart> mikepie demoes extensions
13:11:56 <simonstewart> mikepie: additions include other ways that users need to interact with elements (such as click or send keys)
13:12:18 <simonstewart> mikepie: for example, translate text via a right click menu
13:12:31 <simonstewart> mikepie: also interact with browser chrome via a “page action”
13:12:47 <simonstewart> mikepie: also similar browser actions that initiate some kind of action
13:13:10 <simonstewart> mikepie: last piece is essentially a new window. Extension creates a new popup that it can present and user interact with
13:13:28 <simonstewart> mikepie demonstrates suggestions by JohnJansen for extensions in WebDriver spec
13:13:41 <boazsender> boazsender has joined #webdriver
13:14:04 <simonstewart> AutomatedTester: can’t see anything too contentious now
13:14:15 <simonstewart> sam_u: agrees with what’s been said
13:14:32 <simonstewart> sam_u: chromedriver has some support for chrome extensions. Used by google for testing some extensions already
13:14:56 <simonstewart> mikepie: skips to section 5 of the spec (capabilities)
13:15:23 <simonstewart> mikepie: talks about “enabledExtensions” capability, whihc contains a list of extensions
13:15:55 <simonstewart> simonstewart: points out that relative paths might not work on a distributed system
13:16:20 <simonstewart> mikepie: known issue: if you specify a folder, this should be the folder that contains the manifest json file
13:16:42 <mikepie> https://mikepie1.github.io/browserext-1/webdriver.html#capabilities
13:17:09 <simonstewart> sam_u: chrome extensions have an ID that’s based on the key in the manifest. Is that part of the extensions work?
13:17:19 <simonstewart> mikepie: will be discussed on Thursday about how to generate those IDs
13:18:01 <simonstewart> sam_u: chrome unpacks a crx and takes the manifest and pulls out the ID
13:18:11 <simonstewart> The id is stable for an extension
13:18:19 <simonstewart> sam_u: will that work well with your extensions api?
13:18:27 <simonstewart> mikepie: good question. We can discuss that on Thursday
13:19:17 <simonstewart> mikepie: in section 6 (sessions), no modification that’s needed for extensions here, but the top-level browsing context may need to be expanded to handle extension pop-ups
13:19:44 <simonstewart> mikepie: section 8 (window handles) would need to return the handle for an extension pop-up too
13:19:56 <simonstewart> mikepie: same goes for 8.3 (switch to window)
13:20:08 <simonstewart> mikepie: also 8.4 (get window handles)
13:20:31 <simonstewart> sam_u: in chrome, extensions have another tab that they can use (“webview”)
13:20:53 <simonstewart> sam_u: runs it as a separate render process, designed for embedding HTML into a page.
13:21:03 <simonstewart> sam_u: in chromedriver that appears as a window
13:21:33 <simonstewart> rniwa_: safari does something similar
13:21:47 <simonstewart> rniwa_: you want to be able to interact with the page in the popup
13:21:57 <simonstewart> mikepie: the page within the webview would appear as the window
13:22:12 <simonstewart> sam_u: does this exist in other browsers? And do we want to add this to windows or frames?
13:22:28 <simonstewart> sam_u: feels like it’s something that’s better as windows
13:22:47 <simonstewart> kmag2: asks for clarification on windows in webdriver
13:22:58 <sam_u> https://developer.chrome.com/apps/tags/webview
13:23:05 <simonstewart> AutomatedTester: discusses how marionette works
13:23:56 <simonstewart> sam_u: the popup looks like an iframe to a user, but to everything else it looks like a window. It won’t inherit the permissions of the extension (eg. may not be allowed to use a camera)
13:24:06 <simonstewart> kmag2: so it’s like an iframe in a web page but sandboxed?
13:24:31 <simonstewart> ato: from the webdriver point of view, it’s just another top-level window. It’s just another top-level browsing context
13:24:50 <simonstewart> rniwa_: in some browsers, a pop-up may appear, but you can still switch tabs
13:25:05 <simonstewart> rniwa_: is a popup associated with a particular tab in chrome?
13:25:14 <simonstewart> sam_u: only in the sense that it’s inside a tab
13:25:26 <simonstewart> sam_u: we used “window” because it’s easier to implement
13:26:01 <simonstewart> kmag2: from a user point of view, it may look like an iframe. Could be considered a different window
13:26:22 <simonstewart> kmag2: not defined
13:26:47 <simonstewart> JohnJansen: it “feels” like a separate window
13:27:05 <simonstewart> kmag2: user expects popups to close when window owning the extenion closes
13:27:23 <simonstewart> mikepie: section 17 (“extensions”) — new section
13:28:00 <simonstewart> mikepie: this is about invoking separarte actions. First is “getExtensionActions”, which lets you know that there’s an action that can be used. Returns the text of the action (currently the title property)
13:28:37 <simonstewart> mikepie: it also returns badge text as a separate string
13:28:53 <simonstewart> mikepie: takeExtensionAction will activate the action
13:29:30 <simonstewart> mikepie: another open issue is what’s returned from “getExtensionActions”. Currently returns a json object of “id”, “text”/“title”, “icon” and “badge”
13:29:50 <simonstewart> mikepie: you may want extra information to handle similarly named extensions
13:30:07 <simonstewart> kmag2: leaning towards generating an ID for each extension at runtime for the lifetime of the session
13:30:13 <simonstewart> mikepie: useful for translated strings too
13:31:02 <simonstewart> kmag2: thinks some things are missing. Being able to link a popup to an action would be useful. Also getting the location of the action (between browser actions and element actions). In firefox there’s also a drop down menu
13:31:22 <simonstewart> kmag2: also in firefox and old versions of chrome, extensions could be hidden and disabled
13:31:44 <simonstewart> mikepie: getExtensionContextMenuItems, specific to an individual element
13:32:01 <simonstewart> mikepie describes actions available through context menu
13:32:49 <simonstewart> kmag2: thinks some changes could be made. Both chrome and firefox support checkbox items, so being able to read those would be useful
13:32:58 <simonstewart> kmag2: items can be enabled and disabled in all browsers
13:33:11 <simonstewart> kmag2: most browsers also support separators in context menus
13:33:28 <simonstewart> kmag2: context menus for actions. There’s currently no way to open them
13:34:07 <simonstewart> AutomatedTester describes the “Actions” section and right clicking
13:35:10 <simonstewart> AutomatedTester: “this is where it gets tricky”. The webdriver spec only handles content
13:35:24 <simonstewart> AutomatedTester: at mozilla, we have support for going into the browser chrome
13:35:38 <simonstewart> AutomatedTester: All we need to do is switch the context
13:35:53 <simonstewart> AutomatedTester: talks about extension methods
13:37:12 <simonstewart> ato: handling chrome in firefox only works because firefox’s UI is XUL
13:37:24 <simonstewart> ato: thinks proposal sounds reasonable
13:38:02 <simonstewart> mikepie: describes how to active an extension context menu
13:38:58 <simonstewart> mikepie: other than one change to rename section to “Browser extensions"
13:39:17 <simonstewart> AutomatedTester: I dont think this needs to be in the webdriver spec. Would be better in the extensions spec
13:39:29 <simonstewart> AutomatedTester: allows the spec and how to test it to be combined in the same place
13:39:42 <simonstewart> AutomatedTester: and the browser tools and testing wg should be part of the review process
13:40:07 <simonstewart> AutomatedTester: the webdriver spec gives you primitives to get you 80% of the way there. WG’s can then extend the spec as necessary
13:40:37 <simonstewart> AutomatedTester: that’s because theyre the subject matter experts. We know the WebDriver community, and we can help provide help as necessary
13:40:53 <simonstewart> jgraham: additional point: if you need to patch any current text, that should be in the webdriver spec
13:41:17 <simonstewart> ato: this is a discussion we’ve not yet had
13:41:38 <simonstewart> ato: there are other WG’s that want to do something similar. Permissions and bluetooth are examples
13:42:03 <simonstewart> ato: also for our spec. Aiming for REC by March. Open question for us, how the process of adding new things to the spec will look for us
13:42:12 <simonstewart> wilhelm_: this is a good opportunity to talk about that
13:42:32 <simonstewart> kmag2: the additional browsing contexts should be in the webdriver specs
13:42:43 <simonstewart> AutomatedTester: we do have context menus “kind of” supported.
13:43:14 <simonstewart> jgraham: right click is supported, but we don’t say what that should do
13:43:31 <simonstewart> ato: in marionette, we do synthetic input. Executing a right click shouldn’t open a native menu
13:44:01 <simonstewart> ato: we could support that in marionette, but if you want interaction with the context menu, we should allow providing access to certtain items for security reasons
13:44:27 <simonstewart> ato: that’s why I think it makes sense to have a separate end point for selecting an item in the context menu
13:45:13 <simonstewart> ato: you’re the first WG to come to us with a ready made proposal
13:45:28 <simonstewart> mikepie: thank you. We’ll separate out the bits that need to be separated
13:45:35 <simonstewart> AutomatedTester: feel free to email our mailing list
13:45:59 <simonstewart> kmag2: do have an issue with how extensions are enabled, disabled and installed. Also opening special parts of the UI
13:46:21 <simonstewart> AutomatedTester: briefly touched on that with “new session”. Provides a common mechanism for passing in preferences and extensions
13:46:31 <simonstewart> kmag2: thought extensions could be installed at run time
13:47:00 <simonstewart> sam_u: also stuff to do with handling permissions at run time
13:47:08 <simonstewart> ato: marionette also has a need for that
13:47:16 <simonstewart> ato: standardising that API sounds reasonable
13:47:37 <simonstewart> kmag2: since you mentioned permissions, is theere anything for dealing with user permission prompts?
13:47:42 <simonstewart> AutomatedTester: no
13:48:06 <simonstewart> AutomatedTester: hard for us to describe how we’ll handle coat hangers until we know how they’re going to be implemented
13:48:12 <simonstewart> ato: but permissions would be good to support
13:48:34 <simonstewart> AutomatedTester bemoans lack of common behaviour between browser implementations for accepting permissions
13:49:22 <simonstewart> Discssion on existing browser support for extensions
13:50:44 <simonstewart> AutomatedTester: webdriver spec has a section on privacy. WebDriver should not impact users of the machine. Ideally installed extensions need to be removed
13:50:48 <simonstewart> JohnJansen: we should call that out
13:50:59 <simonstewart> ato: is there a temporary extension?
13:51:08 <simonstewart> ato: avaliable for the life time of a browser
13:51:18 <simonstewart> JohnJansen: that’s how we handle extensions now
13:51:56 <simonstewart> Discussion about security and privacy
13:52:30 <simonstewart> mikepie and kmag2 thank everyone
13:54:54 <simonstewart> topic: discuss send keys and determine best course of action for unicode entries
13:54:59 <simonstewart> AutomatedTester: but first, let’s have a break
13:55:37 <simonstewart> sam_u: we have visitors from Google to talk about send keys. In addition, we could talk about testing keyboard input events.
14:09:57 <ato> RRSAgent: please draft the minutes
14:09:57 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/20-webdriver-minutes.html ato
14:11:38 <sam_u> sam_u has joined #webdriver
14:14:49 <chongz> chongz has joined #webdriver
14:15:31 <simonstewart> brrian: describes how the high level sendKeys command works by iterating over all characters
14:15:52 <simonstewart> brrian: doesn’t work for unicode. IME spec is not doing much.
14:16:07 <simonstewart> brrian: has suggested using “graphine clusters” instead
14:16:33 <simonstewart> brrian: what we want to figure out is what the right thing to do is
14:17:32 <simonstewart> Gary Karcmarcik (garyk): mentions unicode
14:17:52 <simonstewart> jgraham: describes the high level “send keys” method
14:18:02 <simonstewart> ato: and it has specialisation for certain form elements
14:18:23 <simonstewart> garyk: talks about keyboard layout differences between US and other keyboard layouts
14:18:45 <simonstewart> jgraham: the way webdriver works at the moment is that we assume that the keyboard is a 104 US keyboard
14:19:13 <simonstewart> jgraham: there is some possibility that later webdriver will support different keyboard layouts
14:19:31 <simonstewart> jgraham: main thrust of the question: what’s the correct way to break up a string into keystrokes?
14:19:58 <simonstewart> garyk: if you approach it that way, you’re stuck with US English. Because outside of that you need knowledge of all keyboard layouts
14:20:06 <simonstewart> rniwa_: mentions complex scripts
14:20:35 <simonstewart> jgraham: if you send something that’s not represented on a US keyboard, we’ll send a keyboard event with the key code set to 0
14:20:58 <simonstewart> rniwa_: this will make webdriver useless for testing anything outside of the US
14:23:11 <simonstewart> rniwa_: talks about testing sites outside of the US
14:23:46 <simonstewart> rniwa_: the only way to make this feature useful in Chinese or similar languages, you need IME methods
14:24:10 <simonstewart> garyk: name is a little misleading, but it sounds useful.
14:24:43 <simonstewart> garyk: keys come as individual events.
14:25:03 <simonstewart> garyk is the coeditor of the UI events spec. Added support for code and key to events
14:25:24 <simonstewart> garyk: the common keys are compatible, but other things aren’t
14:25:46 <simonstewart> garyk: key value (what user sees), and code (scan code)
14:26:18 <simonstewart> garyk: we’re aiming to avoid bizarre edge cases. Had a situation where hardware changes broke things in interesting ways
14:27:18 <simonstewart> garyk: right now there’s no possible way to do this. Currently doing manual testing. Want to be able to test US International keyboard with dead keys.
14:27:45 <simonstewart> garyk: suggests injecting keys at the system level, then we can validate the physical keys being sent
14:28:15 <simonstewart> rniwa_: on some platforms, it’s impossible to send simulated system level keyboard events
14:28:25 <simonstewart> garyk: if that’s the case, we can’t test on those platforms.
14:29:00 <simonstewart> rniwa_: another way to do this is an emulated mark text and selection in the browser.
14:29:50 <simonstewart> rniwa_: you send the keys to the browser as webdriver does already, but you need a slightly higher level API, offering key events and expected text, with ordered events
14:30:12 <simonstewart> garyk: discusses how text input processing is done by the browser
14:31:02 <simonstewart> jgraham: the existing situation with the lowest level API, the key events handwaves a little about how events are fired.
14:31:23 <simonstewart> jgraham: you’re injecting something into the browser event loop that filters through the system that would generate the same web key events
14:33:27 <simonstewart> simonstewart: describes local end implementations and how keyboard input is done
14:34:40 <simonstewart> simonstewart: thought there was an API on Windows to figure out the keycode and scancode from a keyboard is
14:34:44 <simonstewart> rniwa_: nope :)
14:35:01 <simonstewart> rniwa_: describes difficulty of figuring out keyboard layouts
14:35:25 <simonstewart> garyk: but if an OS can’t guess the keyboard, no-one can
14:35:45 <simonstewart> garyk: Windows has an API to fill out the rest of the events given the scan code
14:36:05 <simonstewart> rniwa_: thinks there’s an API to do that too.
14:36:50 <simonstewart> rniwa_: this handles the keyboard problem, but not the way that things like how an OS does accents
14:36:59 <simonstewart> rniwa_: iOS, OS X and Windows are all different
14:38:09 <simonstewart> https://seleniumhq.github.io/selenium/docs/api/java/index.html?org/openqa/selenium/package-summary.html
14:38:16 <simonstewart> https://seleniumhq.github.io/selenium/docs/api/java/org/openqa/selenium/remote/server/handler/ImeActivateEngine.html
14:38:25 <simonstewart> simonstewart links to Selenium WebDriver APIs
14:38:44 <boazsender> boazsender has joined #webdriver
14:38:45 <ato> Scribe: ato
14:38:57 <ato> simonstewart: It was added to allow us to do proper localisation testing.
14:39:07 <ato> simonstewart: At a lower level than sendkeys.
14:39:21 <ato> simonstewart: Call low level actions API, and that would use the IME.
14:39:34 <ato> simonstewart: But that again assumed a partiucular keyboardlayout.
14:39:54 <ato> wilhelm_: Predefined keyboard layouts? Can we feed it with that?
14:40:01 <ato> wilhelm_: If you catch 50, it’s inifinitely better than what we hav enow.
14:40:15 <ato> garyk: There are six physical keyboard layouts.
14:40:22 <ato> rniwa_: Europeans are all 102.
14:40:28 <ato> garyk: There are locale differences.
14:40:36 <ato> garyk: [explains about keyboard layouts]
14:41:00 <ato> garyk: Then locales on top of these.
14:41:02 <ato> garyk: Literally dozens.
14:41:21 <ato> garyk: Pressing physical key, look it up in the locale, generate the key
14:41:23 <simonstewart> Final API from Selenium WebDriver: https://seleniumhq.github.io/selenium/docs/api/java/org/openqa/selenium/WebDriver.ImeHandler.html
14:41:32 <ato> garyk: Browser compat testing like I do is not the common use case here.
14:41:46 <ato> wilhelm_: I want to test the simple use case.
14:41:58 <ato> wilhelm_: Virtual IMEs are fine for the common use case.
14:42:06 <ato> garyk: That wouldn’t work for my use case.
14:42:37 <ato> garyk: There are different ways of getting access to characters.
14:42:48 <ato> garyk: E with accent: type dead key and that other key over there.
14:42:54 <ato> garyk: That is what I want to write a test case for.
14:43:04 <ato> rniwa_: I don't think it's necessary to define particular IME behaviour.
14:43:12 <ato> rniwa_: Each behaviour tested spearately does make sense to test.
14:43:24 <ato> rniwa_: Type the character, then insert another code point for accent.
14:43:40 <ato> rniwa_: Three or four different types of accents.
14:43:50 <ato> rniwa_: People probably want to these four different cases.
14:44:08 <ato> rniwa_: But they probably don't want to go through the native layer and look these up. It's fine to predefine.
14:44:25 <ato> rniwa_: Single IME that you can feed with some configuration should probably be fine.
14:44:35 <ato> rniwa_: Something that _behaves_ like a Korean IME.
14:44:51 <ato> rniwa_: Chinese IME is _very_ different from Taiwanese IME.
14:45:31 <ato> brrian: Most developers have no idea what a key code is.
14:46:05 <ato> rniwa_: Portuguese accent testing, Japanese kana input mode, Thai: Every testing machine would need to be natively set up to run that test.
14:46:19 <ato> garyk: You’re right. You would need physical keyboard and a lot of locales.
14:46:34 <ato> garyk: But WebDriver needs to be able to press physical key and set the locale.
14:46:49 <ato> garyk: It’s the concern of the test and the tester to make the right assertions.
14:46:53 <ato> brrian: That sounds limiting.
14:47:02 <ato> brrian: What level do we aim at here?
14:47:36 <ato> garyk: What would be the convenience method for Japanese users be?
14:47:45 <ato> garyk: We have a convenience method for US users.
14:48:06 <ato> rniwa_: I don’t think sending text is good enough…
14:48:29 <ato> [discussion about what users want]
14:49:10 <ato> garyk: We have a simple API and an andvanced API. It would be good if the advanced one actually was sufficiently advanced to support my use case.
14:50:25 <ato> rniwa_: If you implement autocompletion you need to generate out the right characters so you get the right composition.
14:50:52 <ato> garyk: Typing the simple characters, even in Japanese, is rather straight forward.
14:50:57 <ato> rniwa_: If you know the locale.
14:50:59 <ato> garyk: Yes.
14:51:21 <ato> garyk: Suggestions are in the heuristic space, so you can never rely on that.
14:51:28 <ato> s/garyk/rniwa_/
14:52:42 <ato> wilhelm_: [explains about his idea about idealised IME]
14:53:20 <ato> rniwa_: User wants these characters, then replace the first with this. If you can specify that, you can generate a lot of the actions a user wants to make on a keyboard.
14:53:27 <ato> wilhelm_: When you write the test, you know what you expect.
14:53:34 <ato> garyk: Could have a dummy IME for Japanese
14:53:44 <ato> garyk: Simple default conversion that never tries to be adaptive.
14:54:01 <ato> rniwa_: Sometimes you want to test specific sequence of events.
14:54:23 <ato> rniwa_: When cursor moves to the left, it changes something, and then breaks that model.
14:54:32 <ato> rniwa_: Arbitrary conversion sequence needs to be able to be coded, I think.
14:54:50 <ato> brrian: Virtual IME, basically.
14:54:54 <ato> brrian: This doesn’t sonud high level any more.
14:54:59 <ato> garyk: Or just a really simple one!
14:55:29 <ato> rniwa_: The key is how to specify the sequenece of keyup and keydown, along with current composable text.
14:56:09 <ato> garyk: Order of key composition events, order of keyup keydown events, swapping, composition update events that are firing [plus a few more things]
14:56:23 <ato> rniwa_: Extending current keysend command and adda current composition state
14:56:33 <ato> garyk: ?
14:56:38 <ato> rniwa_: sendKey("k")
14:57:00 <ato> rniwa_: Also, here’s the current composiing character
14:57:15 <ato> rniwa_: Then user types 8, here’s the current composing character [x].
14:57:53 <ato> jgraham: It sounds like the way that this could potentially
14:57:56 <ato> jgraham: We have this low level API
14:58:05 <ato> jgraham: I want to keydown A keyup A on this virtual keyboard.
14:58:37 <ato> jgraham: Each keyboad should have a way to define that the next event on this keyboard should be go into IME mode.
14:58:46 <ato> jgraham: Then press "k", "a" key in this IME.
14:58:55 <ato> jgraham: You’ve put JS in the page that listens for these events.
14:59:05 <ato> garyk: Also you can enter and exit the IME via the keyboard.
14:59:10 <ato> garyk: You don’t need a special API.
14:59:15 <ato> jgraham: The reason I want it to be specific.
14:59:40 <ato> jgraham: Is then obviously not browser/platform independent.
14:59:48 <ato> garyk: That seems reasonable.
15:00:38 <ato> garyk: What does the Selenium IME API do?
15:01:17 <ato> simonstewart: Once you activate the IME, you’re on your own.
15:02:02 <ato> rniwa_: On a Mac there’s no such thing as an IME.
15:02:12 <ato> rniwa_: If you disable key combinations, you select something from a menu.
15:02:36 <ato> garyk: I’m not uncomfortable with the idea that there’s a specific machine dedicated to do this.
15:02:41 <ato> garyk: Assumption I’m willing to make.
15:02:48 <ato> rniwa_: I think that will work for European languages, for usre.
15:03:11 <ato> rniwa_: This is the same problem with testing spell checking.
15:03:18 <ato> rniwa_: It learns, and you need to reset the state.
15:03:27 <ato> garyk: There are probably hacky ways to do this too. Overwrite some file.
15:03:31 <ato> garyk: Without reinstalling the OS.
15:05:58 <ato> ACTION: Add note to remind web browsers to disable their spell checking and autocorrection.
15:08:14 <ato> ato: [explains how synthesised events work in Firefox]
15:08:18 <ato> brrian: Safari uses nsEvents.
15:08:28 <ato> brrian: As if they were processed by the OS.
15:08:43 <ato> brrian: Slightly different than what Gecko does. Slightly lower level.
15:09:09 <ato> sam_u: In Chrome we do it in EventSource::SendEventToProcessor.
15:09:14 <ato> sam_u: This is before it gets to Blink.
15:09:51 <ato> garyk: Sounds cross platform.
15:09:54 <ato> sam_u: Maybe minus Android.
15:11:39 <ato> AutomatedTester: Do we want to be splitting grapheme clusters or [unicode code points]?
15:12:08 <ato> garyk: That’s not going to be good enough for Japanese or deep testing. But if it works it works.
15:12:12 <ato> garyk: You can split on unicode code point.
15:12:59 <ato> garyk: How do you specify thing sin the low level API?
15:13:25 <ato> jgraham: For keys, you say you want key down then a value that is like a character, and if that is a character that it can match on a US keyboard, then use that.
15:13:31 <ato> jgraham: That's the only thing at the moment.
15:13:38 <ato> jgraham: Not something that will change in the next six months.
15:13:41 <ato> jgraham: But may change in the future.
15:14:25 <ato> garyk: It would also be nice to not try to look up and just do the thing requested.
15:14:35 <ato> brrian: You send a key code _not_ a scan code.
15:14:41 <ato> jgraham: You send a key character, actually.
15:14:45 <ato> simonstewart: We can change that at some point.
15:14:56 <ato> jgraham: I think that API is extensible enough that we can change all the data in it.
15:15:32 <ato> simonstewart: You have services like Sauce that run their machiens in US data centres.
15:15:40 <ato> simonstewart: With users in Germany with German layout.
15:15:59 <ato> simonstewart: Their test will fail either locally or remotely.
15:16:12 <ato> jgraham: Scan code wont work.
15:16:13 <ato> simonstewart: Yes.
15:16:17 <ato> wilhelm_: You can assume US
15:16:36 <ato> garyk: Only the scan code, and expect the system to figure out the rest, then that would be different.
15:16:37 <ato> jgraham: Yes.
15:16:47 <ato> jgraham: This scan code sounds useful but that it is not something we want to add today.
15:16:53 <ato> jgraham: Something we may want to add int he future.
15:17:08 <ato> jgraham: Probably don't need to figure out all the details by this point.
15:17:33 <ato> garyk: By the time you do that it will not be useful for the work we are doing.
15:17:56 <ato> garyk: I’m going to continue with manual testing.
15:26:19 <jgraham> present+ jgraham
15:26:27 <simonstewart> present+ simonstewart
15:26:27 <ato> present+ garyk
15:26:36 <kochi> present+ kochi
15:26:41 <ato> RRSAgent: stop listnening
15:26:41 <RRSAgent> I'm logging. I don't understand 'stop listnening', ato.  Try /msg RRSAgent help
15:27:04 <ato> RRSAgent: off