13:03:00 <RRSAgent> RRSAgent has joined #testing
13:03:00 <RRSAgent> logging to http://www.w3.org/2013/06/13-testing-irc
13:03:08 <plh> plh has joined #testing
13:04:30 <wilhelm> Meeting: WebDriver F2F, June 13th 2013
13:04:52 <wilhelm> Agenda: http://www.w3.org/wiki/WebDriver/2013-June-F2F
13:08:21 <Ms2ger> RRSAgent, make logs public
13:10:02 <wilhelm> RRSAgent, draft minutes
13:10:02 <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html wilhelm
13:10:21 <wilhelm> RRSAgent, make logs public
13:12:16 <sstewart6> sstewart6 has joined #testing
13:12:21 <sstewart6> Hello everybody!
13:13:06 <Ms2ger> G'day
13:13:17 <AutomatedTester> AutomatedTester has joined #testing
13:13:30 <eranm> eranm has joined #testing
13:15:11 <wilhelm> Agenda: http://www.w3.org/wiki/WebDriver/2013-June-F2F
13:15:19 <Ms2ger> Ms2ger has changed the topic to: http://www.w3.org/wiki/WebDriver/2013-June-F2F
13:15:22 <fisherii> fisherii has joined #testing
13:15:24 <jimevans> jimevans has joined #testing
13:15:31 <plh> rrsagent, generate minutes
13:15:31 <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html plh
13:15:38 <chrisgao> chrisgao has joined #testing
13:15:52 <Ms2ger> s/Hello everybody!//
13:15:55 <Ms2ger> s/G'day//
13:15:58 <plh> Chair: Wilhelm
13:16:00 <Ms2ger> rrsagent, generate minutes
13:16:00 <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html Ms2ger
13:16:21 <plh> Present+ Plh
13:16:35 <wilhelm> Present+ Wilhelm
13:16:41 <ato> ato has joined #testing
13:16:43 <jimevans> Present+ jimevans
13:16:46 <JohnJansen> Present+ JOhnJansen
13:16:53 <sstewart6> Present+ sstewart6
13:17:01 <andreastt> Present+ andreastt
13:17:01 <wilhelm> RRSAgent, draft minutes
13:17:01 <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html wilhelm
13:17:03 <AutomatedTester> Present+ AutomatedTester
13:17:04 <kkania> kkania has joined #testing
13:17:06 <JohnJansen> Present+ JohnJansen
13:17:07 <fisherii> Present+ fisherii
13:17:17 <AutomatedTester> Present+ DavidBurns
13:17:20 <Ms2ger> s/Agenda: http://www.w3.org/wiki/WebDriver/2013-June-F2F//
13:17:33 <sstewart6> Present+ SimonStewart
13:17:37 <kkania> Present+ KenKania
13:17:47 <fisherii> Present+ MarcFisher
13:18:17 <plh> rrsagent, generate minutes
13:18:17 <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html plh
13:19:03 <sstewart6> Who's scribing?
13:19:14 <wilhelm> Scribe: wilhelm
13:19:26 <wilhelm> (Introductions.)
13:19:30 <sstewart6> Thanks :)
13:19:33 <Ms2ger> Scribenick: wilhelm
13:19:52 <Ms2ger> RRSAgent, generate minutes
13:19:52 <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html Ms2ger
13:21:06 <wilhelm> Topic: State of the union
13:21:21 <wilhelm> sstewart6: The spec is the laggiest part of the work we're oing.
13:21:33 <wilhelm> We just had SeConfg. Just before that, Google released ChromeDriver 2.
13:21:40 <wilhelm> Adds support for mobile.
13:21:50 <Ms2ger> RRSAgent, generate minutes
13:21:50 <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html Ms2ger
13:21:51 <wilhelm> Mozilla announced Marionette.
13:21:57 <wilhelm> It will be in Firefox 24.
13:22:12 <wilhelm> We announced Selenium 3, where the project gets rid of the old APIs.
13:22:16 <wilhelm> The spec does not reflect the current work.
13:22:25 <wilhelm> We content on everything but the wire protocol.
13:22:34 <wilhelm> The test suite also requires work.
13:22:51 <wilhelm> Every implementation uses the Selenium project test suite currently.
13:23:04 <wilhelm> We made the wire protocol mandatory.
13:23:30 <wilhelm> AutomatedTester: Mozilla has an implementation of touch we'd like to discuss.
13:23:31 <blessmurk> blessmurk has joined #testing
13:24:13 <wilhelm> sstewart6: People are extending Selenium to test native mobile. This work falls outside the scope of this group. See the Selenium project.
13:24:25 <wilhelm> sstewart6: Other big news: Opera is now using the Chromium engine.
13:24:35 <wilhelm> ChromeDriver 2 supports Opera, no?
13:24:56 <wilhelm> andreastt: That's the plan, but it's not yet ready in Opera 15.
13:25:25 <blessmurk> y o y
13:25:27 <sstewart6> http://www.w3.org/wiki/WebDriver/2013-June-F2F
13:25:38 <wilhelm> Chair: sstewart6
13:25:59 <wilhelm> (Reading through the agenda, see above URL.)
13:29:06 <wilhelm> sstewart6: Does anyone have expertise on the accessibility APIs? If not, I suggest we wait with this discussion until we have the expertise present.
13:32:07 <MikeSmith> Zakim, call Mike
13:32:26 <MikeSmith> Zakim, drop MIke
13:33:53 <wilhelm> Topic: Performance logging
13:34:35 <sstewart6> Relevant part of the spec: https://dvcs.w3.org/hg/webdriver/raw-file/tip/webdriver-spec.html#logging
13:34:41 <sstewart6> It's currently empty :)
13:34:55 <wilhelm> Michael: What I'm proposing is to adda a field to log endry called data, which is arbitrary JSON.
13:35:02 <wilhelm> s/endry/entry
13:35:23 <sstewart6> Current OSS webdriver wire protocol: https://code.google.com/p/selenium/wiki/JsonWireProtocol#/session/:sessionId/log
13:35:46 <sstewart6> Representation as Java: http://selenium.googlecode.com/git/docs/api/java/org/openqa/selenium/logging/LogEntry.html
13:36:03 <wilhelm> sstewart6: (Refers to the links above.)
13:36:08 <Zakim> Zakim has joined #testing
13:36:22 <brma> brma has joined #testing
13:36:35 <gdennis> gdennis has joined #testing
13:36:42 <wilhelm> sstewart6: Looking at the interface definition from Java, it sounds like you're proposing we add another method to that.
13:36:49 <wilhelm> Michael: Yes.
13:37:02 <wilhelm> sstewart6: It would be a map of string to object.
13:37:14 <sstewart6> Suggestion: adding a map/dictionary of string->object
13:37:18 <sstewart6> :)
13:37:19 <wilhelm> eranm: Question on context: Does the log entry makes sense with data and nothing else?
13:37:24 <wilhelm> Michael: Yes.
13:37:38 <wilhelm> It's not really for human consumption.
13:37:52 <wilhelm> eranm: This will be distinguishable from the log type.
13:38:19 <wilhelm> sstewart6: Overview of how we do logging in the OSS project: The problem we're trying to solve is that there are multiple sources of messages. Local side, browser.
13:38:30 <wilhelm> There are also intermediate nodes in the chain (f.x. SauceLabs).
13:38:59 <wilhelm> There are 3-4 different sources of log information. At the end of the test run, you should be able to get all these logs.
13:39:03 <wilhelm> We have log types.
13:39:10 <wilhelm> Exposed through an API.
13:39:18 <wilhelm> "Get me the logs of this particular type."
13:39:30 <MikeSmith> RRSAgent, make minutes
13:39:30 <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html MikeSmith
13:39:41 <MikeSmith> RRSAgent, make logs public
13:39:55 <wilhelm> Michael: I'm working under the assumption that these are browser specific.
13:40:08 <MikeSmith> Zakim, call Mike
13:40:08 <Zakim> sorry, MikeSmith, I don't know what conference this is
13:40:15 <wilhelm> I'm just requesting an [opaque] data field.
13:40:45 <wilhelm> JohnJansen: This seems right to me.
13:40:59 <wilhelm> A new data field makes sense to me, at a high level.
13:41:11 <wilhelm> eranm: We would find it useful for getting profiling data.
13:41:19 <MikeSmith> Zakim, this will be WTA_BTTWG
13:41:19 <Zakim> ok, MikeSmith; I see WTA_BTTWG(TSTMIT)9:00AM scheduled to start 41 minutes ago
13:41:21 <wilhelm> It seems related, but might not be in the same format as this proposal.
13:41:45 <MikeSmith> Zakim, call Mike
13:41:45 <Zakim> ok, MikeSmith; the call is being made
13:41:46 <Zakim> WTA_BTTWG(TSTMIT)9:00AM has now started
13:41:46 <Zakim> +Mike
13:41:47 <wilhelm> sstewart6: We should probably leave the data format undefined for now.
13:42:28 <wilhelm> plh: The web performance working group has a HAR format.
13:42:35 <wilhelm> Michael: I have reservations about that.
13:42:42 <wilhelm> plh: You should raise these with the web performance WG.
13:43:06 <wilhelm> plh: We are working on disagnostic APIs and the ability to do some logging. Early in the process.
13:43:22 <wilhelm> plh: There is work happening, within the browser itself.
13:43:47 <wilhelm> sstewart6: We can already return logs from the J2E server. Those formats are not well defined.
13:44:07 <wilhelm> There is value in standardizing specific formats. I don't know if we can do that here.
13:44:13 <wilhelm> plh: What logs do you have?
13:44:26 <wilhelm> sstewart6: At what point was the flake in the flaky test introduced?
13:44:40 <wilhelm> We wanted logs from each moving part.
13:44:53 <wilhelm> We could do an aggregated log, or display separately.
13:45:01 <wilhelm> Useful diagnostic tool.
13:45:14 <wilhelm> JS errors is a classic example.
13:45:20 <wilhelm> Not every browser exposes this.
13:45:38 <wilhelm> We need an API to query available log types.
13:46:01 <wilhelm> Do we have standardized names for log types?
13:46:15 <klepikovm> klepikovm has joined #testing
13:46:15 <wilhelm> What if there are clashes?
13:46:28 <wilhelm> Should we circle back to this later?
13:46:35 <wilhelm> AutomatedTester: Yes.
13:46:50 <wilhelm> AutomatedTester: I don't see it being too contentious.
13:47:01 <wilhelm> sstewart6: The proposal is an undefined JSON blob.
13:47:08 <wilhelm> We should put thought into how to name log types.
13:47:48 <wilhelm> Do anyone need thinking time?
13:47:49 <wilhelm> jimevans: Yes.
13:47:54 <wilhelm> sstewart6: We'll revisit this after lunch.
13:49:09 <wilhelm> Topic: Visibility of elements
13:49:16 <wilhelm> Chair: AutomatedTester
13:49:32 <wilhelm> Chair: Greg
13:49:48 <wilhelm> sstewart6: Greg has been working on the browser automation atoms.
13:50:06 <wilhelm> One of these is isdisplayed.
13:50:21 <wilhelm> gdennis: I've been working on this for a year.
13:50:28 <wilhelm> Overflow is complicated.
13:50:30 <sstewart6> The Automation Atoms on the selenium wiki: https://code.google.com/p/selenium/wiki/AutomationAtoms
13:50:44 <wilhelm> The relationship between visibility and interactability.
13:50:53 <sstewart6> The current source of the atoms: https://code.google.com/p/selenium/source/browse/#git%2Fjavascript%2Fatoms
13:50:54 <wilhelm> The spec currently says that to be interactable, you must be visible.
13:50:58 <wilhelm> I'm not sure that's the case.
13:51:07 <wilhelm> I don't think we should put that in the spec.
13:51:10 <wilhelm> One issue is opacity.
13:51:35 <wilhelm> In the current JS implementation, a transparent element is not visible.
13:51:38 <wilhelm> But it is interactable.
13:51:42 <wilhelm> These are two separate questions.
13:52:02 <wilhelm> (Quoting the spec on visibility.)
13:52:11 <AutomatedTester> https://dvcs.w3.org/hg/webdriver/raw-file/tip/webdriver-spec.html#determining-visibility
13:52:13 <wilhelm> gdennis: I wonder if we can get away with being a little vague.
13:52:26 <wilhelm> An element is shown if a human user can see it.
13:53:12 <wilhelm> gdennis: Does something have to be scrolled into view to be visible?
13:53:18 <wilhelm> The atoms say this is not necessary.
13:53:26 <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html Ms2ger
13:53:31 <wilhelm> THere are practical benefits to this.
13:53:42 <wilhelm> "Is something visible on the page?"
13:53:56 <wilhelm> There is a moral argument against it in that a user can't actually see it.
13:54:10 <wilhelm> UI sometimes make scrollable things that don't have scrollbars.
13:54:18 <sstewart6> (the main benefit is that a test can make assertions about something being visible regardless of the size of the viewport of the browser)
13:54:31 <wilhelm> JohnJansen: It's not binary.
13:54:37 <wilhelm> This thing is on the page, but not visible.
13:55:00 <wilhelm> sstewart6: "Could it be made visible?"
13:55:08 <wilhelm> "Is it within the viewport?"
13:55:15 <wilhelm> Finding the viewport is difficult.
13:55:30 <wilhelm> Is a spec defining a viewport?
13:55:35 <wilhelm> JohnJansen: CSS is attempting it.
13:55:46 <wilhelm> AutomatedTester: getboundingclientrect is based on viewport.
13:55:50 <wilhelm> It must be defined somewhere.
13:56:03 <wilhelm> CSS3 Transforms depend on this.
13:56:19 <wilhelm> gdennis: The closure implementation of getting the viewport is quite accurate.
13:56:36 <wilhelm> AutomatedTester: scrollx, scrolly tells you how far you've scrolled.
13:56:39 <JohnJansen> this might help: http://dev.w3.org/csswg/css-device-adapt/#the-viewport
13:57:51 <wilhelm> sstewart6: I'm happy to rely on this definition.
13:57:51 <sstewart6> Sounds like we mean: http://dev.w3.org/csswg/css-device-adapt/#actual-viewport
13:58:19 <sstewart6> wilhelm^ http://dev.w3.org/csswg/css-device-adapt/#actual-viewport
13:58:24 <wilhelm> gdennis: If you want to say, "is it scrolled into view?", that's a separate question.
13:58:31 <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html ArtB
13:58:58 <wilhelm> andreastt: It's also impractical if you want to determine if a button is clickable.
13:59:21 <wilhelm> sstewart6: "Can I scroll this into view?"
13:59:49 <plh> zakim, passcode?
13:59:49 <Zakim> the conference code is 878648 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), plh
14:00:03 <wilhelm> gdennis: Interactability vs visibility.
14:00:47 <sstewart6> My interpretation so far: we need "can we move this element into the actual viewport?" (the current "is shown" behaviour) and "is the element currently within the actual viewport?" (which isn't currently defined)
14:01:13 <wilhelm> fisherii: From the point of view of test authoring, we need to be able to determine if we can interact with an element.
14:02:12 <wilhelm> (Discussion on opacity and bubbling.)
14:02:48 <Zakim> + +1.617.715.aaaa
14:03:02 <plh> zakim, aaaa is MIT_Room
14:03:02 <Zakim> +MIT_Room; got it
14:03:08 <wilhelm> jimevans: Should we define interactability, and expose it?
14:03:11 <wilhelm> sstewart6: Yes.
14:03:32 <wilhelm> fisherii: The criteria for sendkeys vs click may be different.
14:03:54 <wilhelm> gdennis: It might be interactable for one type of action, but not the other.
14:04:02 <wilhelm> fisherii: You could tab into a field that is hidden.
14:04:21 <wilhelm> JohnJansen: You may even be able to tab into a disabled element.
14:05:01 <wilhelm> fisherii: Handling of disabled elements vary between implementations.
14:05:04 <sstewart6> MikeSmith: can you hear me?
14:05:11 <sstewart6> Is it just that people need to speak louder?
14:05:29 <wilhelm> gdennis: If something is typable or not clicking, clicking would just be a noop.
14:05:47 <wilhelm> sstewart6: We seem to have inconsistent behaviour between browsers.
14:05:52 <MikeSmith> sstewart6: can't hear you at all. And it's not going to help if people speak lounde,r I think
14:05:59 <wilhelm> Standardizing this will be tricky.
14:06:22 <sstewart6> I'm the loudest person in the room :)
14:06:22 <wilhelm> gdennis: Can we define this by definiting a minimum?
14:06:24 <MikeSmith> sstewart6: seems like the mic isn't picking up much of anything
14:07:02 <Zakim> -Mike
14:07:17 <MikeSmith> Zakim, call Mike
14:07:17 <Zakim> ok, MikeSmith; the call is being made
14:07:17 <wilhelm> sstewart6: What are the meaningful conformance tests we want added?
14:07:18 <Zakim> +Mike
14:07:34 <wilhelm> gdennis: You could create a test suite with the minimum conditions we want to impose.
14:07:46 <wilhelm> ... Implied tests, "if this is true on this browser.."
14:08:10 <wilhelm> gdennis: Capabilities?
14:08:46 <wilhelm> sstewart6: I want a meaningful list of tests to add to the spec.
14:09:23 <wilhelm> sstewart6: "Could you interact with the body?"
14:09:28 <wilhelm> gdennis: Not if it's zero size.
14:09:30 <Zakim> -MIT_Room
14:09:36 <wilhelm> sstewart6: Wouldn't the body fill the whole viewport?
14:09:38 <wilhelm> (Yes.)
14:09:49 <wilhelm> sstewart6: What about a disabled input element?
14:09:54 <wilhelm> fisherii: You can click on it.
14:10:21 <wilhelm> sstewart6: You could fire a click on it, but it would be meaningless.
14:10:27 <wilhelm> fisherii: Doesn't it fire events?
14:10:37 <plh> zakim, passcode?
14:10:37 <Zakim> the conference code is 878648 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), plh
14:10:47 <wilhelm> AutomatedTester: I think it ignores the events.
14:10:47 <Zakim> +MIT_Room
14:11:44 <Zakim> +Plh
14:11:45 <wilhelm> data:text/html;charset=utf-8,<input%20disabled%20onclick%3D'alert(1)'>
14:12:06 <wilhelm> eranm: So when is an element is not interactable?
14:12:18 <Zakim> -Plh
14:12:32 <wilhelm> sstewart6: If it lies under another totally transparent element and it not in the tabindex.
14:12:44 <wilhelm> Unless the above element bubbles events.
14:12:53 <wilhelm> JohnJansen: ARIA.
14:13:49 <wilhelm> andreastt: Do we want to expose both?
14:14:04 <wilhelm> sstewart6: I don't know if there's any value in exposing interactable? to a user.
14:14:44 <wilhelm> (Tabbing to invisible elements.)
14:15:37 <wilhelm> fisherii: From the user point of view, they're clicking on the underlying element beneath an invislbe element. The intermediate element may complain, depending on implementation.
14:16:05 <wilhelm> gdennis: A user may want to interact with a transparent element.
14:16:08 <Zakim> +Plh
14:16:42 <Zakim> -Plh
14:16:53 <wilhelm> gdennis: Use case: UI with transparent element that turns visible onmouseover.
14:17:18 <wilhelm> sstewart6: The action element lets you specify an x/y coordinate to interact with.
14:18:07 <wilhelm> andreastt: From a test author's view, I wouldn't want to rely on interactable? to be exposed. I would try to click the element, and see what happens.
14:18:30 <wilhelm> fisherii: People expect to be able to click something, but there may be a transparent element in the way. ChromeDriver throws an exception.
14:18:43 <wilhelm> That might be undesirale behaviour.
14:19:01 <mdas> mdas has joined #testing
14:19:11 <wilhelm> sstewart6: There are two versions of click: Actions API, WebElement.
14:19:13 <plh> rrsagent, generate minutes
14:19:13 <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html plh
14:19:25 <wilhelm> "Do what I say" vs "Do what I mean".
14:20:29 <wilhelm> fisherii: There's different behaviour between Chrome and Firefox.
14:20:50 <wilhelm> sstewart6: For some of this, you need access to the render tree.
14:21:02 <marilyn_> marilyn_ has joined #testing
14:21:12 <wilhelm> JohnJansen: The differences between browsers mean that one of them is not compliant.
14:21:45 <wilhelm> fisherii: In Firefox, this was like firing the event directly on the element.
14:22:05 <wilhelm> JohnJansen: Which is mandated by the spec?
14:22:09 <wilhelm> sstewart6: Probably Chrome.
14:22:18 <wilhelm> JohnJansen: We've been looking at this in IE.
14:22:44 <wilhelm> Certain version of IE handles this differently.
14:23:13 <wilhelm> I just want to make sure we are basing tests on specs, not browser implementations.
14:23:22 <wilhelm> sstewart6: How do we define interactability?
14:24:02 <wilhelm> JohnJansen: (Describing a bug with floats and fractional pixels.)
14:25:02 <wilhelm> I need the distinction between immedately visible and requiring scrolling to be visible.
14:25:35 <wilhelm> JohnJansen: One of these tests should pass, and the other should fail. (visible / interactable)
14:26:18 <wilhelm> gdennis: "The browser window size is different, my test breaks"
14:26:55 <wilhelm> fisherii: (Refers to CSS spec on viewports.)
14:27:29 <wilhelm> fisherii: Scrollable divs are handled differently.
14:27:36 <wilhelm> sstewart6: I'm glad this is easy.
14:27:46 <AutomatedTester> http://www.w3.org/TR/CSS21/visuren.html#viewport
14:28:39 <wilhelm> sstewart6: So we're using the CSS 2.1 definition now?
14:28:42 <wilhelm> How does that handle frames?
14:29:30 <wilhelm> ACTION: JohnJansen to ask the CSS WG which definition of viewport, etc., we want to use
14:30:27 <wilhelm> sstewart6: Given sane definitions here, this is further complicated by: z-index, tabindex
14:30:51 <wilhelm> fisherii: If we're not going to expose this to the user, we can talk about clickable and typable as separate properties.
14:31:51 <wilhelm> sstewart6: (Explains why disabled elements are clickable in the WebDriver API.)
14:32:48 <wilhelm> sstewart6: "Would a user be able to interact with this element?"
14:33:09 <wilhelm> If any opaque element is in the way, the element is not interactable unless you can tab to it.
14:33:36 <wilhelm> fisherii: "Given the element was enabled, this is the element the event would go to"
14:34:09 <wilhelm> gdennis: I thought I understand what I wanted...
14:34:14 <wilhelm> Now I don't know anything anymore.
14:34:38 <MikeSmith> RRSAgent, make minutes
14:34:38 <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html MikeSmith
14:34:53 <wilhelm> jimevans: "It's all edge cases!"
14:35:44 <wilhelm> andreastt: There is a list of edge cases we could make test against.
14:36:03 <wilhelm> fisherii: Maybe you could only interact with elements you could add an onlick handler to.
14:36:24 <wilhelm> fisherii: The actions API doesn't care about interactable.
14:36:33 <wilhelm> sstewart6: Users don't know how browsers work.
14:37:22 <wilhelm> fisherii: What elements can't you attach handlers to?
14:37:31 <sstewart6> http://www.w3.org/TR/html401/sgml/dtd.html#events
14:37:59 <MikeSmith> Present+ GregoryDennis
14:38:11 <wilhelm> wilhelm: I'm not sure this is relevant anymore... What do current specs say?
14:38:41 <Ms2ger> I can definitely tell you HTML4 isn't relevant anymore
14:38:42 <wilhelm> AutomatedTester: The OSS project has users that still test against IE6.
14:39:51 <wilhelm> JohnJansen: It's not necessarily a browser legacy issue that should be ignored.
14:40:24 <wilhelm> wilhelm: We should just write the tests and extract the spec from that.
14:42:49 <andreastt> https://dvcs.w3.org/hg/webdriver-test
14:43:10 <wilhelm> ACTION: David Burns to lead the work on writing tests on visibility/interactivity
14:44:45 <wilhelm> jimevans: The spec says the "do what I mean" APIs should delegate down..
14:45:12 <wilhelm> WebElement.click method should check for visibility, interactability, scroll into view, use advanced user interactions ...
14:45:21 <wilhelm> sstewart6: That was the intention. There are edge cases.
14:45:46 <wilhelm> sstewart6: (Selection of multiple elements.)
14:46:18 <wilhelm> sstewart6: This brings us to ... partially visible elements in the viewport.
14:47:33 <wilhelm> Scribe: eranm
14:47:39 <wilhelm> Chair: sstewart6
14:47:46 <wilhelm> RRSAgent, draft minutes
14:47:46 <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html wilhelm
15:00:25 <zcorpan> zcorpan has joined #testing
15:02:46 <santeriv> santeriv has joined #testing
15:07:15 <eranm> Topic: Visibility
15:07:37 <eranm> sstewart6, first question on the agenda: what is considered visible? not the same as being interactable
15:07:51 <eranm> AutomatedTester: ideally something you could see on the screen
15:08:09 <eranm> AutomatedTester: If an element has text and is the same colour as the element, is it visible?
15:08:24 <eranm> AutomatedTester: An element with the same colour as the element behind it
15:08:34 <eranm> AutomatedTester: Also problems with opacity and partially hidden elements
15:08:57 <eranm> sstewart6: being visible means that if  I were to take a screenshot of the dom, is there a sequence of actions that would make this element visible
15:09:26 <eranm> fisherii: do you only mean the global scrollbar?
15:09:47 <eranm> sstewart6: want to take out of the equation clever things like endless scrolling
15:10:34 <eranm> sstewart6: the common use case: usage of web driver as a service, no access to the machine, can't set the resolution
15:10:40 <eranm> fisherii: agree, be resolution-independent as possible
15:10:58 <MikeSmith> Present+ MesseriEran
15:11:20 <eranm> fisherii: scrollbars internal to the page feel different to the window scrollbars
15:11:51 <eranm> gdennis: people create scrollable elements without scrollbars, which is a problem
15:11:58 <eranm> sstewart6: we're not going to handle that
15:12:12 <eranm> fisherii: we should stick to standards when it comes to respecting scrolling mechanisms
15:12:29 <eranm> sstewart6: otherwise we'll have to run every code path hoping one of them will scroll
15:12:48 <eranm> gdennis: users don't care.
15:13:03 <eranm> wilhelm: we should define explicitly that we don't handle crazy custom scrolling cases
15:13:05 <eranm> sstewart6: agree
15:13:14 <eranm> sstewart6: already defined this for taking screenshots
15:13:56 <eranm> JohnJansen: when scrollbars aren't visible until you hover, web driver should understand that the scrollbars exist ever if not displayed
15:14:08 <eranm> fisherii: it is a rendering choice of the browser
15:15:31 <eranm> AutomatedTester: main use case from firefoxos is z-inedx. Trying to avoid doing a lot of the animation to conserve power. Apps developers overlay items.
15:16:09 <eranm> AutomatedTester: automaters have a hard time figuring out if the element at the bottom of the stack is visible
15:16:33 <eranm> AutomatedTester: we live in a 2d world and trying to solve a 3d problem in a 2d world
15:17:02 <eranm> AutomatedTester: if the top-level one has no opacity and you can see through it, is it visible?
15:17:42 <eranm> sstewart6: we'd be in a far better place if we did this work 3 years ago
15:17:50 <eranm> AutomatedTester: in firefox we have no access to the render tree
15:18:41 <eranm> sstewart6: the implementation should be able to access the rendering engine to figure it out
15:19:09 <eranm> andreastt: if we go this path, can we use a definition from another spec?
15:19:41 <eranm> sstewart6: feels like it should be defined in another spec
15:20:04 <eranm> AutomatedTester: if it affects rendering, it probably should be
15:20:37 <eranm> JohnJansen: mentioned relevant parties on Chrome/Accessibility
15:21:11 <eranm> Action: sstewart6 to continue conversations with html5/css spec committees
15:21:53 <eranm> sstewart6: this feeds into things like our implementation of getText, which tries to be consistent across platforms
15:22:12 <klepikovm> klepikovm has joined #testing
15:22:19 <eranm> sstewart6: textContent doesn't capture it because there's no consistency between browsers.
15:22:31 <eranm> sstewart6: if we could ask an element if it's visible getText would have been much faster
15:22:52 <eranm> JohnJansen: Is it a bug if an element says it's visible but it actually isn't?
15:23:10 <eranm> sstewart6: yes
15:23:30 <eranm> JohnJansen: the test would have to prove the visibility of the element
15:23:46 <eranm> fisherii: we're not worried about rendering bugs in a web driver test. We use screenshot comparison tests for that.
15:23:54 <eranm> fisherii: our web driver tests tend to be more functional
15:24:29 <eranm> JohnJansen: Are screenshots brittle?
15:24:39 <eranm> fisherii: yes, but not done for most projects
15:24:58 <eranm> sstewart6: should we add takeScreenshot to WebElement?
15:25:07 <eranm> multiple voices: yes, please
15:27:00 <eranm> sstewart6: example for a partially-hidden element is a div within a div. the outer div is partially visible.
15:27:32 <eranm> AutomatedTester: also caused by css transforms. Could affect visibility during the transformation
15:27:45 <jmdyck> jmdyck has joined #testing
15:28:16 <eranm> sstewart6: to avoid getting a screenshot mid-animation people should use waits
15:29:16 <eranm> sstewart6: trying to click on an element that's constantly in motion can't be done completely "black box".
15:29:55 <eranm> sstewart6: results taken during a transition will vary and that's ok, as they should be accurate to the time the screenshot was taken
15:30:04 <eranm> AutomatedTester: main issue is z-index
15:30:15 <eranm> AutomatedTester: and partially hidden elements
15:30:40 <eranm> fisherii: overflow considered partially hidden
15:31:58 <eranm> AutomatedTester: implementation in marionette: check all 4 corners of the element as well as centre, see which returns true. If any returns true (or the centre)
15:32:17 <eranm> JohnJansen: if the element is very big the centre of the element will also be off
15:32:56 <eranm> AutomatedTester: 10k by 10k element will not be visible
15:33:26 <eranm> gdennis: why isn't the element visible if the element and the viewport intersect in any way?
15:34:15 <eranm> gdennis: generalise this with overflow calculation: check if the element intersects with its ancestor elements. it can be generalised in that way
15:34:38 <eranm> gdennis: is an element necessarily visible if it has a descendant that is visible?
15:35:13 <eranm> gdennis: Google maps UI, the map is 0 by 0 elements, has tile children with positive size, but the map is 0 by 0
15:35:33 <eranm> gdennis: so the atoms say you have a positive size is if your descendants have non-zero child.
15:36:01 <eranm> JohnJansen: don't think we can say it's visible
15:36:04 <eranm> gdennis: but you can get events
15:36:18 <eranm> JohnJansen: but they're actually interacting with the children
15:36:53 <eranm> JohnJansen: divs with content that comes from a hidden frame
15:38:30 <eranm> gdennis: element which is negatively positioned in the viewport but has a child within the viewport
15:39:10 <eranm> sstewart6: there's a limited set of elements that can get keyboard input
15:39:57 <eranm> fisherii: the advanced interactions API doesn't care about interactability.
15:40:07 <eranm> fisherii: only have to determine coordinates to click at
15:40:24 <eranm> gdennis: if they were to click on the map, they would not be able to.
15:40:57 <eranm> gdennis: map tiles are not known in advance, only want to click on the map
15:41:14 <Zakim> +mdyck
15:41:19 <eranm> gdennis: that x,y may not be interactable
15:42:23 <eranm> fisherii: the element is used as a reference, to calculate position
15:43:09 <Zakim> -Mike
15:43:26 <eranm> gdennis: this is a distinction from the javascript implementation, where the element provided is the element to be interacted with
15:43:54 <eranm> sstewart6: do what I mean vs. do what I say, Interactions API is do what I say
15:44:48 <zcorpan> zcorpan has joined #testing
15:45:46 <eranm> sstewart6: many of the limitations originate from the original implementation of the iedriver
15:46:05 <eranm> jimevans: now we do fairly complicated calculations to figure out what the screen coordinates we should be clicking at are
15:46:16 <eranm> jimevans: based on element coordinations on the screen, including iframes
15:46:17 <MikeSmith> Zakim, call Mike
15:46:17 <Zakim> ok, MikeSmith; the call is being made
15:46:19 <Zakim> +Mike
15:46:43 <eranm> jimevans: and we can't use the atoms because if there are cross-domain frames the atoms would not be able to get the document elements
15:47:03 <eranm> sstewart6: what does it mean for visibility?
15:47:36 <eranm> sstewart6: the intuitive definition is "i can see some part of it on the screen"
15:47:42 <eranm> andreastt: if any of it is visible
15:47:55 <eranm> JohnJansen: what about the children being visible but not the parent
15:48:08 <eranm> wilhelm: we should write tests
15:48:57 <eranm> JohnJansen: makes sense that the parent is not considered visible even if it's children are (unless it's visible by itself)
15:49:13 <eranm> fisherii: the visibility of the children does not affect the visibility of the parent
15:49:56 <eranm> gdennis: they want the map to be considered visible if its children are visible
15:50:41 <eranm> JohnJansen: css3 regions are relevant as well
15:51:00 <JohnJansen> http://dev.w3.org/csswg/css-regions/
15:51:19 <sstewart6> Thanks
15:51:29 <eranm> Animation should be drawn only if the element is visible, no reason in doing it otherwise
15:51:48 <eranm> jimevans: anchor element where the entire of it consists of a span element
15:51:50 <sstewart6> plh: can we please get a link to the web performance spec where this is defined?
15:52:06 <eranm> jimevans: the span element was considered to have 0 dimensions
15:52:40 <plh> -> http://www.w3.org/TR/page-visibility/ Page Visibility API
15:52:46 <sstewart6> Thanks :)
15:52:51 <plh> but it only defines for the document, not the elements (yet)
15:53:08 <zcorpan> zcorpan has joined #testing
15:53:16 <eranm> gdennis: I have a case where the element is negatively positioned outside the viewport, but has children in the viewport
15:53:24 <plh> we'll need to do for the elements to refine requestAnimationFrame
15:53:34 <eranm> gdennis: should the same exception we make for size should be made for negatively-positioned elements?
15:54:48 <eranm> eranm: does the problem not stem from the selection of the element to be interacted with?
15:55:00 <eranm> gdennis: the event handlers are on the map, tiles amount and naming is unknown
15:55:31 <eranm> wilhelm: is visibility an academic problem?
15:55:47 <eranm> AutomatedTester: what opacity do we set to say something is visible? currently anything above 0
15:55:58 <eranm> AutomatedTester: that should be higher
15:56:06 <eranm> fisherii: you can click on something with 0 visibility
15:56:29 <eranm> AutomatedTester: the lowest visible value is 0.05 (with human eyes)
15:56:58 <plh> Simon, you've got a wrong link to DOM2Core in your spec. should be DOM4 instead.
15:57:01 <eranm> sstewart6: select arbitrary limit for the visibility
15:57:38 <eranm> sstewart6: white text on white background is still visible, just hard to read
15:57:48 <sstewart6> plh: where?
15:58:11 <plh> section 12, Cookies
15:58:21 <eranm> fisherii: if you care about actually being able to see something you should be doing image analysis
15:59:01 <plh> ACTION: Simon to change link from DOM2Core to DOM4 in Section 12, Cookies
15:59:49 <eranm> AutomatedTester: element with visibility hidden?
15:59:57 <eranm> sstewart6: we've covered it in the Selenium IRC channel
16:00:10 <eranm> ACTION: Simon to link to the discussion on elements with visibility hidden
16:00:38 <eranm> sstewart6: if the size of the element is positive then disregard visibility hidden, because it affects layout
16:01:58 <Zakim> -mdyck
16:03:52 <plh> action-4?
16:04:54 <eranm> AutomatedTester: from a visibility point of view, it's not visible, but asking other questions (size) should be correctly returned as they affect layout
16:05:26 <eranm> fisherii: is displayed returns false , but get location and get size return correct values?
16:05:27 <eranm> AutomatedTester: yes
16:05:33 <eranm> fisherii: but it's not interactable?
16:05:35 <eranm> AutomatedTester: yes
16:05:46 <eranm> AutomatedTester: if display:none then it's totally different
16:07:01 <trackbot> trackbot has joined #testing
16:07:01 <trackbot> Sorry, but this channel isn't in my configuration.
16:07:01 <trackbot> If you want to associate this channel with an existing Tracker, please say 'trackbot, associate this channel with #channel' (where #channel is the name of default channel for the group)
16:21:38 <AutomatedTester> AutomatedTester has joined #testing
16:23:36 <Automate_> Automate_ has joined #testing
16:24:26 <zcorpan> zcorpan has joined #testing
16:28:16 <AutomatedTester> AutomatedTester has joined #testing
16:28:45 <AutomatedTester> AutomatedTester has joined #testing
16:34:06 <eranm> eranm has joined #testing
16:35:14 <AutomatedTester> AutomatedTester has joined #testing
16:35:40 <zqzhang> zqzhang has joined #testing
16:44:48 <AutomatedTester> AutomatedTester has joined #testing
16:47:12 <Automate_> Automate_ has joined #testing
16:49:12 <jhammel> jhammel has joined #testing
16:49:16 <jhammel> jhammel has left #testing
16:51:20 <AutomatedTester> AutomatedTester has joined #testing
16:52:57 <AutomatedTester> http://eideticker.mozilla.org
16:53:15 <Ms2ger> RRSAgent, thanks
16:53:15 <RRSAgent> I'm logging. I don't understand 'thanks', Ms2ger.  Try /msg RRSAgent help
16:54:13 <Ms2ger> Zakim, excuse us
16:54:13 <Zakim> leaving.  As of this point the attendees were Mike, +1.617.715.aaaa, MIT_Room, Plh, mdyck
16:54:13 <Zakim> Zakim has left #testing
16:54:46 <Ms2ger> RRSAgent, excuse us
16:54:46 <RRSAgent> I see 5 open action items saved in http://www.w3.org/2013/06/13-testing-actions.rdf :
16:54:46 <RRSAgent> ACTION: JohnJansen to ask the CSS WG which definition of viewport, etc., we want to use [1]
16:54:46 <RRSAgent>   recorded in http://www.w3.org/2013/06/13-testing-irc#T14-29-30
16:54:46 <RRSAgent> ACTION: David Burns to lead the work on writing tests on visibility/interactivity [2]
16:54:46 <RRSAgent>   recorded in http://www.w3.org/2013/06/13-testing-irc#T14-43-10
16:54:46 <RRSAgent> ACTION: sstewart6 to continue conversations with html5/css spec committees [3]
16:54:46 <RRSAgent>   recorded in http://www.w3.org/2013/06/13-testing-irc#T15-21-11
16:54:46 <RRSAgent> ACTION: Simon to change link from DOM2Core to DOM4 in Section 12, Cookies [4]
16:54:46 <RRSAgent>   recorded in http://www.w3.org/2013/06/13-testing-irc#T15-59-01
16:54:46 <RRSAgent> ACTION: Simon to link to the discussion on elements with visibility hidden [5]
16:54:46 <RRSAgent>   recorded in http://www.w3.org/2013/06/13-testing-irc#T16-00-10
17:10:06 <RRSAgent> RRSAgent has joined #testing
17:10:06 <RRSAgent> logging to http://www.w3.org/2013/06/13-testing-irc
17:16:10 <bbbco> bbbco has joined #testing
17:17:22 <Lachy> Lachy has joined #testing
17:18:12 <wilhelm> RRSAgent, draft minutes
17:18:12 <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html wilhelm
17:20:19 <wilhelm> Scribe: wilhelm
17:20:42 <sstewart6> http://www.w3.org/2011/08/browser-testing-charter.html
17:20:53 <wilhelm> Topic: Timeline for spec work
17:21:20 <wilhelm> sstewart6: According to our charter, we were supposed to be finished by February .. 2013.
17:22:13 <wilhelm> JohnJansen: We should put some amount of thought into it, and make it as real as possible.
17:22:23 <wilhelm> sstewart6: It should have some bearing of reality.
17:22:30 <wilhelm> plh: The product is your spec.
17:22:47 <wilhelm> sstewart6: We're doing our spec backwards. We have implementations, trying to go back to a spec.
17:23:15 <wilhelm> JohnJansen: By making a concrete schedule, you need to have make tough decisions. Limit the scope.
17:23:39 <wilhelm> sstewart6: We've done a good job of limiting scope so far.
17:26:36 <chrisgao> chrisgao has joined #testing
17:27:59 <fisherii> fisherii has joined #testing
17:28:19 <Lachy> Lachy has joined #testing
17:28:52 <zcorpan> zcorpan has joined #testing
17:32:19 <wilhelm> ACTION: Group will meet in the #testing channel on July 12th, to work on spec and test suite together
17:32:19 <trackbot> Sorry, but this channel isn't in my configuration.
17:33:58 <zcorpan> zcorpan has joined #testing
17:34:01 <wilhelm> RESOLUTION: Group aims for LC just after TPAC: 22nd of November, 2013
17:35:09 <Lachy_> Lachy_ has joined #testing
17:37:08 <wilhelm> jimevans: CR in March 2014?
17:39:32 <JohnJansen> http://dev.w3.org/csswg/css-regions/
17:39:50 <wilhelm> JohnJansen: The current spec does not use plinss' tool for mapping tests to chapters.
17:40:24 <wilhelm> JohnJansen: What it doesn't tell you how many tests you need for that paragraph, but it tells you how many you have.
17:40:52 <wilhelm> JohnJansen: Every statement needs >0 tests.
17:43:27 <wilhelm> ACTION: JohnJansen will share annotations on needed tests
17:43:27 <trackbot> Sorry, but this channel isn't in my configuration.
17:44:02 <wilhelm> andreastt: We could create empty tests and fill them in.
17:44:07 <wilhelm> sstewart6: I'd prefer a todo list.
17:45:18 <wilhelm> jimevans: This approach is useful for TTWF.
17:45:56 <JohnJansen> s/jimevans/johnjan
17:46:01 <JohnJansen> s/johnjan/johnjansen
17:56:45 <darobin> darobin has joined #testing
17:57:08 <wilhelm> ACTION: JohnJansen to investigate feasibility of running the Python-based test suite at MS
17:57:08 <trackbot> Sorry, but this channel isn't in my configuration.
17:58:30 <wilhelm> trackbot, bye
17:58:30 <trackbot> trackbot has left #testing
17:59:17 <wilhelm> sstewart6: PR in April.
18:02:42 <wilhelm> RESOLUTION: WG would like to meet at TPAC in China in November
18:06:10 <sstewart6> Current touch https://dvcs.w3.org/hg/webdriver/raw-file/tip/webdriver-spec.html#touch
18:06:14 <wilhelm> Topic: Touch events
18:08:13 <eranm> eranm has joined #testing
18:09:47 <kkania> Scribe: kkania
18:12:10 <AutomatedTester> http://nakubu.com/site_media/webdriver-spec.html#interactions
18:13:08 <kkania> AutomatedTester: with firefox OS, first target is mobile
18:13:54 <kkania> AutomatedTester: we've looked at open source project, it assumes one finger; nowsdays multitouch is important
18:14:38 <Vishal> Vishal has joined #testing
18:14:45 <kkania> AutomatedTester: examples of garage band, microsoft surface; there's a need to emulate multiple actions
18:14:53 <gdennis> the atoms TouchScreen abstraction: https://code.google.com/p/selenium/source/browse/javascript/atoms/touchscreen.js
18:15:41 <kkania> AutomatedTester: in our implementation, we combine actions into one batch for transmission
18:16:00 <JohnJansen_> JohnJansen_ has joined #testing
18:16:31 <JohnJansen_> JohnJansen_ has joined #testing
18:16:50 <JohnJansen_> JohnJansen_ has left #testing
18:16:58 <kkania> AutomatedTester: we do time slicing; you can create chains of different lengths, if you want chains to be of the same length, you can send a no-op
18:18:24 <kkania> AutomatedTester: This is our first implementation.  There's no regard for pointer events. For instance, we don't handle tilting
18:18:52 <kkania> gdennis: I'd argue this should be just for touch. Pen, etc. is separate
18:19:03 <kkania> sstewart6: Agree.
18:19:40 <sstewart6> http://www.w3.org/TR/pointerevents/#pointerevent-interface
18:19:59 <JohnJansen> JohnJansen has joined #testing
18:21:10 <kkania> AutomatedTester: there is no JSON wire protocol for this yet, since we are using an internal protocol
18:21:44 <JohnJansen> Present+ JohnJansen
18:21:56 <kkania> AutomatedTester: should there be separate implementations for touch and for click?
18:22:23 <kkania> sstewart6: we should redirect based on the underlying device
18:23:13 <kkania> sstewart6: if you do need to distinguish between click and touch, you could use lower level action apis
18:23:21 <kkania> sstewart6: but the default would match the system
18:23:31 <kkania> JohnJansen: can you override it?
18:23:52 <kkania> gdennis: if override requires to go through the advanced interactions API, that's a bit much?
18:26:19 <kkania> jimevans: i'm less concerned about the high-level interface; we should have a single endpoint called input which takes an array of actions
18:26:50 <darobin> darobin has joined #testing
18:26:57 <sstewart6> ArtB: yes it would
18:27:04 <kkania> sstewart6: let's finish the straw man for touch before batching
18:27:30 <sstewart6> AutomatedTester tells us that he's spoken to some of the mozillians involved, but hasn't had their strawman in place for long
18:28:47 <kkania> AutomatedTester: if its not too contentious, I'd be happy to forward to the other working group, but I'd like our input first
18:29:21 <kkania> AutomatedTester: We have tap on the element; users wanted to know the difference between click and tap
18:29:47 <kkania> AutomatedTester: we've done click in the past and redirecting, but harms readability of tests
18:30:27 <kkania> sstewart6: this is a stronger argument to remove click from WebElement
18:30:36 <kkania> jimevans: it would force you to go to the advanced interactions
18:30:56 <kkania> fisherii: that means we'd ignore all the interactions stuff we discussed earlier
18:31:32 <kkania> andreastt: could we have a state on the web driver itself that says whether it is click or tap?
18:31:56 <kkania> andreastt: if readability is a problem, I would subclass the WebElement instance
18:32:30 <kkania> sstewart6: click is very clear about what it means; you could tell someone to click something on their phone; adding an individual tap is bad
18:32:37 <kkania> andreastt: I agree adding method for tap is bad
18:32:53 <kkania> gdennis: which of the ones we are proposing does a redirect
18:33:02 <kkania> gdennis: is there a drag that does a swipe
18:33:11 <kkania> sstewart6: this is only for stuff on webelement
18:34:10 <andreastt> Isn't that what I proposed earlier? d-:  Oh well.
18:34:34 <kkania> sstewart6: if you care about the actual events, you should be using advanced interactions
18:35:07 <Vishal> sstewart6: sorry if this is missing some context, but what's the motivation for keeping two separate levels? those on webelement and interactions?
18:35:13 <kkania> sstewart6 explains way actions work currently in open source
18:37:10 <sstewart6> tl;dr: Actions make use a Mouse and Keyboard abstraction.
18:37:55 <kkania> AutomatedTester explains straw man proposal linked earlier
18:39:02 <kkania> sstewart6: aggregations of underlying things that could be done on the local end don't need to be in the spec
18:40:41 <kkania> sstewart6: I'd like to see the deepest level of abstraction instead of starting the discussion on the high level
18:41:10 <kkania> sstewart6: I'd like to see the equivalent of the mouse and keyboard interface
18:41:31 <kkania> gdennis: why is cancel needed? a user cannot right?
18:41:55 <kkania> AutomatedTester: mashing your hand against the phone will cancel
18:42:19 <kkania> everyone tries mashing their hand against their phonee
18:43:39 <Vishal> if we have a mouse and keyboard, would having a screen (for touch) also make sense?
18:44:01 <Vishal> going forward, screen interactions will become more relevant (and important)
18:44:45 <sstewart6> Vishal: AutomatedTester is currently describing the touch strawman
18:44:45 <kkania> AutomatedTester explains time ticks and necessity of batching for latency purposes
18:44:48 <sstewart6> So "yes"
18:46:27 <kkania> sstewart6: are beats based on time or on command
18:47:09 <zcorpan> zcorpan has joined #testing
18:47:09 <kkania> fisherii: if you make it time based, it's hard to make it line up across multiple fingers; action based is easier
18:47:20 <kkania> sstewart6: you can imagine causing failures in both pretty easy
18:47:49 <kkania> sstewart6: does anyone think time based is a good idea?
18:48:16 <Lachy> Lachy has joined #testing
18:50:12 <kkania> gdennis: I'm not sure long press is necessary
18:51:12 <kkania> AutomatedTester explains that long press is used to bring up context menu for testing in firefox os
18:52:48 <kkania> wilhelm: how would i zoom out in a map application? wait an amount of time?
18:54:44 <kkania> sstewart6 describes java interface for mouse
18:54:54 <kkania> sstewart6: what are the primitives for touch?
18:56:14 <kkania> fisherii: is velocity part of a move?
18:57:50 <kkania> sstewart6: aggregation of underlying primitives should be pushed outside of the spec
18:58:12 <kkania> fisherii: how long it takes for a long press varies on device
18:58:23 <kkania> sstewart6: we need to find out what these primitives are for device
18:58:54 <bbbco> bbbco has joined #testing
19:01:26 <kkania> sstewart6: so have a tap which takes a count, ok?
19:01:36 <kkania> many agreements
19:01:48 <kkania> sstewart6: I think long press also needs to be a primitive
19:02:59 <kkania> sstewart6 talks about open source touch primitives
19:03:07 <kkania> AutomatedTester: I don't think scroll is needed, just a press and move
19:03:52 <kkania> sstewart6: I think I agree
19:05:08 <klepikovm> klepikovm has joined #testing
19:06:32 <kkania> gdennis: do you want the ability to specify time in wait, instead of a pause to sync for the tick
19:07:10 <kkania> fisherii: the time in the wait could specify the minimum amount of time of the tick
19:08:07 <kkania> sstewart6: I think that makes a lot sense
19:08:46 <kkania> sstewart6: I think we've agreed on ticks is a good thing, having taps with a count parameter, long press
19:08:59 <kkania> sstewart6: and finger down and finger up, move by offset
19:10:08 <kkania> talk about how to do rotation
19:12:05 <kkania> gdennis: instead of multi-action, another option would be multiple locations in a single action
19:12:38 <kkania> sstewart6: might want to do different action types at the same time
19:13:20 <kkania> gdennis: that is a good argument
19:14:49 <kkania> wilhelm: how would rotations work?
19:15:19 <kkania> jimevans: a huge batch of straight lines, which could be composed at a nicer way at a higher level
19:15:32 <kkania> many voices agree
19:16:07 <kkania> fisherii: does the mozilla implementation work with multiple input devices at the same time
19:16:12 <kkania> AutomatedTester: not yet
19:18:44 <kkania> ACTION: AutomatedTester will update the proposal for touch primitives and send it out for review
19:20:22 <kkania> AutomatedTester points to place in mozilla straw man that discusses batching actions
19:20:42 <andreastt> Scribe: andreastt
19:21:08 <sstewart6> scribe andreas:
19:21:11 <wilhelm> RRSAgent, draft minutes
19:21:11 <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html wilhelm
19:23:21 <andreastt> Topic: Batching
19:23:37 <andreastt> sstewart6: The need for batching is obvious, ideally for everything.
19:23:43 <andreastt> sstewart6: We're only looking at user input batching atm.
19:23:55 <andreastt> jimevans: From a wire protocol perspective
19:24:02 <andreastt> jimevans: You send a command to a single protocol endpoint
19:24:16 <andreastt> jimevans: Which as its JSON data takes an array of JSON objects, each of those objects describes an action.
19:24:36 <andreastt> jimevans: The format of those actions is ... it takes the name of the action.
19:24:43 <sstewart6> https://code.google.com/p/selenium/wiki/JsonWireProtocol#/session/:sessionId/buttondown
19:25:10 <andreastt> jimevans: Instead of the parameters simply taking the numbers, it would have name, colon, button down, colon.
19:25:19 <andreastt> sstewart6: It would also need the name of the device.
19:25:32 <andreastt> jimevans: I hadn't considered that because up to this point I was only dealing with desktpo types.
19:25:48 <andreastt> fisherii: Touch, click would be what it would be otherwise
19:25:55 <andreastt> fisherii: I don't think you need a separate device thing.
19:26:29 <andreastt> jimevans: touch/press
19:26:34 <andreastt> jimevans: All of them are prefixed.
19:26:48 <andreastt> fisherii: I think it would've been nice if keyboard and  mouse had done that to begin with.
19:26:54 <andreastt> jimevans: That's my strawman proposal.
19:26:57 <andreastt> sstewart6: How would we do it?
19:27:04 <andreastt> sstewart6: I guess it would be a list of lists.
19:27:52 <andreastt> sstewart6: For rotations it would be nice to go as soon as you can.
19:28:02 <andreastt> fisherii: List of beats, then each beat is a list of actions in itself.
19:28:09 <andreastt> sstewart6: I'm actually happy with that.
19:28:16 <andreastt> sstewart6: We've already had this argument some times.
19:28:29 <andreastt> jimevans: Ticks, beats, whatever we're calling it.
19:28:38 <sstewart6> s/beats/ticks/
19:28:41 <andreastt> JohnJansen: I'm going to spell check the beats to “ticks”.
19:29:25 <andreastt> jimevans: So how would that work, how would it sit for AutomatedTester?
19:29:36 <andreastt> AutomatedTester: Each line as one list, then we slice the lists.  So that's fine.
19:29:39 <andreastt> sstewart6: Cool.
19:29:44 <andreastt> AutomatedTester: That's what I was looking for.
19:29:47 <andreastt> sstewart6: Does anyone disagree?
19:30:00 <andreastt> No.
19:31:03 <andreastt> Resolved: We batch with a list of ticks, and each tick is a list of actions.
19:31:19 <andreastt> Resolved: We have a single end-point in the HTTP protocol for actions to be sent to.
19:31:52 <andreastt> Action: AutomatedTester finish his strawman proposal.
19:32:35 <andreastt> sstewart6: Do we invite Michael back now for the data in logging discussion?
19:32:57 <andreastt> fisherii: Naming conventions for log types?
19:33:58 <andreastt> Resolved: Add data field to a log entry, which should be a map of string of objects (JSON blob).
19:34:00 <wilhelm> RRSAgent, draft minutes
19:34:00 <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html wilhelm
19:34:16 <andreastt> Ten to fifteen minute break.
19:34:21 <mklepikov> mklepikov has joined #testing
19:34:38 <andreastt> mklepikov: We agreed to add your proposal.  No need for further discussion.
19:35:09 <andreastt> Resolution: Add data field to a log entry, which should be a map of string of objects (JSON blob).
19:35:15 <wilhelm> RRSAgent, draft minutes
19:35:15 <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html wilhelm
19:35:43 <andreastt> RESOLUTION: Add data field to a log entry, which should be a map of string of objects (JSON blob).
19:35:48 <wilhelm> RRSAgent, draft minutes
19:35:48 <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html wilhelm
19:49:30 <klepikovm> klepikovm has joined #testing
19:51:12 <kkania> kkania has joined #testing
19:55:28 <sstewart6> sstewart6 has joined #testing
19:55:36 <andreastt> sstewart6: Topics we could cover if we so wish.
19:55:51 <andreastt> sstewart6: Modern HTML5 input type, on which there is no concensus.
19:55:57 <andreastt> sstewart6: Security dialogues.
19:56:09 <andreastt> sstewart6: Sensors, caches, interaction with sysapps, the test suite.
19:56:27 <andreastt> sstewart6: I would quite like to either do the new sensors, or the modern input types.
19:56:50 <andreastt> jimevans: The input types is the only one I have real input on.
19:57:02 <sstewart6> https://groups.google.com/forum/#!msg/selenium-developers/_JiNc65rOUo/SJxNjCQq7t4J
19:57:23 <sstewart6> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#the-input-element
19:57:32 <andreastt> Topic: HTML5 input types
19:57:38 <sstewart6> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#attr-input-type
19:57:51 <andreastt> sstewart6: The type attribute has gone from being very simple to very complex.
19:58:06 <andreastt> sstewart6: Whereas you could previously only upload one file, you can now upload multiple files for example.
19:58:13 <andreastt> sstewart6: Some of them just fallback to plain text.
19:58:40 <andreastt> sstewart6: datetime, datetime-local, range, color pose some problems.
19:59:00 <andreastt> They probably bring up some native UI.  I don't know how IE does it, but Firefox does shadow DOM.
19:59:05 <andreastt> We need to be able to send data to it.
19:59:20 <andreastt> The file input element allows you to upload multiple files.
19:59:36 <wilhelm> http://shwetankdixit.com/testpages/webforms2demo.htm
20:00:22 <andreastt> sstewart6: So the interesting thing is, if you have an old browser it will fall back to rendering all of these as text inputs.
20:00:30 <andreastt> sstewart6: We could say just go on and send strings.
20:00:55 <andreastt> fisherii: Is it really?  The forms themselves just send it to the backend.
20:01:00 <andreastt> sstewart6: What do we do with datetimes?
20:01:22 <andreastt> sstewart6: Well you have to do it with an ISO formatted date, then you end up jumping through these hoops, you end up leaving people confused.
20:01:57 <JohnJansen> JohnJansen has joined #testing
20:02:04 <JohnJansen> Present+ JohnJansen
20:02:09 <wilhelm> http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#date-state-(type=date)
20:02:14 <sstewart6> Present+ SimonStewart
20:02:32 <andreastt> andreastt: I like Jason Leyba proposal to use client binding utility classes.
20:02:53 <wilhelm> http://www.w3.org/html/wg/drafts/html/master/forms.html#date-state-(type=date)
20:03:18 <wilhelm> Definition of a valid date string: http://www.w3.org/html/wg/drafts/html/master/infrastructure.html#valid-date-string
20:03:26 <andreastt> sstewart6: What is a valid date string?
20:03:36 <andreastt> wilhelm: The spec includes saniation for any string.
20:03:41 <andreastt> sstewart6: We could do that.
20:03:50 <andreastt> sstewart6: How do we cope with the case where the multiple attribute has been set?
20:03:53 <andreastt> fisherii: For file uplods?
20:04:01 <andreastt> sstewart6: File is one, but I think they can all have multiple.
20:04:20 <andreastt> sstewart6: Now the problem is that our sendKeys API already takes a list.
20:04:25 <wilhelm> The multiple attribute: http://www.w3.org/html/wg/drafts/html/master/forms.html#the-multiple-attribute
20:05:12 <andreastt> fisherii: It could just send it, and and send it, until you hit clear.
20:05:14 <andreastt> sstewart6: That might work.
20:05:19 <andreastt> fisherii: Just continue appending it on.
20:05:33 <andreastt> sstewart6: I think they can all take multiple values, although it makes no sense.
20:05:40 <andreastt> fisherii: What does that look like in the frontend?
20:05:46 <andreastt> wilhelm: Several emails make sense.
20:05:55 <andreastt> fisherii: Yes, appending to an email field makes sense.
20:06:22 <andreastt> sstewart6: Should we just say “we will attempt to add an extra element, unless multiple isn't set and the browser supports the new HTML5 _and_, yeah”.
20:07:10 <andreastt> fisherii: We use well-formatted strings to send keys as defined by the HTML5 spec, and if the field has multiple attribute it just appends another field, and you could clear it using the clear() API.
20:07:30 <andreastt> jimevans: Not all of them accept @multiple.
20:07:51 <andreastt> jimevans: For example for INPUT @type="tel".
20:08:07 <andreastt> It's valid on the INPUT element, but it does not apply.
20:08:12 <andreastt> fisherii: Yeah, it's non-normative.
20:08:23 <andreastt> gdennis: What happens with the select boxes?
20:08:27 <andreastt> sstewart6: Select isn't an input.
20:08:35 <andreastt> fisherii: We don't have to worry about select in this case.
20:08:52 <andreastt> fisherii: And select.  You click on each item.
20:09:07 <andreastt> gdennis: Yes, there are multiple, individual actions on the wire protocol level.
20:09:50 <andreastt> sstewart6: If multiple isn't supported, append as we do currently with text or unspecified.
20:10:06 <andreastt> sstewart6: We're going to be providing utility classes.
20:10:20 <andreastt> fisherii: So we're going to have to throw an exception if they try to enter another colour?
20:10:30 <andreastt> Except for password, telephone, text, date, colour.
20:10:44 <andreastt> sstewart6: Files are handled in a very strange way.
20:11:08 <JohnJansen_> JohnJansen_ has joined #testing
20:11:10 <andreastt> sstewart6: We upload the file to the remote end, have it return the path …
20:11:55 <andreastt> Discussion about driver specific INPUT @type="file" implementations.
20:12:32 <andreastt> fisherii: Maybe we just throw exceptions for values you can't append to without clearing?
20:12:43 <andreastt> Presumably all of these can have default values.
20:12:59 <andreastt> fisherii: So do you have to clear it before setting it?
20:13:06 <andreastt> andreastt: Yes, replacement makes sense.
20:13:14 <andreastt> sstewart6: So we do replacements for the ones we can do
20:13:20 <JohnJansen> JohnJansen has joined #testing
20:13:41 <andreastt> sstewart6: Replacements for dates, times, numeric inputs (number and range), colour, file upload.
20:13:57 <andreastt> sstewart6: And we do append for text, telephone, url, email, password.
20:14:23 <andreastt> fisherii: These aren't supported by all browsers.
20:14:29 <andreastt> fisherii: So are we smart about detecting the type?
20:14:35 <andreastt> fisherii: The attribute is still there.
20:14:48 <andreastt> sstewart6: We will do an append, because the input type is text.
20:15:33 <andreastt> sstewart6: If I go to the demo page with a browser that doesn't support the HTML5 controls, you'd only get text inputs.
20:15:45 <andreastt> gdennis: The property will still be text.
20:16:08 <andreastt> sstewart6: Yes, that's the difference between attributs and properties.
20:17:00 <andreastt> fisherii: And getAttribute would return "color" right?
20:17:07 <andreastt> sstewart6: yes, because the attribute is defined as so.
20:17:13 <andreastt> sstewart6: And actually that's what people would actually expect, right?
20:17:18 <andreastt> fisherii: I think that's reasonable.
20:17:21 <andreastt> fisherii: So.
20:17:42 <andreastt> fisherii: Replace or append for send keys depending on the multiple attribute.
20:18:07 <andreastt> gdennis: Can you clarify what happens in the wire protocol?
20:18:20 <andreastt> sstewart6: Normally we just send the the keys across the protocol.
20:18:29 <andreastt> sstewart6: Unless the string matches a local file.
20:18:33 <andreastt> sstewart6: And you have the LocalFileDetector.
20:18:40 <andreastt> sstewart6: You upload that to the remote end.
20:19:02 <andreastt> gdennis: You'd still use the sendKeys() command for all of these?
20:19:04 <andreastt> sstewart6: yes.
20:19:06 <andreastt> jimevans: Yes.
20:19:19 <andreastt> gdennis: It would be a bad idea to have a select command?
20:19:43 <andreastt> jimevans: The proposal for language bindings would be to expose a wrapper element type.
20:19:56 <andreastt> jimevans: Which under the covers would call sendKeys with the correctly formatted strings.
20:20:06 <andreastt> sstewart6: So the idea is that we have as little in the spec as possible.
20:20:32 <andreastt> fisherii: It's really that we're taking advantage that the _output_ of the input fields return plain strings.
20:20:40 <andreastt> jimevans: Viewport!
20:20:42 <andreastt> sstewart6: Canvas!
20:20:50 <andreastt> wilhelm: Should we validte?
20:21:01 <andreastt> sstewart6: If a user calls sendKeys() directly they're welcome to send whatever they want.
20:21:12 <andreastt> sstewart6: But that would be the remote end telling us you can't.
20:21:32 <andreastt> sstewart6: The language bindings would have utilities thta would make it easy to use these things without messing up.
20:22:26 <andreastt> gdennis: Even if modern browsers implement this would it be posisble for users to attach something else to it?
20:24:56 <andreastt> sstewart6: Are we content with that?
20:25:04 <andreastt> jimevans: I'm happy with that.  It's what I wanted to do anyways.
20:25:16 <andreastt> jimevans: Support classes, which are more discoverable than role based interfaces.
20:25:44 <andreastt> sstewart6: Okay.
20:29:29 <sstewart6> http://selenium.googlecode.com/git/docs/api/java/org/openqa/selenium/security/UserAndPassword.html
20:31:42 <andreastt> Resolution: Default behaviour for something that has a property of type that is text, is to append.  If the browser supports the particular type (Fx not doing color), if the input is correct formatted we will set the value to whatever it is, otherwise throw exception. If the value is multiple and the browser understands the concept of multiple, otherwise it will be appeneded unless it's a file input element in which case it will be replaced.
20:31:50 <sstewart6> Something like that.
20:33:49 <andreastt> particular type _and_ if the
20:34:17 <abarsto> abarsto has joined #testing
20:34:41 <wilhelm> </meeting><pub>
20:34:47 <wilhelm> RRSAgent, draft minutes
20:34:47 <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html wilhelm
20:34:58 <sstewart6> Resolution: If the multiple property has been set and the browser supports the multiple property, new separate values will be added, otherwise the value will be replaced.
20:35:04 <wilhelm> RRSAgent, draft minutes
20:35:04 <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html wilhelm
20:35:26 <gdennis> gdennis has left #testing
20:35:28 <wilhelm> RRSAgent, bye
20:35:45 <wilhelm> RRSAgent, make logs public
20:35:48 <wilhelm> RRSAgent, bye
20:35:48 <RRSAgent> I see 5 open action items saved in http://www.w3.org/2013/06/13-testing-actions.rdf :
20:35:48 <RRSAgent> ACTION: Group will meet in the #testing channel on July 12th, to work on spec and test suite together [1]
20:35:48 <RRSAgent>   recorded in http://www.w3.org/2013/06/13-testing-irc#T17-32-19
20:35:48 <RRSAgent> ACTION: JohnJansen will share annotations on needed tests [2]
20:35:48 <RRSAgent>   recorded in http://www.w3.org/2013/06/13-testing-irc#T17-43-27
20:35:48 <RRSAgent> ACTION: JohnJansen to investigate feasibility of running the Python-based test suite at MS [3]
20:35:48 <RRSAgent>   recorded in http://www.w3.org/2013/06/13-testing-irc#T17-57-08
20:35:48 <RRSAgent> ACTION: AutomatedTester will update the proposal for touch primitives and send it out for review [4]
20:35:48 <RRSAgent>   recorded in http://www.w3.org/2013/06/13-testing-irc#T19-18-44
20:35:48 <RRSAgent> ACTION: AutomatedTester finish his strawman proposal. [5]
20:35:48 <RRSAgent>   recorded in http://www.w3.org/2013/06/13-testing-irc#T19-31-52