/irc-logs / w3c / #testing / 2013-06-13 / end

Options:

  1. # Session Start: Thu Jun 13 00:00:00 2013
  2. # Session Ident: #testing
  3. # [01:52] * heycam|away is now known as heycam
  4. # [01:54] * Quits: jhammel (~jhammel@public.cloak) ("leaving")
  5. # [03:15] * Quits: abarsto (~abarsto@public.cloak) ("Leaving.")
  6. # [03:30] * Joins: zqzhang (~zqzhang@public.cloak)
  7. # [03:44] * Joins: gitbot (~gitbot@public.cloak)
  8. # [03:44] -gitbot:#testing- [web-platform-tests] hayatoito pushed 2 new commits to master: https://github.com/w3c/web-platform-tests/compare/cf97f8093080...167a1e39a098
  9. # [03:44] -gitbot:#testing- web-platform-tests/master 3271a27 Yuta Kitamura: shadow-dom: Refine script tests related to ownerDocument property....
  10. # [03:44] -gitbot:#testing- web-platform-tests/master 167a1e3 Hayato Ito: Merge pull request #220 from yutak/shadow-dom/ownerdocument...
  11. # [03:44] * Parts: gitbot (~gitbot@public.cloak) (gitbot)
  12. # [06:21] * heycam is now known as heycam|away
  13. # [06:38] * heycam|away is now known as heycam
  14. # [07:11] * heycam is now known as heycam|away
  15. # [07:27] * heycam|away is now known as heycam
  16. # [08:26] * heycam is now known as heycam|away
  17. # [08:37] * heycam|away is now known as heycam
  18. # [09:32] * Joins: Ms2ger (~Ms2ger@public.cloak)
  19. # [10:06] * heycam is now known as heycam|away
  20. # [10:45] * Joins: darobin (rberjon@public.cloak)
  21. # [10:55] * Quits: zqzhang (~zqzhang@public.cloak) ("Page closed")
  22. # [12:30] * Joins: abarsto (~abarsto@public.cloak)
  23. # [12:30] * abarsto is now known as ArtB
  24. # [13:55] * Joins: darobin_ (rberjon@public.cloak)
  25. # [13:55] * Quits: darobin (rberjon@public.cloak) (Client closed connection)
  26. # [13:56] * Joins: darobin (rberjon@public.cloak)
  27. # [13:56] * Quits: darobin_ (rberjon@public.cloak) (Client closed connection)
  28. # [14:56] * Joins: JohnJansen (~JohnJansen@public.cloak)
  29. # [15:02] * Joins: RRSAgent (rrsagent@public.cloak)
  30. # [15:03] <RRSAgent> logging to http://www.w3.org/2013/06/13-testing-irc
  31. # [15:03] * Joins: plh (plehegar@public.cloak)
  32. # [15:04] <wilhelm> Meeting: WebDriver F2F, June 13th 2013
  33. # [15:04] <wilhelm> Agenda: http://www.w3.org/wiki/WebDriver/2013-June-F2F
  34. # [15:08] <Ms2ger> RRSAgent, make logs public
  35. # [15:08] <RRSAgent> I have made the request, Ms2ger
  36. # [15:10] <wilhelm> RRSAgent, draft minutes
  37. # [15:10] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html wilhelm
  38. # [15:10] <wilhelm> RRSAgent, make logs public
  39. # [15:10] <RRSAgent> I have made the request, wilhelm
  40. # [15:12] * Joins: sstewart6 (~simons@public.cloak)
  41. # [15:12] <sstewart6> Hello everybody!
  42. # [15:13] <Ms2ger> G'day
  43. # [15:13] * plh waves
  44. # [15:13] * Joins: AutomatedTester (~AutomatedTester@public.cloak)
  45. # [15:13] * Joins: eranm (~eranm@public.cloak)
  46. # [15:15] <wilhelm> Agenda: http://www.w3.org/wiki/WebDriver/2013-June-F2F
  47. # [15:15] * Ms2ger changes topic to 'http://www.w3.org/wiki/WebDriver/2013-June-F2F'
  48. # [15:15] * Joins: fisherii (~fisherii@public.cloak)
  49. # [15:15] * Joins: jimevans (~jimevans@public.cloak)
  50. # [15:15] <plh> rrsagent, generate minutes
  51. # [15:15] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html plh
  52. # [15:15] * Joins: chrisgao (~chrisgao@public.cloak)
  53. # [15:15] <Ms2ger> s/Hello everybody!//
  54. # [15:15] <Ms2ger> s/G'day//
  55. # [15:15] <plh> Chair: Wilhelm
  56. # [15:16] <Ms2ger> rrsagent, generate minutes
  57. # [15:16] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html Ms2ger
  58. # [15:16] <plh> Present+ Plh
  59. # [15:16] <wilhelm> Present+ Wilhelm
  60. # [15:16] * Joins: ato (~ato@public.cloak)
  61. # [15:16] <jimevans> Present+ jimevans
  62. # [15:16] * ato is now known as andreastt
  63. # [15:16] <JohnJansen> Present+ JOhnJansen
  64. # [15:16] <sstewart6> Present+ sstewart6
  65. # [15:17] <andreastt> Present+ andreastt
  66. # [15:17] <wilhelm> RRSAgent, draft minutes
  67. # [15:17] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html wilhelm
  68. # [15:17] <AutomatedTester> Present+ AutomatedTester
  69. # [15:17] * Joins: kkania (~kkania@public.cloak)
  70. # [15:17] <JohnJansen> Present+ JohnJansen
  71. # [15:17] <fisherii> Present+ fisherii
  72. # [15:17] <AutomatedTester> Present+ DavidBurns
  73. # [15:17] <Ms2ger> s/Agenda: http://www.w3.org/wiki/WebDriver/2013-June-F2F//
  74. # [15:17] <sstewart6> Present+ SimonStewart
  75. # [15:17] <kkania> Present+ KenKania
  76. # [15:17] <fisherii> Present+ MarcFisher
  77. # [15:18] <plh> rrsagent, generate minutes
  78. # [15:18] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html plh
  79. # [15:19] <sstewart6> Who's scribing?
  80. # [15:19] <wilhelm> Scribe: wilhelm
  81. # [15:19] <wilhelm> (Introductions.)
  82. # [15:19] <sstewart6> Thanks :)
  83. # [15:19] <Ms2ger> Scribenick: wilhelm
  84. # [15:19] <Ms2ger> RRSAgent, generate minutes
  85. # [15:19] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html Ms2ger
  86. # [15:20] * jgraham in which Ms2ger secretaries (is that a verb) a meeting from half the world away
  87. # [15:21] <wilhelm> Topic: State of the union
  88. # [15:21] <wilhelm> sstewart6: The spec is the laggiest part of the work we're oing.
  89. # [15:21] <wilhelm> We just had SeConfg. Just before that, Google released ChromeDriver 2.
  90. # [15:21] <wilhelm> Adds support for mobile.
  91. # [15:21] <Ms2ger> RRSAgent, generate minutes
  92. # [15:21] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html Ms2ger
  93. # [15:21] <wilhelm> Mozilla announced Marionette.
  94. # [15:21] <wilhelm> It will be in Firefox 24.
  95. # [15:22] <wilhelm> We announced Selenium 3, where the project gets rid of the old APIs.
  96. # [15:22] <wilhelm> The spec does not reflect the current work.
  97. # [15:22] * Ms2ger leaves the secretarying to those present
  98. # [15:22] <wilhelm> We content on everything but the wire protocol.
  99. # [15:22] <wilhelm> The test suite also requires work.
  100. # [15:22] <wilhelm> Every implementation uses the Selenium project test suite currently.
  101. # [15:23] <wilhelm> We made the wire protocol mandatory.
  102. # [15:23] <wilhelm> AutomatedTester: Mozilla has an implementation of touch we'd like to discuss.
  103. # [15:23] * Joins: blessmurk (~blessmurk@public.cloak)
  104. # [15:24] <wilhelm> sstewart6: People are extending Selenium to test native mobile. This work falls outside the scope of this group. See the Selenium project.
  105. # [15:24] <wilhelm> sstewart6: Other big news: Opera is now using the Chromium engine.
  106. # [15:24] <wilhelm> ChromeDriver 2 supports Opera, no?
  107. # [15:24] <wilhelm> andreastt: That's the plan, but it's not yet ready in Opera 15.
  108. # [15:25] <blessmurk> y o y
  109. # [15:25] <sstewart6> http://www.w3.org/wiki/WebDriver/2013-June-F2F
  110. # [15:25] <wilhelm> Chair: sstewart6
  111. # [15:25] <wilhelm> (Reading through the agenda, see above URL.)
  112. # [15:29] <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.
  113. # [15:32] <MikeSmith> Zakim, call Mike
  114. # [15:32] <MikeSmith> Zakim, drop MIke
  115. # [15:33] <wilhelm> Topic: Performance logging
  116. # [15:34] <sstewart6> Relevant part of the spec: https://dvcs.w3.org/hg/webdriver/raw-file/tip/webdriver-spec.html#logging
  117. # [15:34] <sstewart6> It's currently empty :)
  118. # [15:34] <wilhelm> Michael: What I'm proposing is to adda a field to log endry called data, which is arbitrary JSON.
  119. # [15:35] <wilhelm> s/endry/entry
  120. # [15:35] <sstewart6> Current OSS webdriver wire protocol: https://code.google.com/p/selenium/wiki/JsonWireProtocol#/session/:sessionId/log
  121. # [15:35] <sstewart6> Representation as Java: http://selenium.googlecode.com/git/docs/api/java/org/openqa/selenium/logging/LogEntry.html
  122. # [15:36] <wilhelm> sstewart6: (Refers to the links above.)
  123. # [15:36] * Joins: Zakim (zakim@public.cloak)
  124. # [15:36] * Joins: brma (~bmannix@public.cloak)
  125. # [15:36] * Joins: gdennis (~Adium@public.cloak)
  126. # [15:36] <wilhelm> sstewart6: Looking at the interface definition from Java, it sounds like you're proposing we add another method to that.
  127. # [15:36] <wilhelm> Michael: Yes.
  128. # [15:37] <wilhelm> sstewart6: It would be a map of string to object.
  129. # [15:37] <sstewart6> Suggestion: adding a map/dictionary of string->object
  130. # [15:37] <sstewart6> :)
  131. # [15:37] <wilhelm> eranm: Question on context: Does the log entry makes sense with data and nothing else?
  132. # [15:37] <wilhelm> Michael: Yes.
  133. # [15:37] <wilhelm> It's not really for human consumption.
  134. # [15:37] <wilhelm> eranm: This will be distinguishable from the log type.
  135. # [15:38] <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.
  136. # [15:38] <wilhelm> There are also intermediate nodes in the chain (f.x. SauceLabs).
  137. # [15:38] <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.
  138. # [15:39] <wilhelm> We have log types.
  139. # [15:39] <wilhelm> Exposed through an API.
  140. # [15:39] <wilhelm> "Get me the logs of this particular type."
  141. # [15:39] <MikeSmith> RRSAgent, make minutes
  142. # [15:39] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html MikeSmith
  143. # [15:39] <MikeSmith> RRSAgent, make logs public
  144. # [15:39] <RRSAgent> I have made the request, MikeSmith
  145. # [15:39] <wilhelm> Michael: I'm working under the assumption that these are browser specific.
  146. # [15:40] <MikeSmith> Zakim, call Mike
  147. # [15:40] <Zakim> sorry, MikeSmith, I don't know what conference this is
  148. # [15:40] <wilhelm> I'm just requesting an [opaque] data field.
  149. # [15:40] <wilhelm> JohnJansen: This seems right to me.
  150. # [15:40] <wilhelm> A new data field makes sense to me, at a high level.
  151. # [15:41] <wilhelm> eranm: We would find it useful for getting profiling data.
  152. # [15:41] <MikeSmith> Zakim, this will be WTA_BTTWG
  153. # [15:41] <Zakim> ok, MikeSmith; I see WTA_BTTWG(TSTMIT)9:00AM scheduled to start 41 minutes ago
  154. # [15:41] <wilhelm> It seems related, but might not be in the same format as this proposal.
  155. # [15:41] <MikeSmith> Zakim, call Mike
  156. # [15:41] <Zakim> ok, MikeSmith; the call is being made
  157. # [15:41] <Zakim> WTA_BTTWG(TSTMIT)9:00AM has now started
  158. # [15:41] <Zakim> +Mike
  159. # [15:41] <wilhelm> sstewart6: We should probably leave the data format undefined for now.
  160. # [15:42] <wilhelm> plh: The web performance working group has a HAR format.
  161. # [15:42] <wilhelm> Michael: I have reservations about that.
  162. # [15:42] <wilhelm> plh: You should raise these with the web performance WG.
  163. # [15:43] <wilhelm> plh: We are working on disagnostic APIs and the ability to do some logging. Early in the process.
  164. # [15:43] <wilhelm> plh: There is work happening, within the browser itself.
  165. # [15:43] <wilhelm> sstewart6: We can already return logs from the J2E server. Those formats are not well defined.
  166. # [15:44] <wilhelm> There is value in standardizing specific formats. I don't know if we can do that here.
  167. # [15:44] <wilhelm> plh: What logs do you have?
  168. # [15:44] <wilhelm> sstewart6: At what point was the flake in the flaky test introduced?
  169. # [15:44] <wilhelm> We wanted logs from each moving part.
  170. # [15:44] <wilhelm> We could do an aggregated log, or display separately.
  171. # [15:45] <wilhelm> Useful diagnostic tool.
  172. # [15:45] <wilhelm> JS errors is a classic example.
  173. # [15:45] <wilhelm> Not every browser exposes this.
  174. # [15:45] <wilhelm> We need an API to query available log types.
  175. # [15:46] <wilhelm> Do we have standardized names for log types?
  176. # [15:46] * Joins: klepikovm (~801f23f0@public.cloak)
  177. # [15:46] <wilhelm> What if there are clashes?
  178. # [15:46] * plh Mike, I'm still trying to figure how to set up the polycom
  179. # [15:46] <wilhelm> Should we circle back to this later?
  180. # [15:46] <wilhelm> AutomatedTester: Yes.
  181. # [15:46] <wilhelm> AutomatedTester: I don't see it being too contentious.
  182. # [15:47] <wilhelm> sstewart6: The proposal is an undefined JSON blob.
  183. # [15:47] <wilhelm> We should put thought into how to name log types.
  184. # [15:47] <wilhelm> Do anyone need thinking time?
  185. # [15:47] <wilhelm> jimevans: Yes.
  186. # [15:47] <wilhelm> sstewart6: We'll revisit this after lunch.
  187. # [15:49] <wilhelm> Topic: Visibility of elements
  188. # [15:49] <wilhelm> Chair: AutomatedTester
  189. # [15:49] <wilhelm> Chair: Greg
  190. # [15:49] <wilhelm> sstewart6: Greg has been working on the browser automation atoms.
  191. # [15:50] <wilhelm> One of these is isdisplayed.
  192. # [15:50] <wilhelm> gdennis: I've been working on this for a year.
  193. # [15:50] <wilhelm> Overflow is complicated.
  194. # [15:50] * MikeSmith plh no problem, the silence is calming :-)
  195. # [15:50] <sstewart6> The Automation Atoms on the selenium wiki: https://code.google.com/p/selenium/wiki/AutomationAtoms
  196. # [15:50] <wilhelm> The relationship between visibility and interactability.
  197. # [15:50] <sstewart6> The current source of the atoms: https://code.google.com/p/selenium/source/browse/#git%2Fjavascript%2Fatoms
  198. # [15:50] <wilhelm> The spec currently says that to be interactable, you must be visible.
  199. # [15:50] <wilhelm> I'm not sure that's the case.
  200. # [15:51] <wilhelm> I don't think we should put that in the spec.
  201. # [15:51] <wilhelm> One issue is opacity.
  202. # [15:51] <wilhelm> In the current JS implementation, a transparent element is not visible.
  203. # [15:51] <wilhelm> But it is interactable.
  204. # [15:51] <wilhelm> These are two separate questions.
  205. # [15:52] <wilhelm> (Quoting the spec on visibility.)
  206. # [15:52] <AutomatedTester> https://dvcs.w3.org/hg/webdriver/raw-file/tip/webdriver-spec.html#determining-visibility
  207. # [15:52] <wilhelm> gdennis: I wonder if we can get away with being a little vague.
  208. # [15:52] <wilhelm> An element is shown if a human user can see it.
  209. # [15:53] * Quits: klepikovm (~801f23f0@public.cloak) ("http://www.mibbit.com ajax IRC Client")
  210. # [15:53] <wilhelm> gdennis: Does something have to be scrolled into view to be visible?
  211. # [15:53] <wilhelm> The atoms say this is not necessary.
  212. # [15:53] * Ms2ger RRSAgent, generate minutes
  213. # [15:53] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html Ms2ger
  214. # [15:53] <wilhelm> THere are practical benefits to this.
  215. # [15:53] <wilhelm> "Is something visible on the page?"
  216. # [15:53] <wilhelm> There is a moral argument against it in that a user can't actually see it.
  217. # [15:54] <wilhelm> UI sometimes make scrollable things that don't have scrollbars.
  218. # [15:54] <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)
  219. # [15:54] <wilhelm> JohnJansen: It's not binary.
  220. # [15:54] <wilhelm> This thing is on the page, but not visible.
  221. # [15:55] <wilhelm> sstewart6: "Could it be made visible?"
  222. # [15:55] <wilhelm> "Is it within the viewport?"
  223. # [15:55] <wilhelm> Finding the viewport is difficult.
  224. # [15:55] <wilhelm> Is a spec defining a viewport?
  225. # [15:55] <wilhelm> JohnJansen: CSS is attempting it.
  226. # [15:55] <wilhelm> AutomatedTester: getboundingclientrect is based on viewport.
  227. # [15:55] <wilhelm> It must be defined somewhere.
  228. # [15:56] <wilhelm> CSS3 Transforms depend on this.
  229. # [15:56] <wilhelm> gdennis: The closure implementation of getting the viewport is quite accurate.
  230. # [15:56] <wilhelm> AutomatedTester: scrollx, scrolly tells you how far you've scrolled.
  231. # [15:56] <JohnJansen> this might help: http://dev.w3.org/csswg/css-device-adapt/#the-viewport
  232. # [15:57] <wilhelm> sstewart6: I'm happy to rely on this definition.
  233. # [15:57] <sstewart6> Sounds like we mean: http://dev.w3.org/csswg/css-device-adapt/#actual-viewport
  234. # [15:58] <sstewart6> wilhelm^ http://dev.w3.org/csswg/css-device-adapt/#actual-viewport
  235. # [15:58] <wilhelm> gdennis: If you want to say, "is it scrolled into view?", that's a separate question.
  236. # [15:58] * ArtB RRSAgent, make minutes
  237. # [15:58] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html ArtB
  238. # [15:58] <wilhelm> andreastt: It's also impractical if you want to determine if a button is clickable.
  239. # [15:59] <wilhelm> sstewart6: "Can I scroll this into view?"
  240. # [15:59] <plh> zakim, passcode?
  241. # [15:59] <Zakim> the conference code is 878648 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), plh
  242. # [16:00] <wilhelm> gdennis: Interactability vs visibility.
  243. # [16:00] <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)
  244. # [16:01] <wilhelm> fisherii: From the point of view of test authoring, we need to be able to determine if we can interact with an element.
  245. # [16:01] * plh Mike, we'll be on the bridge in 2 minutes
  246. # [16:01] * MikeSmith cool
  247. # [16:02] <wilhelm> (Discussion on opacity and bubbling.)
  248. # [16:02] <Zakim> + +1.617.715.aaaa
  249. # [16:03] <plh> zakim, aaaa is MIT_Room
  250. # [16:03] <Zakim> +MIT_Room; got it
  251. # [16:03] <wilhelm> jimevans: Should we define interactability, and expose it?
  252. # [16:03] <wilhelm> sstewart6: Yes.
  253. # [16:03] * plh zakim, who is on the phone?
  254. # [16:03] * Zakim sees on the phone: Mike, MIT_Room
  255. # [16:03] * MikeSmith hears sounds... faintly
  256. # [16:03] <wilhelm> fisherii: The criteria for sendkeys vs click may be different.
  257. # [16:03] * plh Mike, sorry for the delay. had to get the polycom from the MIT IT folks
  258. # [16:03] <wilhelm> gdennis: It might be interactable for one type of action, but not the other.
  259. # [16:04] <wilhelm> fisherii: You could tab into a field that is hidden.
  260. # [16:04] * plh Mike, the polycom is right in the middle of us...
  261. # [16:04] * plh Mike, stil hearing faintly?
  262. # [16:04] <wilhelm> JohnJansen: You may even be able to tab into a disabled element.
  263. # [16:04] * MikeSmith plh yeah, can just barely hear anything at all. Can't really even make out any words. But maybe not worth trying to fix. Not sure if we are going to have anybody else calling oin.
  264. # [16:05] <wilhelm> fisherii: Handling of disabled elements vary between implementations.
  265. # [16:05] <sstewart6> MikeSmith: can you hear me?
  266. # [16:05] <sstewart6> Is it just that people need to speak louder?
  267. # [16:05] <wilhelm> gdennis: If something is typable or not clicking, clicking would just be a noop.
  268. # [16:05] <wilhelm> sstewart6: We seem to have inconsistent behaviour between browsers.
  269. # [16:05] <MikeSmith> sstewart6: can't hear you at all. And it's not going to help if people speak lounde,r I think
  270. # [16:05] <wilhelm> Standardizing this will be tricky.
  271. # [16:06] <sstewart6> I'm the loudest person in the room :)
  272. # [16:06] <wilhelm> gdennis: Can we define this by definiting a minimum?
  273. # [16:06] <MikeSmith> sstewart6: seems like the mic isn't picking up much of anything
  274. # [16:06] * MikeSmith will try dropping and calling back in
  275. # [16:06] * plh Mike, can't find settings to change the microphone volume :-/
  276. # [16:07] <Zakim> -Mike
  277. # [16:07] <MikeSmith> Zakim, call Mike
  278. # [16:07] <Zakim> ok, MikeSmith; the call is being made
  279. # [16:07] <wilhelm> sstewart6: What are the meaningful conformance tests we want added?
  280. # [16:07] <Zakim> +Mike
  281. # [16:07] * plh Mike, try to speak up a bit
  282. # [16:07] <wilhelm> gdennis: You could create a test suite with the minimum conditions we want to impose.
  283. # [16:07] <wilhelm> ... Implied tests, "if this is true on this browser.."
  284. # [16:08] * plh Mike, yes, we can hear clear
  285. # [16:08] <wilhelm> gdennis: Capabilities?
  286. # [16:08] * plh still faint on your side?
  287. # [16:08] <wilhelm> sstewart6: I want a meaningful list of tests to add to the spec.
  288. # [16:08] * MikeSmith hmm, I still can't hear you there. Just kind of .. mumbling sound
  289. # [16:09] * plh I can try to restart the polycom
  290. # [16:09] <wilhelm> sstewart6: "Could you interact with the body?"
  291. # [16:09] <wilhelm> gdennis: Not if it's zero size.
  292. # [16:09] <Zakim> -MIT_Room
  293. # [16:09] <wilhelm> sstewart6: Wouldn't the body fill the whole viewport?
  294. # [16:09] <wilhelm> (Yes.)
  295. # [16:09] <wilhelm> sstewart6: What about a disabled input element?
  296. # [16:09] <wilhelm> fisherii: You can click on it.
  297. # [16:10] <wilhelm> sstewart6: You could fire a click on it, but it would be meaningless.
  298. # [16:10] <wilhelm> fisherii: Doesn't it fire events?
  299. # [16:10] <plh> zakim, passcode?
  300. # [16:10] <Zakim> the conference code is 878648 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), plh
  301. # [16:10] <wilhelm> AutomatedTester: I think it ignores the events.
  302. # [16:10] <Zakim> +MIT_Room
  303. # [16:11] * plh how about now?
  304. # [16:11] * plh zakim, call plh-mobile
  305. # [16:11] * Zakim ok, plh; the call is being made
  306. # [16:11] <Zakim> +Plh
  307. # [16:11] <wilhelm> data:text/html;charset=utf-8,<input%20disabled%20onclick%3D'alert(1)'>
  308. # [16:12] * MikeSmith plh just heard you re-join but still can't hear voices clearly at all. Very faint
  309. # [16:12] <wilhelm> eranm: So when is an element is not interactable?
  310. # [16:12] <Zakim> -Plh
  311. # [16:12] * MikeSmith plh can your hear OK from your mobile?
  312. # [16:12] <wilhelm> sstewart6: If it lies under another totally transparent element and it not in the tabindex.
  313. # [16:12] * plh nope
  314. # [16:12] * MikeSmith ok
  315. # [16:12] <wilhelm> Unless the above element bubbles events.
  316. # [16:12] <wilhelm> JohnJansen: ARIA.
  317. # [16:13] * MikeSmith I just sorta heard you guys laugh at least
  318. # [16:13] <wilhelm> andreastt: Do we want to expose both?
  319. # [16:14] <wilhelm> sstewart6: I don't know if there's any value in exposing interactable? to a user.
  320. # [16:14] * plh Mike, I asked the MIT IT folks to come and check the polycom
  321. # [16:14] * MikeSmith ok
  322. # [16:14] * plh this will probably take 5-10 minutes at least
  323. # [16:14] <wilhelm> (Tabbing to invisible elements.)
  324. # [16:15] <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.
  325. # [16:15] * MikeSmith ok, sounds seems to getting slightly better now , for whatever reason
  326. # [16:16] <wilhelm> gdennis: A user may want to interact with a transparent element.
  327. # [16:16] * plh zakim, call plh-mobile
  328. # [16:16] * Zakim ok, plh; the call is being made
  329. # [16:16] <Zakim> +Plh
  330. # [16:16] <Zakim> -Plh
  331. # [16:16] <wilhelm> gdennis: Use case: UI with transparent element that turns visible onmouseover.
  332. # [16:17] * plh Mike, it seems doing better now
  333. # [16:17] <wilhelm> sstewart6: The action element lets you specify an x/y coordinate to interact with.
  334. # [16:17] * plh the sysguy is going to bring an external microphone
  335. # [16:18] <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.
  336. # [16:18] * MikeSmith plh, yeah, sound did get better already. External mic might help more too I guess
  337. # [16:18] <wilhelm> fisherii: People expect to be able to click something, but there may be a transparent element in the way. ChromeDriver throws an exception.
  338. # [16:18] <wilhelm> That might be undesirale behaviour.
  339. # [16:19] * Joins: mdas (~mdas@public.cloak)
  340. # [16:19] <wilhelm> sstewart6: There are two versions of click: Actions API, WebElement.
  341. # [16:19] <plh> rrsagent, generate minutes
  342. # [16:19] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html plh
  343. # [16:19] <wilhelm> "Do what I say" vs "Do what I mean".
  344. # [16:20] <wilhelm> fisherii: There's different behaviour between Chrome and Firefox.
  345. # [16:20] <wilhelm> sstewart6: For some of this, you need access to the render tree.
  346. # [16:21] * Joins: marilyn_ (~marilyn@public.cloak)
  347. # [16:21] <wilhelm> JohnJansen: The differences between browsers mean that one of them is not compliant.
  348. # [16:21] <wilhelm> fisherii: In Firefox, this was like firing the event directly on the element.
  349. # [16:22] <wilhelm> JohnJansen: Which is mandated by the spec?
  350. # [16:22] <wilhelm> sstewart6: Probably Chrome.
  351. # [16:22] <wilhelm> JohnJansen: We've been looking at this in IE.
  352. # [16:22] <wilhelm> Certain version of IE handles this differently.
  353. # [16:23] <wilhelm> I just want to make sure we are basing tests on specs, not browser implementations.
  354. # [16:23] <wilhelm> sstewart6: How do we define interactability?
  355. # [16:24] <wilhelm> JohnJansen: (Describing a bug with floats and fractional pixels.)
  356. # [16:24] * Quits: mdas (~mdas@public.cloak) ("Leaving...")
  357. # [16:25] <wilhelm> I need the distinction between immedately visible and requiring scrolling to be visible.
  358. # [16:25] <wilhelm> JohnJansen: One of these tests should pass, and the other should fail. (visible / interactable)
  359. # [16:26] <wilhelm> gdennis: "The browser window size is different, my test breaks"
  360. # [16:26] <wilhelm> fisherii: (Refers to CSS spec on viewports.)
  361. # [16:27] <wilhelm> fisherii: Scrollable divs are handled differently.
  362. # [16:27] <wilhelm> sstewart6: I'm glad this is easy.
  363. # [16:27] <AutomatedTester> http://www.w3.org/TR/CSS21/visuren.html#viewport
  364. # [16:28] <wilhelm> sstewart6: So we're using the CSS 2.1 definition now?
  365. # [16:28] <wilhelm> How does that handle frames?
  366. # [16:29] <wilhelm> ACTION: JohnJansen to ask the CSS WG which definition of viewport, etc., we want to use
  367. # [16:29] * RRSAgent records action 1
  368. # [16:30] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
  369. # [16:30] <wilhelm> sstewart6: Given sane definitions here, this is further complicated by: z-index, tabindex
  370. # [16:30] <wilhelm> fisherii: If we're not going to expose this to the user, we can talk about clickable and typable as separate properties.
  371. # [16:31] <wilhelm> sstewart6: (Explains why disabled elements are clickable in the WebDriver API.)
  372. # [16:32] <wilhelm> sstewart6: "Would a user be able to interact with this element?"
  373. # [16:33] <wilhelm> If any opaque element is in the way, the element is not interactable unless you can tab to it.
  374. # [16:33] <wilhelm> fisherii: "Given the element was enabled, this is the element the event would go to"
  375. # [16:34] <wilhelm> gdennis: I thought I understand what I wanted...
  376. # [16:34] <wilhelm> Now I don't know anything anymore.
  377. # [16:34] <MikeSmith> RRSAgent, make minutes
  378. # [16:34] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html MikeSmith
  379. # [16:34] <wilhelm> jimevans: "It's all edge cases!"
  380. # [16:35] <wilhelm> andreastt: There is a list of edge cases we could make test against.
  381. # [16:36] <wilhelm> fisherii: Maybe you could only interact with elements you could add an onlick handler to.
  382. # [16:36] <wilhelm> fisherii: The actions API doesn't care about interactable.
  383. # [16:36] <wilhelm> sstewart6: Users don't know how browsers work.
  384. # [16:37] <wilhelm> fisherii: What elements can't you attach handlers to?
  385. # [16:37] <sstewart6> http://www.w3.org/TR/html401/sgml/dtd.html#events
  386. # [16:37] <MikeSmith> Present+ GregoryDennis
  387. # [16:38] <wilhelm> wilhelm: I'm not sure this is relevant anymore... What do current specs say?
  388. # [16:38] <Ms2ger> I can definitely tell you HTML4 isn't relevant anymore
  389. # [16:38] <wilhelm> AutomatedTester: The OSS project has users that still test against IE6.
  390. # [16:39] <wilhelm> JohnJansen: It's not necessarily a browser legacy issue that should be ignored.
  391. # [16:40] <wilhelm> wilhelm: We should just write the tests and extract the spec from that.
  392. # [16:42] <andreastt> https://dvcs.w3.org/hg/webdriver-test
  393. # [16:43] <wilhelm> ACTION: David Burns to lead the work on writing tests on visibility/interactivity
  394. # [16:43] * RRSAgent records action 2
  395. # [16:44] <wilhelm> jimevans: The spec says the "do what I mean" APIs should delegate down..
  396. # [16:45] <wilhelm> WebElement.click method should check for visibility, interactability, scroll into view, use advanced user interactions ...
  397. # [16:45] <wilhelm> sstewart6: That was the intention. There are edge cases.
  398. # [16:45] <wilhelm> sstewart6: (Selection of multiple elements.)
  399. # [16:46] <wilhelm> sstewart6: This brings us to ... partially visible elements in the viewport.
  400. # [16:47] * wilhelm : We now have a short pause.
  401. # [16:47] <wilhelm> Scribe: eranm
  402. # [16:47] <wilhelm> Chair: sstewart6
  403. # [16:47] <wilhelm> RRSAgent, draft minutes
  404. # [16:47] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html wilhelm
  405. # [17:00] * Joins: zcorpan (~zcorpan@public.cloak)
  406. # [17:02] * Joins: santeriv (~santeriv@public.cloak)
  407. # [17:07] <eranm> Topic: Visibility
  408. # [17:07] <eranm> sstewart6, first question on the agenda: what is considered visible? not the same as being interactable
  409. # [17:07] <eranm> AutomatedTester: ideally something you could see on the screen
  410. # [17:08] <eranm> AutomatedTester: If an element has text and is the same colour as the element, is it visible?
  411. # [17:08] <eranm> AutomatedTester: An element with the same colour as the element behind it
  412. # [17:08] <eranm> AutomatedTester: Also problems with opacity and partially hidden elements
  413. # [17:08] <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
  414. # [17:09] <eranm> fisherii: do you only mean the global scrollbar?
  415. # [17:09] <eranm> sstewart6: want to take out of the equation clever things like endless scrolling
  416. # [17:10] <eranm> sstewart6: the common use case: usage of web driver as a service, no access to the machine, can't set the resolution
  417. # [17:10] <eranm> fisherii: agree, be resolution-independent as possible
  418. # [17:10] <MikeSmith> Present+ MesseriEran
  419. # [17:11] <eranm> fisherii: scrollbars internal to the page feel different to the window scrollbars
  420. # [17:11] <eranm> gdennis: people create scrollable elements without scrollbars, which is a problem
  421. # [17:11] <eranm> sstewart6: we're not going to handle that
  422. # [17:12] <eranm> fisherii: we should stick to standards when it comes to respecting scrolling mechanisms
  423. # [17:12] <eranm> sstewart6: otherwise we'll have to run every code path hoping one of them will scroll
  424. # [17:12] <eranm> gdennis: users don't care.
  425. # [17:13] <eranm> wilhelm: we should define explicitly that we don't handle crazy custom scrolling cases
  426. # [17:13] <eranm> sstewart6: agree
  427. # [17:13] <eranm> sstewart6: already defined this for taking screenshots
  428. # [17:13] <eranm> JohnJansen: when scrollbars aren't visible until you hover, web driver should understand that the scrollbars exist ever if not displayed
  429. # [17:14] <eranm> fisherii: it is a rendering choice of the browser
  430. # [17:15] <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.
  431. # [17:16] <eranm> AutomatedTester: automaters have a hard time figuring out if the element at the bottom of the stack is visible
  432. # [17:16] <eranm> AutomatedTester: we live in a 2d world and trying to solve a 3d problem in a 2d world
  433. # [17:17] <eranm> AutomatedTester: if the top-level one has no opacity and you can see through it, is it visible?
  434. # [17:17] <eranm> sstewart6: we'd be in a far better place if we did this work 3 years ago
  435. # [17:17] <eranm> AutomatedTester: in firefox we have no access to the render tree
  436. # [17:18] <eranm> sstewart6: the implementation should be able to access the rendering engine to figure it out
  437. # [17:19] <eranm> andreastt: if we go this path, can we use a definition from another spec?
  438. # [17:19] <eranm> sstewart6: feels like it should be defined in another spec
  439. # [17:20] <eranm> AutomatedTester: if it affects rendering, it probably should be
  440. # [17:20] <eranm> JohnJansen: mentioned relevant parties on Chrome/Accessibility
  441. # [17:21] <eranm> Action: sstewart6 to continue conversations with html5/css spec committees
  442. # [17:21] * RRSAgent records action 3
  443. # [17:21] <eranm> sstewart6: this feeds into things like our implementation of getText, which tries to be consistent across platforms
  444. # [17:22] * Joins: klepikovm (~42660e18@public.cloak)
  445. # [17:22] <eranm> sstewart6: textContent doesn't capture it because there's no consistency between browsers.
  446. # [17:22] <eranm> sstewart6: if we could ask an element if it's visible getText would have been much faster
  447. # [17:22] <eranm> JohnJansen: Is it a bug if an element says it's visible but it actually isn't?
  448. # [17:23] <eranm> sstewart6: yes
  449. # [17:23] <eranm> JohnJansen: the test would have to prove the visibility of the element
  450. # [17:23] <eranm> fisherii: we're not worried about rendering bugs in a web driver test. We use screenshot comparison tests for that.
  451. # [17:23] <eranm> fisherii: our web driver tests tend to be more functional
  452. # [17:24] <eranm> JohnJansen: Are screenshots brittle?
  453. # [17:24] <eranm> fisherii: yes, but not done for most projects
  454. # [17:24] <eranm> sstewart6: should we add takeScreenshot to WebElement?
  455. # [17:25] <eranm> multiple voices: yes, please
  456. # [17:27] <eranm> sstewart6: example for a partially-hidden element is a div within a div. the outer div is partially visible.
  457. # [17:27] <eranm> AutomatedTester: also caused by css transforms. Could affect visibility during the transformation
  458. # [17:27] * Joins: jmdyck (~jmdyck@public.cloak)
  459. # [17:28] <eranm> sstewart6: to avoid getting a screenshot mid-animation people should use waits
  460. # [17:29] <eranm> sstewart6: trying to click on an element that's constantly in motion can't be done completely "black box".
  461. # [17:29] <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
  462. # [17:30] <eranm> AutomatedTester: main issue is z-index
  463. # [17:30] <eranm> AutomatedTester: and partially hidden elements
  464. # [17:30] <eranm> fisherii: overflow considered partially hidden
  465. # [17:31] <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)
  466. # [17:32] <eranm> JohnJansen: if the element is very big the centre of the element will also be off
  467. # [17:32] <eranm> AutomatedTester: 10k by 10k element will not be visible
  468. # [17:33] <eranm> gdennis: why isn't the element visible if the element and the viewport intersect in any way?
  469. # [17:34] <eranm> gdennis: generalise this with overflow calculation: check if the element intersects with its ancestor elements. it can be generalised in that way
  470. # [17:34] <eranm> gdennis: is an element necessarily visible if it has a descendant that is visible?
  471. # [17:35] <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
  472. # [17:35] <eranm> gdennis: so the atoms say you have a positive size is if your descendants have non-zero child.
  473. # [17:36] <eranm> JohnJansen: don't think we can say it's visible
  474. # [17:36] <eranm> gdennis: but you can get events
  475. # [17:36] <eranm> JohnJansen: but they're actually interacting with the children
  476. # [17:36] <eranm> JohnJansen: divs with content that comes from a hidden frame
  477. # [17:38] <eranm> gdennis: element which is negatively positioned in the viewport but has a child within the viewport
  478. # [17:39] <eranm> sstewart6: there's a limited set of elements that can get keyboard input
  479. # [17:39] <eranm> fisherii: the advanced interactions API doesn't care about interactability.
  480. # [17:40] <eranm> fisherii: only have to determine coordinates to click at
  481. # [17:40] <eranm> gdennis: if they were to click on the map, they would not be able to.
  482. # [17:40] <eranm> gdennis: map tiles are not known in advance, only want to click on the map
  483. # [17:41] <Zakim> +mdyck
  484. # [17:41] <eranm> gdennis: that x,y may not be interactable
  485. # [17:42] <eranm> fisherii: the element is used as a reference, to calculate position
  486. # [17:43] <Zakim> -Mike
  487. # [17:43] <eranm> gdennis: this is a distinction from the javascript implementation, where the element provided is the element to be interacted with
  488. # [17:43] <eranm> sstewart6: do what I mean vs. do what I say, Interactions API is do what I say
  489. # [17:44] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
  490. # [17:44] * Joins: zcorpan (~zcorpan@public.cloak)
  491. # [17:45] <eranm> sstewart6: many of the limitations originate from the original implementation of the iedriver
  492. # [17:46] <eranm> jimevans: now we do fairly complicated calculations to figure out what the screen coordinates we should be clicking at are
  493. # [17:46] <eranm> jimevans: based on element coordinations on the screen, including iframes
  494. # [17:46] <MikeSmith> Zakim, call Mike
  495. # [17:46] <Zakim> ok, MikeSmith; the call is being made
  496. # [17:46] <Zakim> +Mike
  497. # [17:46] <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
  498. # [17:47] <eranm> sstewart6: what does it mean for visibility?
  499. # [17:47] <eranm> sstewart6: the intuitive definition is "i can see some part of it on the screen"
  500. # [17:47] <eranm> andreastt: if any of it is visible
  501. # [17:47] <eranm> JohnJansen: what about the children being visible but not the parent
  502. # [17:48] <eranm> wilhelm: we should write tests
  503. # [17:48] <eranm> JohnJansen: makes sense that the parent is not considered visible even if it's children are (unless it's visible by itself)
  504. # [17:49] <eranm> fisherii: the visibility of the children does not affect the visibility of the parent
  505. # [17:49] <eranm> gdennis: they want the map to be considered visible if its children are visible
  506. # [17:50] <eranm> JohnJansen: css3 regions are relevant as well
  507. # [17:51] <JohnJansen> http://dev.w3.org/csswg/css-regions/
  508. # [17:51] <sstewart6> Thanks
  509. # [17:51] <eranm> Animation should be drawn only if the element is visible, no reason in doing it otherwise
  510. # [17:51] <eranm> jimevans: anchor element where the entire of it consists of a span element
  511. # [17:51] <sstewart6> plh: can we please get a link to the web performance spec where this is defined?
  512. # [17:52] <eranm> jimevans: the span element was considered to have 0 dimensions
  513. # [17:52] <plh> -> http://www.w3.org/TR/page-visibility/ Page Visibility API
  514. # [17:52] <sstewart6> Thanks :)
  515. # [17:52] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
  516. # [17:52] <plh> but it only defines for the document, not the elements (yet)
  517. # [17:53] * Joins: zcorpan (~zcorpan@public.cloak)
  518. # [17:53] <eranm> gdennis: I have a case where the element is negatively positioned outside the viewport, but has children in the viewport
  519. # [17:53] <plh> we'll need to do for the elements to refine requestAnimationFrame
  520. # [17:53] <eranm> gdennis: should the same exception we make for size should be made for negatively-positioned elements?
  521. # [17:54] <eranm> eranm: does the problem not stem from the selection of the element to be interacted with?
  522. # [17:54] <eranm> gdennis: the event handlers are on the map, tiles amount and naming is unknown
  523. # [17:55] <eranm> wilhelm: is visibility an academic problem?
  524. # [17:55] <eranm> AutomatedTester: what opacity do we set to say something is visible? currently anything above 0
  525. # [17:55] <eranm> AutomatedTester: that should be higher
  526. # [17:56] <eranm> fisherii: you can click on something with 0 visibility
  527. # [17:56] <eranm> AutomatedTester: the lowest visible value is 0.05 (with human eyes)
  528. # [17:56] <plh> Simon, you've got a wrong link to DOM2Core in your spec. should be DOM4 instead.
  529. # [17:57] <eranm> sstewart6: select arbitrary limit for the visibility
  530. # [17:57] <eranm> sstewart6: white text on white background is still visible, just hard to read
  531. # [17:57] <sstewart6> plh: where?
  532. # [17:58] <plh> section 12, Cookies
  533. # [17:58] <eranm> fisherii: if you care about actually being able to see something you should be doing image analysis
  534. # [17:59] <plh> ACTION: Simon to change link from DOM2Core to DOM4 in Section 12, Cookies
  535. # [17:59] * RRSAgent records action 4
  536. # [17:59] <eranm> AutomatedTester: element with visibility hidden?
  537. # [17:59] <eranm> sstewart6: we've covered it in the Selenium IRC channel
  538. # [18:00] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
  539. # [18:00] <eranm> ACTION: Simon to link to the discussion on elements with visibility hidden
  540. # [18:00] * RRSAgent records action 5
  541. # [18:00] <eranm> sstewart6: if the size of the element is positive then disregard visibility hidden, because it affects layout
  542. # [18:01] <Zakim> -mdyck
  543. # [18:03] <plh> action-4?
  544. # [18:04] <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
  545. # [18:05] <eranm> fisherii: is displayed returns false , but get location and get size return correct values?
  546. # [18:05] <eranm> AutomatedTester: yes
  547. # [18:05] * plh wonders where the tracker is
  548. # [18:05] <eranm> fisherii: but it's not interactable?
  549. # [18:05] <eranm> AutomatedTester: yes
  550. # [18:05] <eranm> AutomatedTester: if display:none then it's totally different
  551. # [18:07] * Joins: trackbot (trackbot@public.cloak)
  552. # [18:07] <trackbot> Sorry, but this channel isn't in my configuration.
  553. # [18:07] <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)
  554. # [18:13] * Quits: fisherii (~fisherii@public.cloak) (Ping timeout: 180 seconds)
  555. # [18:13] * Quits: klepikovm (~42660e18@public.cloak) ("http://www.mibbit.com ajax IRC Client")
  556. # [18:15] * Quits: eranm (~eranm@public.cloak) ("This computer has gone to sleep")
  557. # [18:21] * Quits: AutomatedTester (~AutomatedTester@public.cloak) (Client closed connection)
  558. # [18:21] * Joins: AutomatedTester (~AutomatedTester@public.cloak)
  559. # [18:23] * Joins: Automate_ (~AutomatedTester@public.cloak)
  560. # [18:23] * Quits: AutomatedTester (~AutomatedTester@public.cloak) (Client closed connection)
  561. # [18:24] * Quits: darobin (rberjon@public.cloak) (Client closed connection)
  562. # [18:24] * Quits: Automate_ (~AutomatedTester@public.cloak) (Client closed connection)
  563. # [18:24] * Joins: zcorpan (~zcorpan@public.cloak)
  564. # [18:24] * Quits: marilyn_ (~marilyn@public.cloak) (Ping timeout: 180 seconds)
  565. # [18:27] * Quits: chrisgao (~chrisgao@public.cloak) (Ping timeout: 180 seconds)
  566. # [18:28] * Joins: AutomatedTester (~AutomatedTester@public.cloak)
  567. # [18:28] * Quits: AutomatedTester (~AutomatedTester@public.cloak) (Client closed connection)
  568. # [18:28] * Joins: AutomatedTester (~AutomatedTester@public.cloak)
  569. # [18:34] * Joins: eranm (~eranm@public.cloak)
  570. # [18:34] * Quits: AutomatedTester (~AutomatedTester@public.cloak) (Client closed connection)
  571. # [18:35] * Joins: AutomatedTester (~AutomatedTester@public.cloak)
  572. # [18:35] * Joins: zqzhang (~zqzhang@public.cloak)
  573. # [18:35] * Quits: AutomatedTester (~AutomatedTester@public.cloak) (Client closed connection)
  574. # [18:44] * Joins: AutomatedTester (~AutomatedTester@public.cloak)
  575. # [18:47] * Joins: Automate_ (~AutomatedTester@public.cloak)
  576. # [18:47] * Quits: AutomatedTester (~AutomatedTester@public.cloak) (Client closed connection)
  577. # [18:49] * Joins: jhammel (~jhammel@public.cloak)
  578. # [18:49] * Parts: jhammel (~jhammel@public.cloak) (jhammel)
  579. # [18:51] * Joins: AutomatedTester (~AutomatedTester@public.cloak)
  580. # [18:52] * Quits: Automate_ (~AutomatedTester@public.cloak) (Client closed connection)
  581. # [18:52] <AutomatedTester> http://eideticker.mozilla.org
  582. # [18:53] <Ms2ger> RRSAgent, thanks
  583. # [18:53] <RRSAgent> I'm logging. I don't understand 'thanks', Ms2ger. Try /msg RRSAgent help
  584. # [18:54] <Ms2ger> Zakim, excuse us
  585. # [18:54] <Zakim> leaving. As of this point the attendees were Mike, +1.617.715.aaaa, MIT_Room, Plh, mdyck
  586. # [18:54] * Parts: Zakim (zakim@public.cloak) (Zakim)
  587. # [18:54] <Ms2ger> RRSAgent, excuse us
  588. # [18:54] <RRSAgent> I see 5 open action items saved in http://www.w3.org/2013/06/13-testing-actions.rdf :
  589. # [18:54] <RRSAgent> ACTION: JohnJansen to ask the CSS WG which definition of viewport, etc., we want to use [1]
  590. # [18:54] <RRSAgent> recorded in http://www.w3.org/2013/06/13-testing-irc#T14-29-30
  591. # [18:54] <RRSAgent> ACTION: David Burns to lead the work on writing tests on visibility/interactivity [2]
  592. # [18:54] <RRSAgent> recorded in http://www.w3.org/2013/06/13-testing-irc#T14-43-10
  593. # [18:54] <RRSAgent> ACTION: sstewart6 to continue conversations with html5/css spec committees [3]
  594. # [18:54] <RRSAgent> recorded in http://www.w3.org/2013/06/13-testing-irc#T15-21-11
  595. # [18:54] <RRSAgent> ACTION: Simon to change link from DOM2Core to DOM4 in Section 12, Cookies [4]
  596. # [18:55] <RRSAgent> recorded in http://www.w3.org/2013/06/13-testing-irc#T15-59-01
  597. # [18:55] <RRSAgent> ACTION: Simon to link to the discussion on elements with visibility hidden [5]
  598. # [18:55] <RRSAgent> recorded in http://www.w3.org/2013/06/13-testing-irc#T16-00-10
  599. # [18:55] * Parts: RRSAgent (rrsagent@public.cloak) (RRSAgent)
  600. # [18:56] * Joins: klepikovm (~42660e18@public.cloak)
  601. # [18:58] * Quits: Lachy (~Lachy@public.cloak) (Ping timeout: 180 seconds)
  602. # [18:59] * Joins: Lachy (~Lachy@public.cloak)
  603. # [19:06] * Joins: Lachy_ (~Lachy@public.cloak)
  604. # [19:07] * Quits: Lachy (~Lachy@public.cloak) (Ping timeout: 180 seconds)
  605. # [19:09] <klepikovm> plz have someone ping me on google corp chat when you decide when to come back to the logging discussion, and I'll come over
  606. # [19:10] * Joins: RRSAgent (rrsagent@public.cloak)
  607. # [19:10] <RRSAgent> logging to http://www.w3.org/2013/06/13-testing-irc
  608. # [19:10] * wilhelm : Resuming meeting after lunch shortly.
  609. # [19:16] * Joins: bbbco (~bbbco@public.cloak)
  610. # [19:17] * Joins: Lachy (~Lachy@public.cloak)
  611. # [19:17] * Quits: Lachy_ (~Lachy@public.cloak) (Ping timeout: 180 seconds)
  612. # [19:18] <wilhelm> RRSAgent, draft minutes
  613. # [19:18] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html wilhelm
  614. # [19:20] <wilhelm> Scribe: wilhelm
  615. # [19:20] <sstewart6> http://www.w3.org/2011/08/browser-testing-charter.html
  616. # [19:20] <wilhelm> Topic: Timeline for spec work
  617. # [19:21] <wilhelm> sstewart6: According to our charter, we were supposed to be finished by February .. 2013.
  618. # [19:21] * Ms2ger hah, charters
  619. # [19:22] <wilhelm> JohnJansen: We should put some amount of thought into it, and make it as real as possible.
  620. # [19:22] <wilhelm> sstewart6: It should have some bearing of reality.
  621. # [19:22] <wilhelm> plh: The product is your spec.
  622. # [19:22] <wilhelm> sstewart6: We're doing our spec backwards. We have implementations, trying to go back to a spec.
  623. # [19:23] <wilhelm> JohnJansen: By making a concrete schedule, you need to have make tough decisions. Limit the scope.
  624. # [19:23] <wilhelm> sstewart6: We've done a good job of limiting scope so far.
  625. # [19:24] * Quits: Lachy (~Lachy@public.cloak) (Ping timeout: 180 seconds)
  626. # [19:26] * Joins: chrisgao (~chrisgao@public.cloak)
  627. # [19:27] * Joins: fisherii (~fisherii@public.cloak)
  628. # [19:28] * Joins: Lachy (~Lachy@public.cloak)
  629. # [19:28] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
  630. # [19:28] * Joins: zcorpan (~zcorpan@public.cloak)
  631. # [19:32] <wilhelm> ACTION: Group will meet in the #testing channel on July 12th, to work on spec and test suite together
  632. # [19:32] * trackbot is creating a new ACTION.
  633. # [19:32] <trackbot> Sorry, but this channel isn't in my configuration.
  634. # [19:32] * RRSAgent records action 1
  635. # [19:33] * Quits: eranm (~eranm@public.cloak) ("This computer has gone to sleep")
  636. # [19:33] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
  637. # [19:33] * Joins: zcorpan (~zcorpan@public.cloak)
  638. # [19:34] <wilhelm> RESOLUTION: Group aims for LC just after TPAC: 22nd of November, 2013
  639. # [19:35] * Joins: Lachy_ (~Lachy@public.cloak)
  640. # [19:35] * Quits: Lachy (~Lachy@public.cloak) (Ping timeout: 180 seconds)
  641. # [19:37] <wilhelm> jimevans: CR in March 2014?
  642. # [19:39] * Quits: santeriv (~santeriv@public.cloak) (Ping timeout: 180 seconds)
  643. # [19:39] <JohnJansen> http://dev.w3.org/csswg/css-regions/
  644. # [19:39] <wilhelm> JohnJansen: The current spec does not use plinss' tool for mapping tests to chapters.
  645. # [19:40] <wilhelm> JohnJansen: What it doesn't tell you how many tests you need for that paragraph, but it tells you how many you have.
  646. # [19:40] <wilhelm> JohnJansen: Every statement needs >0 tests.
  647. # [19:40] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
  648. # [19:43] <wilhelm> ACTION: JohnJansen will share annotations on needed tests
  649. # [19:43] * trackbot is creating a new ACTION.
  650. # [19:43] <trackbot> Sorry, but this channel isn't in my configuration.
  651. # [19:43] * RRSAgent records action 2
  652. # [19:44] <wilhelm> andreastt: We could create empty tests and fill them in.
  653. # [19:44] <wilhelm> sstewart6: I'd prefer a todo list.
  654. # [19:46] <wilhelm> jimevans: This approach is useful for TTWF.
  655. # [19:46] <JohnJansen> s/jimevans/johnjan
  656. # [19:46] <JohnJansen> s/johnjan/johnjansen
  657. # [19:46] * wilhelm : Damned tab completion. (c;
  658. # [19:56] * Joins: darobin (rberjon@public.cloak)
  659. # [19:57] <wilhelm> ACTION: JohnJansen to investigate feasibility of running the Python-based test suite at MS
  660. # [19:57] * trackbot is creating a new ACTION.
  661. # [19:57] <trackbot> Sorry, but this channel isn't in my configuration.
  662. # [19:57] * RRSAgent records action 3
  663. # [19:58] <wilhelm> trackbot, bye
  664. # [19:58] * Parts: trackbot (trackbot@public.cloak) (trackbot)
  665. # [19:59] <wilhelm> sstewart6: PR in April.
  666. # [20:02] <wilhelm> RESOLUTION: WG would like to meet at TPAC in China in November
  667. # [20:03] * Quits: bbbco (~bbbco@public.cloak) (Ping timeout: 180 seconds)
  668. # [20:06] <sstewart6> Current touch https://dvcs.w3.org/hg/webdriver/raw-file/tip/webdriver-spec.html#touch
  669. # [20:06] <wilhelm> Topic: Touch events
  670. # [20:06] * Quits: darobin (rberjon@public.cloak) (Client closed connection)
  671. # [20:08] * Joins: eranm (~eranm@public.cloak)
  672. # [20:09] <kkania> Scribe: kkania
  673. # [20:12] <AutomatedTester> http://nakubu.com/site_media/webdriver-spec.html#interactions
  674. # [20:13] <kkania> AutomatedTester: with firefox OS, first target is mobile
  675. # [20:13] <kkania> AutomatedTester: we've looked at open source project, it assumes one finger; nowsdays multitouch is important
  676. # [20:14] * Joins: Vishal (~Vishal@public.cloak)
  677. # [20:14] <kkania> AutomatedTester: examples of garage band, microsoft surface; there's a need to emulate multiple actions
  678. # [20:14] <gdennis> the atoms TouchScreen abstraction: https://code.google.com/p/selenium/source/browse/javascript/atoms/touchscreen.js
  679. # [20:15] <kkania> AutomatedTester: in our implementation, we combine actions into one batch for transmission
  680. # [20:15] * Joins: JohnJansen_ (~JohnJansen@public.cloak)
  681. # [20:16] * Quits: JohnJansen_ (~JohnJansen@public.cloak) ("Page closed")
  682. # [20:16] * Joins: JohnJansen_ (~JohnJansen@public.cloak)
  683. # [20:16] * Parts: JohnJansen_ (~JohnJansen@public.cloak)
  684. # [20:16] <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
  685. # [20:17] * Quits: JohnJansen (~JohnJansen@public.cloak) (Ping timeout: 180 seconds)
  686. # [20:18] <kkania> AutomatedTester: This is our first implementation. There's no regard for pointer events. For instance, we don't handle tilting
  687. # [20:18] <kkania> gdennis: I'd argue this should be just for touch. Pen, etc. is separate
  688. # [20:19] <kkania> sstewart6: Agree.
  689. # [20:19] <sstewart6> http://www.w3.org/TR/pointerevents/#pointerevent-interface
  690. # [20:19] * Quits: klepikovm (~42660e18@public.cloak) ("http://www.mibbit.com ajax IRC Client")
  691. # [20:19] * Joins: JohnJansen (~JohnJansen@public.cloak)
  692. # [20:21] <kkania> AutomatedTester: there is no JSON wire protocol for this yet, since we are using an internal protocol
  693. # [20:21] <JohnJansen> Present+ JohnJansen
  694. # [20:21] <kkania> AutomatedTester: should there be separate implementations for touch and for click?
  695. # [20:22] <kkania> sstewart6: we should redirect based on the underlying device
  696. # [20:23] <kkania> sstewart6: if you do need to distinguish between click and touch, you could use lower level action apis
  697. # [20:23] <kkania> sstewart6: but the default would match the system
  698. # [20:23] <kkania> JohnJansen: can you override it?
  699. # [20:23] <kkania> gdennis: if override requires to go through the advanced interactions API, that's a bit much?
  700. # [20:26] * ArtB wonders if it would have been helpful to invite the people in #webevents (Touch Events spec) and #pointerevents (Pointer Events spec)
  701. # [20:26] <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
  702. # [20:26] * Joins: darobin (rberjon@public.cloak)
  703. # [20:26] <sstewart6> ArtB: yes it would
  704. # [20:27] <kkania> sstewart6: let's finish the straw man for touch before batching
  705. # [20:27] <sstewart6> AutomatedTester tells us that he's spoken to some of the mozillians involved, but hasn't had their strawman in place for long
  706. # [20:28] <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
  707. # [20:29] <kkania> AutomatedTester: We have tap on the element; users wanted to know the difference between click and tap
  708. # [20:29] <kkania> AutomatedTester: we've done click in the past and redirecting, but harms readability of tests
  709. # [20:30] <kkania> sstewart6: this is a stronger argument to remove click from WebElement
  710. # [20:30] <kkania> jimevans: it would force you to go to the advanced interactions
  711. # [20:30] <kkania> fisherii: that means we'd ignore all the interactions stuff we discussed earlier
  712. # [20:31] <kkania> andreastt: could we have a state on the web driver itself that says whether it is click or tap?
  713. # [20:31] <kkania> andreastt: if readability is a problem, I would subclass the WebElement instance
  714. # [20:32] <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
  715. # [20:32] <kkania> andreastt: I agree adding method for tap is bad
  716. # [20:32] <kkania> gdennis: which of the ones we are proposing does a redirect
  717. # [20:33] <kkania> gdennis: is there a drag that does a swipe
  718. # [20:33] <kkania> sstewart6: this is only for stuff on webelement
  719. # [20:34] <andreastt> Isn't that what I proposed earlier? d-: Oh well.
  720. # [20:34] <kkania> sstewart6: if you care about the actual events, you should be using advanced interactions
  721. # [20:35] <Vishal> sstewart6: sorry if this is missing some context, but what's the motivation for keeping two separate levels? those on webelement and interactions?
  722. # [20:35] <kkania> sstewart6 explains way actions work currently in open source
  723. # [20:37] <sstewart6> tl;dr: Actions make use a Mouse and Keyboard abstraction.
  724. # [20:37] <kkania> AutomatedTester explains straw man proposal linked earlier
  725. # [20:39] <kkania> sstewart6: aggregations of underlying things that could be done on the local end don't need to be in the spec
  726. # [20:40] <kkania> sstewart6: I'd like to see the deepest level of abstraction instead of starting the discussion on the high level
  727. # [20:41] <kkania> sstewart6: I'd like to see the equivalent of the mouse and keyboard interface
  728. # [20:41] <kkania> gdennis: why is cancel needed? a user cannot right?
  729. # [20:41] <kkania> AutomatedTester: mashing your hand against the phone will cancel
  730. # [20:42] <kkania> everyone tries mashing their hand against their phonee
  731. # [20:43] <Vishal> if we have a mouse and keyboard, would having a screen (for touch) also make sense?
  732. # [20:44] <Vishal> going forward, screen interactions will become more relevant (and important)
  733. # [20:44] <sstewart6> Vishal: AutomatedTester is currently describing the touch strawman
  734. # [20:44] <kkania> AutomatedTester explains time ticks and necessity of batching for latency purposes
  735. # [20:44] <sstewart6> So "yes"
  736. # [20:46] <kkania> sstewart6: are beats based on time or on command
  737. # [20:46] * Quits: Lachy_ (~Lachy@public.cloak) (Ping timeout: 180 seconds)
  738. # [20:47] * Joins: zcorpan (~zcorpan@public.cloak)
  739. # [20:47] <kkania> fisherii: if you make it time based, it's hard to make it line up across multiple fingers; action based is easier
  740. # [20:47] <kkania> sstewart6: you can imagine causing failures in both pretty easy
  741. # [20:47] <kkania> sstewart6: does anyone think time based is a good idea?
  742. # [20:48] * Joins: Lachy (~Lachy@public.cloak)
  743. # [20:50] <kkania> gdennis: I'm not sure long press is necessary
  744. # [20:51] <kkania> AutomatedTester explains that long press is used to bring up context menu for testing in firefox os
  745. # [20:52] <kkania> wilhelm: how would i zoom out in a map application? wait an amount of time?
  746. # [20:54] <kkania> sstewart6 describes java interface for mouse
  747. # [20:54] <kkania> sstewart6: what are the primitives for touch?
  748. # [20:56] <kkania> fisherii: is velocity part of a move?
  749. # [20:57] <kkania> sstewart6: aggregation of underlying primitives should be pushed outside of the spec
  750. # [20:58] <kkania> fisherii: how long it takes for a long press varies on device
  751. # [20:58] <kkania> sstewart6: we need to find out what these primitives are for device
  752. # [20:58] * Joins: bbbco (~bbbco@public.cloak)
  753. # [21:01] <kkania> sstewart6: so have a tap which takes a count, ok?
  754. # [21:01] <kkania> many agreements
  755. # [21:01] <kkania> sstewart6: I think long press also needs to be a primitive
  756. # [21:02] <kkania> sstewart6 talks about open source touch primitives
  757. # [21:03] <kkania> AutomatedTester: I don't think scroll is needed, just a press and move
  758. # [21:03] <kkania> sstewart6: I think I agree
  759. # [21:05] * Joins: klepikovm (~d8ef3754@public.cloak)
  760. # [21:06] <kkania> gdennis: do you want the ability to specify time in wait, instead of a pause to sync for the tick
  761. # [21:07] <kkania> fisherii: the time in the wait could specify the minimum amount of time of the tick
  762. # [21:08] <kkania> sstewart6: I think that makes a lot sense
  763. # [21:08] <kkania> sstewart6: I think we've agreed on ticks is a good thing, having taps with a count parameter, long press
  764. # [21:08] <kkania> sstewart6: and finger down and finger up, move by offset
  765. # [21:10] <kkania> talk about how to do rotation
  766. # [21:12] <kkania> gdennis: instead of multi-action, another option would be multiple locations in a single action
  767. # [21:12] <kkania> sstewart6: might want to do different action types at the same time
  768. # [21:13] <kkania> gdennis: that is a good argument
  769. # [21:14] * Quits: darobin (rberjon@public.cloak) (Client closed connection)
  770. # [21:14] <kkania> wilhelm: how would rotations work?
  771. # [21:15] <kkania> jimevans: a huge batch of straight lines, which could be composed at a nicer way at a higher level
  772. # [21:15] <kkania> many voices agree
  773. # [21:16] <kkania> fisherii: does the mozilla implementation work with multiple input devices at the same time
  774. # [21:16] <kkania> AutomatedTester: not yet
  775. # [21:18] <kkania> ACTION: AutomatedTester will update the proposal for touch primitives and send it out for review
  776. # [21:18] * RRSAgent records action 4
  777. # [21:20] <kkania> AutomatedTester points to place in mozilla straw man that discusses batching actions
  778. # [21:20] <andreastt> Scribe: andreastt
  779. # [21:21] <sstewart6> scribe andreas:
  780. # [21:21] <wilhelm> RRSAgent, draft minutes
  781. # [21:21] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html wilhelm
  782. # [21:22] * Quits: klepikovm (~d8ef3754@public.cloak) ("http://www.mibbit.com ajax IRC Client")
  783. # [21:23] <andreastt> Topic: Batching
  784. # [21:23] <andreastt> sstewart6: The need for batching is obvious, ideally for everything.
  785. # [21:23] <andreastt> sstewart6: We're only looking at user input batching atm.
  786. # [21:23] <andreastt> jimevans: From a wire protocol perspective
  787. # [21:24] <andreastt> jimevans: You send a command to a single protocol endpoint
  788. # [21:24] <andreastt> jimevans: Which as its JSON data takes an array of JSON objects, each of those objects describes an action.
  789. # [21:24] <andreastt> jimevans: The format of those actions is ... it takes the name of the action.
  790. # [21:24] <sstewart6> https://code.google.com/p/selenium/wiki/JsonWireProtocol#/session/:sessionId/buttondown
  791. # [21:25] <andreastt> jimevans: Instead of the parameters simply taking the numbers, it would have name, colon, button down, colon.
  792. # [21:25] <andreastt> sstewart6: It would also need the name of the device.
  793. # [21:25] <andreastt> jimevans: I hadn't considered that because up to this point I was only dealing with desktpo types.
  794. # [21:25] <andreastt> fisherii: Touch, click would be what it would be otherwise
  795. # [21:25] <andreastt> fisherii: I don't think you need a separate device thing.
  796. # [21:26] <andreastt> jimevans: touch/press
  797. # [21:26] <andreastt> jimevans: All of them are prefixed.
  798. # [21:26] <andreastt> fisherii: I think it would've been nice if keyboard and mouse had done that to begin with.
  799. # [21:26] <andreastt> jimevans: That's my strawman proposal.
  800. # [21:26] <andreastt> sstewart6: How would we do it?
  801. # [21:27] <andreastt> sstewart6: I guess it would be a list of lists.
  802. # [21:27] <andreastt> sstewart6: For rotations it would be nice to go as soon as you can.
  803. # [21:28] <andreastt> fisherii: List of beats, then each beat is a list of actions in itself.
  804. # [21:28] <andreastt> sstewart6: I'm actually happy with that.
  805. # [21:28] <andreastt> sstewart6: We've already had this argument some times.
  806. # [21:28] <andreastt> jimevans: Ticks, beats, whatever we're calling it.
  807. # [21:28] <sstewart6> s/beats/ticks/
  808. # [21:28] <andreastt> JohnJansen: I'm going to spell check the beats to “ticks”.
  809. # [21:29] <andreastt> jimevans: So how would that work, how would it sit for AutomatedTester?
  810. # [21:29] <andreastt> AutomatedTester: Each line as one list, then we slice the lists. So that's fine.
  811. # [21:29] <andreastt> sstewart6: Cool.
  812. # [21:29] <andreastt> AutomatedTester: That's what I was looking for.
  813. # [21:29] <andreastt> sstewart6: Does anyone disagree?
  814. # [21:30] <andreastt> No.
  815. # [21:31] <andreastt> Resolved: We batch with a list of ticks, and each tick is a list of actions.
  816. # [21:31] <andreastt> Resolved: We have a single end-point in the HTTP protocol for actions to be sent to.
  817. # [21:31] <andreastt> Action: AutomatedTester finish his strawman proposal.
  818. # [21:31] * RRSAgent records action 5
  819. # [21:32] <andreastt> sstewart6: Do we invite Michael back now for the data in logging discussion?
  820. # [21:32] <andreastt> fisherii: Naming conventions for log types?
  821. # [21:33] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
  822. # [21:33] <andreastt> Resolved: Add data field to a log entry, which should be a map of string of objects (JSON blob).
  823. # [21:33] <wilhelm> RRSAgent, draft minutes
  824. # [21:33] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html wilhelm
  825. # [21:34] <andreastt> Ten to fifteen minute break.
  826. # [21:34] * Joins: mklepikov (~42660e18@public.cloak)
  827. # [21:34] <andreastt> mklepikov: We agreed to add your proposal. No need for further discussion.
  828. # [21:34] * Quits: kkania (~kkania@public.cloak) ("This computer has gone to sleep")
  829. # [21:35] <andreastt> Resolution: Add data field to a log entry, which should be a map of string of objects (JSON blob).
  830. # [21:35] <wilhelm> RRSAgent, draft minutes
  831. # [21:35] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html wilhelm
  832. # [21:35] <andreastt> RESOLUTION: Add data field to a log entry, which should be a map of string of objects (JSON blob).
  833. # [21:35] <wilhelm> RRSAgent, draft minutes
  834. # [21:35] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html wilhelm
  835. # [21:35] * wilhelm pokes RRSAgent with a stick.
  836. # [21:37] * Ms2ger pokes wilhelm
  837. # [21:49] * Quits: JohnJansen (~JohnJansen@public.cloak) (Ping timeout: 180 seconds)
  838. # [21:49] * Quits: mklepikov (~42660e18@public.cloak) ("http://www.mibbit.com ajax IRC Client")
  839. # [21:49] * Joins: klepikovm (~42660e18@public.cloak)
  840. # [21:51] * Joins: kkania (~kkania@public.cloak)
  841. # [21:51] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
  842. # [21:54] * Quits: sstewart6 (~simons@public.cloak) (sstewart6)
  843. # [21:55] * Joins: sstewart6 (~simons@public.cloak)
  844. # [21:55] <andreastt> sstewart6: Topics we could cover if we so wish.
  845. # [21:55] <andreastt> sstewart6: Modern HTML5 input type, on which there is no concensus.
  846. # [21:55] <andreastt> sstewart6: Security dialogues.
  847. # [21:56] <andreastt> sstewart6: Sensors, caches, interaction with sysapps, the test suite.
  848. # [21:56] <andreastt> sstewart6: I would quite like to either do the new sensors, or the modern input types.
  849. # [21:56] * Quits: ArtB (~abarsto@public.cloak) ("Leaving.")
  850. # [21:56] <andreastt> jimevans: The input types is the only one I have real input on.
  851. # [21:57] <sstewart6> https://groups.google.com/forum/#!msg/selenium-developers/_JiNc65rOUo/SJxNjCQq7t4J
  852. # [21:57] <sstewart6> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#the-input-element
  853. # [21:57] <andreastt> Topic: HTML5 input types
  854. # [21:57] <sstewart6> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#attr-input-type
  855. # [21:57] <andreastt> sstewart6: The type attribute has gone from being very simple to very complex.
  856. # [21:58] <andreastt> sstewart6: Whereas you could previously only upload one file, you can now upload multiple files for example.
  857. # [21:58] <andreastt> sstewart6: Some of them just fallback to plain text.
  858. # [21:58] <andreastt> sstewart6: datetime, datetime-local, range, color pose some problems.
  859. # [21:58] <andreastt> They probably bring up some native UI. I don't know how IE does it, but Firefox does shadow DOM.
  860. # [21:59] <andreastt> We need to be able to send data to it.
  861. # [21:59] <andreastt> The file input element allows you to upload multiple files.
  862. # [21:59] <wilhelm> http://shwetankdixit.com/testpages/webforms2demo.htm
  863. # [22:00] <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.
  864. # [22:00] <andreastt> sstewart6: We could say just go on and send strings.
  865. # [22:00] <andreastt> fisherii: Is it really? The forms themselves just send it to the backend.
  866. # [22:00] <andreastt> sstewart6: What do we do with datetimes?
  867. # [22:01] <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.
  868. # [22:01] * Joins: JohnJansen (~JohnJansen@public.cloak)
  869. # [22:02] <JohnJansen> Present+ JohnJansen
  870. # [22:02] <wilhelm> http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#date-state-(type=date)
  871. # [22:02] <sstewart6> Present+ SimonStewart
  872. # [22:02] <andreastt> andreastt: I like Jason Leyba proposal to use client binding utility classes.
  873. # [22:02] <wilhelm> http://www.w3.org/html/wg/drafts/html/master/forms.html#date-state-(type=date)
  874. # [22:03] <wilhelm> Definition of a valid date string: http://www.w3.org/html/wg/drafts/html/master/infrastructure.html#valid-date-string
  875. # [22:03] <andreastt> sstewart6: What is a valid date string?
  876. # [22:03] <andreastt> wilhelm: The spec includes saniation for any string.
  877. # [22:03] <andreastt> sstewart6: We could do that.
  878. # [22:03] <andreastt> sstewart6: How do we cope with the case where the multiple attribute has been set?
  879. # [22:03] <andreastt> fisherii: For file uplods?
  880. # [22:04] <andreastt> sstewart6: File is one, but I think they can all have multiple.
  881. # [22:04] <andreastt> sstewart6: Now the problem is that our sendKeys API already takes a list.
  882. # [22:04] <wilhelm> The multiple attribute: http://www.w3.org/html/wg/drafts/html/master/forms.html#the-multiple-attribute
  883. # [22:05] <andreastt> fisherii: It could just send it, and and send it, until you hit clear.
  884. # [22:05] <andreastt> sstewart6: That might work.
  885. # [22:05] <andreastt> fisherii: Just continue appending it on.
  886. # [22:05] <andreastt> sstewart6: I think they can all take multiple values, although it makes no sense.
  887. # [22:05] <andreastt> fisherii: What does that look like in the frontend?
  888. # [22:05] <andreastt> wilhelm: Several emails make sense.
  889. # [22:05] <andreastt> fisherii: Yes, appending to an email field makes sense.
  890. # [22:06] <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”.
  891. # [22:07] <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.
  892. # [22:07] <andreastt> jimevans: Not all of them accept @multiple.
  893. # [22:07] <andreastt> jimevans: For example for INPUT @type="tel".
  894. # [22:08] <andreastt> It's valid on the INPUT element, but it does not apply.
  895. # [22:08] <andreastt> fisherii: Yeah, it's non-normative.
  896. # [22:08] <andreastt> gdennis: What happens with the select boxes?
  897. # [22:08] <andreastt> sstewart6: Select isn't an input.
  898. # [22:08] <andreastt> fisherii: We don't have to worry about select in this case.
  899. # [22:08] <andreastt> fisherii: And select. You click on each item.
  900. # [22:09] <andreastt> gdennis: Yes, there are multiple, individual actions on the wire protocol level.
  901. # [22:09] <andreastt> sstewart6: If multiple isn't supported, append as we do currently with text or unspecified.
  902. # [22:10] <andreastt> sstewart6: We're going to be providing utility classes.
  903. # [22:10] <andreastt> fisherii: So we're going to have to throw an exception if they try to enter another colour?
  904. # [22:10] <andreastt> Except for password, telephone, text, date, colour.
  905. # [22:10] <andreastt> sstewart6: Files are handled in a very strange way.
  906. # [22:11] * Joins: JohnJansen_ (~JohnJansen@public.cloak)
  907. # [22:11] <andreastt> sstewart6: We upload the file to the remote end, have it return the path …
  908. # [22:11] * Quits: JohnJansen_ (~JohnJansen@public.cloak) ("Page closed")
  909. # [22:11] <andreastt> Discussion about driver specific INPUT @type="file" implementations.
  910. # [22:12] <andreastt> fisherii: Maybe we just throw exceptions for values you can't append to without clearing?
  911. # [22:12] <andreastt> Presumably all of these can have default values.
  912. # [22:12] <andreastt> fisherii: So do you have to clear it before setting it?
  913. # [22:13] <andreastt> andreastt: Yes, replacement makes sense.
  914. # [22:13] * Quits: JohnJansen (~JohnJansen@public.cloak) (Ping timeout: 180 seconds)
  915. # [22:13] <andreastt> sstewart6: So we do replacements for the ones we can do
  916. # [22:13] * Joins: JohnJansen (~JohnJansen@public.cloak)
  917. # [22:13] <andreastt> sstewart6: Replacements for dates, times, numeric inputs (number and range), colour, file upload.
  918. # [22:13] <andreastt> sstewart6: And we do append for text, telephone, url, email, password.
  919. # [22:14] <andreastt> fisherii: These aren't supported by all browsers.
  920. # [22:14] <andreastt> fisherii: So are we smart about detecting the type?
  921. # [22:14] <andreastt> fisherii: The attribute is still there.
  922. # [22:14] <andreastt> sstewart6: We will do an append, because the input type is text.
  923. # [22:15] <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.
  924. # [22:15] <andreastt> gdennis: The property will still be text.
  925. # [22:16] <andreastt> sstewart6: Yes, that's the difference between attributs and properties.
  926. # [22:16] <andreastt> fisherii: And getAttribute would return "color" right?
  927. # [22:17] <andreastt> sstewart6: yes, because the attribute is defined as so.
  928. # [22:17] <andreastt> sstewart6: And actually that's what people would actually expect, right?
  929. # [22:17] <andreastt> fisherii: I think that's reasonable.
  930. # [22:17] <andreastt> fisherii: So.
  931. # [22:17] <andreastt> fisherii: Replace or append for send keys depending on the multiple attribute.
  932. # [22:18] <andreastt> gdennis: Can you clarify what happens in the wire protocol?
  933. # [22:18] <andreastt> sstewart6: Normally we just send the the keys across the protocol.
  934. # [22:18] <andreastt> sstewart6: Unless the string matches a local file.
  935. # [22:18] <andreastt> sstewart6: And you have the LocalFileDetector.
  936. # [22:18] <andreastt> sstewart6: You upload that to the remote end.
  937. # [22:19] <andreastt> gdennis: You'd still use the sendKeys() command for all of these?
  938. # [22:19] <andreastt> sstewart6: yes.
  939. # [22:19] <andreastt> jimevans: Yes.
  940. # [22:19] <andreastt> gdennis: It would be a bad idea to have a select command?
  941. # [22:19] <andreastt> jimevans: The proposal for language bindings would be to expose a wrapper element type.
  942. # [22:19] <andreastt> jimevans: Which under the covers would call sendKeys with the correctly formatted strings.
  943. # [22:20] <andreastt> sstewart6: So the idea is that we have as little in the spec as possible.
  944. # [22:20] <andreastt> fisherii: It's really that we're taking advantage that the _output_ of the input fields return plain strings.
  945. # [22:20] <andreastt> jimevans: Viewport!
  946. # [22:20] <andreastt> sstewart6: Canvas!
  947. # [22:20] * heycam|away is now known as heycam
  948. # [22:20] <andreastt> wilhelm: Should we validte?
  949. # [22:21] <andreastt> sstewart6: If a user calls sendKeys() directly they're welcome to send whatever they want.
  950. # [22:21] <andreastt> sstewart6: But that would be the remote end telling us you can't.
  951. # [22:21] <andreastt> sstewart6: The language bindings would have utilities thta would make it easy to use these things without messing up.
  952. # [22:22] <andreastt> gdennis: Even if modern browsers implement this would it be posisble for users to attach something else to it?
  953. # [22:24] <andreastt> sstewart6: Are we content with that?
  954. # [22:25] <andreastt> jimevans: I'm happy with that. It's what I wanted to do anyways.
  955. # [22:25] <andreastt> jimevans: Support classes, which are more discoverable than role based interfaces.
  956. # [22:25] <andreastt> sstewart6: Okay.
  957. # [22:29] <sstewart6> http://selenium.googlecode.com/git/docs/api/java/org/openqa/selenium/security/UserAndPassword.html
  958. # [22:31] <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.
  959. # [22:31] <sstewart6> Something like that.
  960. # [22:33] <andreastt> particular type _and_ if the
  961. # [22:34] * Quits: JohnJansen (~JohnJansen@public.cloak) ("Page closed")
  962. # [22:34] * Quits: jimevans (~jimevans@public.cloak) ("Leaving.")
  963. # [22:34] * Joins: abarsto (~abarsto@public.cloak)
  964. # [22:34] * abarsto is now known as ArtB
  965. # [22:34] <wilhelm> </meeting><pub>
  966. # [22:34] <wilhelm> RRSAgent, draft minutes
  967. # [22:34] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html wilhelm
  968. # [22:34] <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.
  969. # [22:35] <wilhelm> RRSAgent, draft minutes
  970. # [22:35] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/13-testing-minutes.html wilhelm
  971. # [22:35] * Quits: sstewart6 (~simons@public.cloak) (sstewart6)
  972. # [22:35] * Quits: kkania (~kkania@public.cloak) ("Leaving")
  973. # [22:35] * Parts: gdennis (~Adium@public.cloak) (gdennis)
  974. # [22:35] <wilhelm> RRSAgent, bye
  975. # [22:35] <RRSAgent> I'm staying, wilhelm; no access has been specified for the meeting record
  976. # [22:35] <wilhelm> RRSAgent, make logs public
  977. # [22:35] <RRSAgent> I have made the request, wilhelm
  978. # [22:35] <wilhelm> RRSAgent, bye
  979. # [22:35] <RRSAgent> I see 5 open action items saved in http://www.w3.org/2013/06/13-testing-actions.rdf :
  980. # [22:35] <RRSAgent> ACTION: Group will meet in the #testing channel on July 12th, to work on spec and test suite together [1]
  981. # [22:35] <RRSAgent> recorded in http://www.w3.org/2013/06/13-testing-irc#T17-32-19
  982. # [22:35] <RRSAgent> ACTION: JohnJansen will share annotations on needed tests [2]
  983. # [22:35] <RRSAgent> recorded in http://www.w3.org/2013/06/13-testing-irc#T17-43-27
  984. # [22:35] <RRSAgent> ACTION: JohnJansen to investigate feasibility of running the Python-based test suite at MS [3]
  985. # [22:35] <RRSAgent> recorded in http://www.w3.org/2013/06/13-testing-irc#T17-57-08
  986. # [22:36] <RRSAgent> ACTION: AutomatedTester will update the proposal for touch primitives and send it out for review [4]
  987. # [22:36] <RRSAgent> recorded in http://www.w3.org/2013/06/13-testing-irc#T19-18-44
  988. # [22:36] <RRSAgent> ACTION: AutomatedTester finish his strawman proposal. [5]
  989. # [22:36] <RRSAgent> recorded in http://www.w3.org/2013/06/13-testing-irc#T19-31-52
  990. # [22:36] * Quits: AutomatedTester (~AutomatedTester@public.cloak) (Client closed connection)
  991. # [22:36] * Parts: RRSAgent (rrsagent@public.cloak) (RRSAgent)
  992. # [22:37] * Quits: jmdyck (~jmdyck@public.cloak) ("Page closed")
  993. # [22:38] * Quits: fisherii (~fisherii@public.cloak) (Ping timeout: 180 seconds)
  994. # [22:38] * Quits: plh (plehegar@public.cloak) ("Leaving")
  995. # [22:39] * Joins: jari (~jari@public.cloak)
  996. # [22:42] * Quits: chrisgao (~chrisgao@public.cloak) (Ping timeout: 180 seconds)
  997. # [22:53] * Quits: klepikovm (~42660e18@public.cloak) ("http://www.mibbit.com ajax IRC Client")
  998. # [22:58] * Quits: bbbco (~bbbco@public.cloak) (Ping timeout: 180 seconds)
  999. # [23:01] * Quits: eranm (~eranm@public.cloak) ("This computer has gone to sleep")
  1000. # [23:03] * Joins: eranm (~eranm@public.cloak)
  1001. # [23:03] * Quits: eranm (~eranm@public.cloak) ("This computer has gone to sleep")
  1002. # [23:11] * Joins: Lachy_ (~Lachy@public.cloak)
  1003. # [23:12] * Quits: Lachy (~Lachy@public.cloak) (Ping timeout: 180 seconds)
  1004. # [23:13] * Joins: eranm (~eranm@public.cloak)
  1005. # [23:22] * Joins: Lachy (~Lachy@public.cloak)
  1006. # [23:23] * Quits: Lachy_ (~Lachy@public.cloak) (Ping timeout: 180 seconds)
  1007. # [23:50] * heycam is now known as heycam|away
  1008. # [23:54] * Quits: blessmurk (~blessmurk@public.cloak) (Ping timeout: 180 seconds)
  1009. # [23:56] * Quits: eranm (~eranm@public.cloak) ("Leaving")
  1010. # [23:57] * heycam|away is now known as heycam
  1011. # Session Close: Fri Jun 14 00:00:00 2013

The end :)