/irc-logs / w3c / #testing / 2012-10-29 / end

Options:

  1. # Session Start: Mon Oct 29 00:00:00 2012
  2. # Session Ident: #testing
  3. # [00:22] * Joins: Lachy (~Lachy@public.cloak)
  4. # [06:24] * Quits: Lachy (~Lachy@public.cloak) (Ping timeout: 20 seconds)
  5. # [06:29] * Joins: byungjung (~byungjung@public.cloak)
  6. # [06:31] * Joins: MikeSmith (~MikeSmith@public.cloak)
  7. # [06:31] * Parts: byungjung (~byungjung@public.irc.w3.org)
  8. # [07:38] * Joins: Lachy (~Lachy@public.cloak)
  9. # [08:00] * Quits: MikeSmith (~MikeSmith@public.cloak) (MikeSmith)
  10. # [08:09] * Quits: Lachy (~Lachy@public.cloak) ("Computer has gone to sleep.")
  11. # [08:42] * Joins: bryan (~bryan@public.irc.w3.org)
  12. # [08:48] <wilhelm> 'Morning!
  13. # [08:48] <jgraham> Hi ho
  14. # [08:49] * Joins: byungjung (~byungjung@public.irc.w3.org)
  15. # [08:51] * Joins: simonstewart (~simonstewart@public.cloak)
  16. # [08:52] * Quits: simonstewart (~simonstewart@public.cloak) (Client closed connection)
  17. # [08:53] * Joins: sms (~simonstewart@public.cloak)
  18. # [08:53] <sms> He shoots! He scores!
  19. # [08:53] * Joins: RRSAgent (rrsagent@public.irc.w3.org)
  20. # [08:53] <RRSAgent> logging to http://www.w3.org/2012/10/29-testing-irc
  21. # [08:53] * Joins: jhammel (~jhammel@public.cloak)
  22. # [08:54] * Joins: Lachy (~Lachy@public.cloak)
  23. # [08:55] <wilhelm> RRSAgent, draft minutes
  24. # [08:55] <RRSAgent> I have made the request to generate http://www.w3.org/2012/10/29-testing-minutes.html wilhelm
  25. # [08:56] * Joins: eranm (~eranm@public.cloak)
  26. # [08:57] <wilhelm> Meeting: Browser Testing and Tools WG, Monday, TPAC
  27. # [08:57] <wilhelm> Chair: wilhelm
  28. # [08:57] * Joins: kkania (~kkania@public.cloak)
  29. # [08:57] <wilhelm> Agenda: http://lists.w3.org/Archives/Public/public-test-infra/2012OctDec/0019.html
  30. # [08:58] * Joins: abarsto (~abarsto@public.cloak)
  31. # [08:58] * abarsto is now known as ArtB
  32. # [09:03] <wilhelm> RRSAgent, make log public
  33. # [09:03] <RRSAgent> I have made the request, wilhelm
  34. # [09:04] * Joins: jari (~jari@public.cloak)
  35. # [09:04] <sms> Hi jari
  36. # [09:04] <sms> I should change my nick
  37. # [09:04] * sms is now known as simonstewart
  38. # [09:04] <simonstewart> That's better
  39. # [09:04] <jari> hi
  40. # [09:05] * Joins: JohnJansen_ (~JohnJansen@public.irc.w3.org)
  41. # [09:05] <simonstewart> The room's looking a little bare now
  42. # [09:05] <simonstewart> (physical room, that is)
  43. # [09:06] * Joins: ato (~ato@public.cloak)
  44. # [09:06] * ato is now known as andreastt
  45. # [09:06] * andreastt waves
  46. # [09:06] * simonstewart waves back
  47. # [09:09] <simonstewart> Starting in 5 minutes
  48. # [09:09] * simonstewart starts large countdown clock
  49. # [09:10] * Joins: shadi (shadi@public.cloak)
  50. # [09:10] <jgraham> (does it have the countdown music for the last 30 seconds?)
  51. # [09:10] <jhammel> it should!
  52. # [09:11] * Joins: shepazu (schepers@public.cloak)
  53. # [09:11] <simonstewart> I'll be sure to hum it loudly
  54. # [09:12] * Quits: shepazu (schepers@public.cloak)
  55. # [09:12] <wilhelm> Scribe: jhammel
  56. # [09:12] * Joins: shepazu (schepers@public.cloak)
  57. # [09:15] <wilhelm> RRSAgent, draft minutes
  58. # [09:15] <RRSAgent> I have made the request to generate http://www.w3.org/2012/10/29-testing-minutes.html wilhelm
  59. # [09:15] <jhammel> wilhelm: is the list of would-be attendents publically available?
  60. # [09:15] * Joins: plh (plehegar@public.cloak)
  61. # [09:16] <wilhelm> jhammel: https://www.w3.org/2002/09/wbs/35125/TPAC2012/registrants
  62. # [09:16] <jhammel> thanks
  63. # [09:16] <simonstewart> We've had our 5 minutes
  64. # [09:18] * simonstewart stops playing the countdown clock video
  65. # [09:18] <simonstewart> And we're off!
  66. # [09:19] <jhammel> wilhelm: For the first session, what is webdriver? What is the state of the spec? What would the attendents like to get out of webdriver?
  67. # [09:19] * plh wonders if Mike Smith is in the Testing WG f2f
  68. # [09:23] <jhammel> introductions: Michael Smith, Andreas Tolfsen, Shangyi Chen, Jeff Hammel, Larry Masinter, Wilhelm Andersen, Simon Stewart, [more]
  69. # [09:26] <jhammel> introductions: Byungjung Kim, John Jansen, Ken Kenia
  70. # [09:27] <jhammel> simonstewart: 3 audiences for driving a browser
  71. # [09:27] <jhammel> simonstewart: 1. people that want to drive a web application end to end
  72. # [09:29] <jhammel> simonstewart: <aside>original selenium was limited to what you could do in a JS sandbox; but the web has become more sophisticated
  73. # [09:29] <jhammel> simonstewart: webdriver integrates tightly with the browser; so webdriver + selenium merged to become selenium 2
  74. # [09:30] <jhammel> simonstewart: webdriver is currently the API of selenium
  75. # [09:30] <jhammel> </aside>
  76. # [09:30] <jhammel> 2nd group of people: browser vendors
  77. # [09:31] <jhammel> andreastt: Opera's made a huge undertaking in converting testing to use the webdriver API
  78. # [09:32] <jhammel> simonstewart: 3rd audience: people that are writing specifications on their own who can't write these in pure JS (mostly hypothetical at the moment)
  79. # [09:32] <jhammel> simonstewart: i've thrown together a quick demo
  80. # [09:33] <jhammel> simonstewart: walk through demo: first create a browser instance; get a particular URL ...
  81. # [09:34] <jhammel> simonstewart: webdriver represents a browser instance, but people are interested in elements on a page; [demos how to get an element]
  82. # [09:35] <jhammel> simonstewart: summary: we're going to google, searching for cheese, then arrowing down for autocomplete
  83. # [09:38] <jhammel> simonstewart: the ability to do testing across browsers with only changing the driver is very powerful with rapid releases from browser vendors
  84. # [09:38] <jhammel> larry masinter: there are no assertions?
  85. # [09:39] <jhammel> simonstewart: no, assertions aren't part of the webdriver API; this is left to whoever is writing the tests/scripts
  86. # [09:40] * Quits: plh (plehegar@public.cloak) (Ping timeout: 60 seconds)
  87. # [09:40] <jhammel> simonstewart: each of one of several languages that selenium has language bindings have their own mechanisms for running tests and doing assertions
  88. # [09:41] <jhammel> simonstewart: there is a JS binding for webdriver for nodejs
  89. # [09:42] <jhammel> simonstewart: there are multiple implementations of webdriver; the OSS project is where the webdriver work began
  90. # [09:42] <jhammel> simonstewart: opera were the first implementators of webdriver; written separately, but using the OSS project to ensure compatability
  91. # [09:43] <jhammel> simonstewart: Opera owns the Opera driver; Chrome is maintaining the Chrome driver; Mozilla is taking responsibility for the Firefox driver with Marionette
  92. # [09:43] <jhammel> Larry Masinter: You want to test scrubbing through a video; is that doable?
  93. # [09:44] <jhammel> simonstewart: there is a section on dealing with non-HTML content; we currently don't have a great story on how to test
  94. # [09:44] <jhammel> simonstewart: example: canvas; writing to canvas isn't generally done with testability in mind
  95. # [09:45] * Joins: plh (plehegar@public.cloak)
  96. # [09:45] <jhammel> simonstewart: what we want to do with the webdriver API is to bring focus to how to make what is done on the web testable/automatable (social engineering)
  97. # [09:45] <jhammel> wilhelm: isn't the video element just shadow DOM?
  98. # [09:46] <jhammel> simonstewart: one of our topics is dealing with the shadow DOM
  99. # [09:46] <jhammel> simonstewart: other open questions: SVG, a11y
  100. # [09:46] <jhammel> simonstewart: a surprising amount of web pages are still JS and HTML
  101. # [09:47] <jhammel> Larry Masinter: having a roadmap of what needs to be done would be really useful
  102. # [09:47] <jhammel> simonstewart: there is a section on extending the protocol; extending the APIs + vendor extensions
  103. # [09:47] <jhammel> simonstewart: example: wouldn't it be nice to have a API for bookmarks? However this is done differently across browsers
  104. # [09:47] <jhammel> simonstewart: process: experiment; see what works and doesn't; consolidate on what works
  105. # [09:48] <jhammel> simonstewart: just the point of getting a standard that works with JS and HTML and works with the various browsers is a huge undertaking
  106. # [09:49] <jhammel> simonstewart: then figuring out what people really want
  107. # [09:49] <jhammel> Larry Masinter: as a separate item, in the long run, what needs to get tested? Mapping out what all should be tested
  108. # [09:50] <jhammel> Larry Masinter: e.g. performance testing doesn't fit in this framework; but there should be some place where performance testing can be consider (wrt w3c WGs)
  109. # [09:51] <jhammel> Andreas Tolfsen: we can look at the webdriver API as part of that infrastructure
  110. # [09:51] <jhammel> Andreas: we use webdriver to run the tests; then we use another framework actually handle the testing
  111. # [09:51] * Joins: MikeSmith (~MikeSmith@public.cloak)
  112. # [09:52] <jhammel> Andreas: webdriver needs to be much more generic than just browser testing
  113. # [09:53] <MikeSmith> RRSAgent, make minutes
  114. # [09:53] <RRSAgent> I have made the request to generate http://www.w3.org/2012/10/29-testing-minutes.html MikeSmith
  115. # [09:53] <jhammel> Andreas: the screenshot story is a bit complicated
  116. # [09:55] <jhammel> Andreas: if we take screenshots externally, should that be part of the spec? otherwise, this could trigger a window repaint
  117. # [09:56] <jhammel> jhammel: so webdriver is fundamentally a browser automation framework, not a testing framework
  118. # [09:56] <jhammel> simonstewart: yes
  119. # [09:56] <jhammel> Larry Masinter: but it is the browser testing charter?
  120. # [09:57] <MikeSmith> RRSAgent, make minutes
  121. # [09:57] <RRSAgent> I have made the request to generate http://www.w3.org/2012/10/29-testing-minutes.html MikeSmith
  122. # [09:57] <jhammel> Simon Stewart: yes, we need to ensure that webdriver supports all that is needed to test
  123. # [09:57] <jhammel> Larry Masinter: I wonder if we could do fuzzing
  124. # [09:57] <jhammel> Andreas: it would be difficult to try to put all security testing into webdriver
  125. # [09:58] <jhammel> Simon Stewart: tests that involve using a browser like a user are good candidates for webdriver automation
  126. # [09:59] <jhammel> Wilhelm: Next topic: State of the union: where is the spec right now?
  127. # [09:59] <jhammel> Simon: I've landed a bunch of edits; the specification is moving forward
  128. # [10:00] <jhammel> Simon: the OSS selenium project; 15-100 checkins / week ; most of this is refining capabilities
  129. # [10:00] <jhammel> Simon: (handling edge cases, etc); the broad strokes are fairly well defined
  130. # [10:01] <jhammel> Simon: however, getting the test cases into the w3c test suite and ensuring that the spec is rigorously defined in English is still needing
  131. # [10:01] <jhammel> Simon: some sections are fairly flushed out; some are skeletal
  132. # [10:01] <jhammel> Simon: the implementations are further along than the specification because of a common test suite
  133. # [10:02] <jhammel> Wilhelm: which sections are finished?
  134. # [10:02] * Joins: glenn (~gadams@public.cloak)
  135. # [10:02] * Joins: JonathanJ1 (~hollobit@public.cloak)
  136. # [10:03] <jhammel> Simon: Commands+Responses flushed out ...; Switching windows; Running without focus : spec says you should; ...
  137. # [10:03] <jhammel> Simon: if you can use the OSS tests section 10 makes a lot of sense
  138. # [10:04] <jhammel> Simon: cookies = WIP; ...; Modal dialogues: skeletal; screenshots aren't flushed out
  139. # [10:05] <jhammel> Simon: How we do logging in webdriver: logging is out of process
  140. # [10:05] <jhammel> Simon: selenium grid: driver + client may be running on different machines
  141. # [10:06] <jhammel> simonstewart: vs in process; maybe console.log has all we care about
  142. # [10:06] <jhammel> Larry Masinter: You have logging but no assertions
  143. # [10:06] <jhammel> Simon: Yes; we want to get logs back in a consistent format; the logging API we have lets you get consistent records
  144. # [10:07] <jhammel> Larry Masinter: The logs would include assertion failures
  145. # [10:07] <jhammel> Simon: No; it is only internal logging
  146. # [10:07] <jhammel> Larry Masinter: What do you need to do with the logs that require standardization
  147. # [10:07] <jhammel> e.g. the console of the browser
  148. # [10:07] <jhammel> Larry Masinter: If different browsers log differently, does that matter?
  149. # [10:08] <jhammel> Simon: There isn't a standard for the content of the logs
  150. # [10:09] <jhammel> Simon Stewart: you're probably on a heterogenous network of machines; if a test fails, the user doesn't have any insight into what is going on
  151. # [10:09] <jhammel> Simon Stewart: developers want to take a look at the logs at all intermediate stages; this is what happend locally, on a webdriver server, on the test machine, etc
  152. # [10:10] <jhammel> Simon: we need that format in order to be able to get the logs
  153. # [10:10] <jhammel> Simon: we haven't put assertions in, but we've given you the ability to put assertions in
  154. # [10:10] <jhammel> Simon: its not active logging; its fairly passive
  155. # [10:12] <jhammel> Larry Masinter: roadmap: how do you ensure adequate consistency? are we writing our specs too precisely?
  156. # [10:13] <jhammel> Simon Stewart: i've seen a number of projects that have survived major reworking of the UIs without failing; the key is how you find the elements
  157. # [10:14] <jhammel> Larry Masinter: there may be operations that can only be done with multitouch, etc
  158. # [10:14] <jhammel> Simon Stewart: you can query your webdriver instance for the capabilities it supports
  159. # [10:14] <jhammel> Simon Stewart: e.g. do i support touch actions?
  160. # [10:15] <jhammel> Larry Masinter: would you use media queries to determine what tests are run?
  161. # [10:15] <jhammel> Simon Stewart: no; in the OSS project, you only run tests if the assumption is true
  162. # [10:16] * Quits: byungjung (~byungjung@public.irc.w3.org) (Ping timeout: 20 seconds)
  163. # [10:16] <jhammel> Simon Stewart: we've divorced ourselves from a testing framework, but we've given you the capabilities to create a testing framework; we allow you to query the capabilities without enforcing you to do anything if the capabilities aren't met
  164. # [10:17] <jhammel> John Jansen: How do i easily determine the diff between red+blue?
  165. # [10:18] <jhammel> Simon Stewart: using diff from the VCS; would you prefer a different way?
  166. # [10:18] * Joins: byungjung (~byungjung@public.irc.w3.org)
  167. # [10:18] <jhammel> John: is that pushed decided by the wg?
  168. # [10:18] <jhammel> Simon Stewart: Yes
  169. # [10:19] <jhammel> Wilhelm: is there any particular reason why you care about the blue one over the red one?
  170. # [10:19] <jhammel> John: mostly out of habit
  171. # [10:19] <jhammel> Simon: because of the way we're writing the specification, blue isn't invalid
  172. # [10:20] <simonstewart> http://dvcs.w3.org/hg/webdriver/raw-file/tip/webdriver-spec.html#commands-and-responses
  173. # [10:20] <jhammel> Wilhelm: Blue refers to the published working draft; red is the editor draft
  174. # [10:20] <simonstewart> http://dvcs.w3.org/hg/webdriver/raw-file/tip/webdriver-spec.html
  175. # [10:20] <simonstewart> http://www.w3.org/TR/webdriver/
  176. # [10:21] <simonstewart> jhammel: those links probably won't be in the minutes unless you scribe them
  177. # [10:21] <jhammel> Wilhelm: What do you all want from the webdriver spec? What do you want from this meeting
  178. # [10:21] <jhammel> location of webdriver spec: http://www.w3.org/TR/webdriver/
  179. # [10:21] <simonstewart> thanks :)
  180. # [10:22] <jhammel> andreastt: we want web developers to be able to use opera when testing
  181. # [10:22] * Joins: darobin (rberjon@public.cloak)
  182. # [10:22] <jhammel> Andreas: to ensure that they have site compatability
  183. # [10:22] <jhammel> Andreas: last year, we released our HTML5 parser; we also got sites to run our test suite versus their sites
  184. # [10:24] <jhammel> Jeff Hammel: trying to figure out what Mozilla needs to do to get Marionette + webdriver on spec
  185. # [10:24] <jhammel> Shangyi Chen: trying to observe what is the progress is being done
  186. # [10:25] <jhammel> Shangyi Chen: Baidu using webdriver
  187. # [10:26] <jhammel> John Jansen: trying to solve big problems at microsoft; this is one point of input
  188. # [10:26] <jhammel> Wilhelm: last time i wanted to test my browser; today i want to test my sites with various browsers
  189. # [10:27] <jhammel> Wilhelm: want the spec to move forward; want all WGs to test all the specs they're working on
  190. # [10:27] <jhammel> wilhelm: want to be able to point to a spec to say, 'Use this spec to test all other specs'
  191. # [10:28] <jhammel> Simon: working on webdriver for 7 years now; has become the de facto way of testing web apps
  192. # [10:28] <jhammel> Simon: I want to standardize it; as the web gets more capability, it becomes harder and harder
  193. # [10:28] * Quits: ArtB (~abarsto@public.cloak) (Client closed connection)
  194. # [10:28] * Joins: abarsto (~abarsto@public.cloak)
  195. # [10:28] * abarsto is now known as ArtB
  196. # [10:28] <jhammel> Simon: need support from the browser vendors; webdriver is one of the tools in the arsenal
  197. # [10:29] <jhammel> Simon: the thing that testers hate doing is duplicating effort; they tend not to use another API once they have one solution working
  198. # [10:30] <jhammel> ?: Make sure the spec is understood; the more help we can get from browser vendors, the better
  199. # [10:30] <jhammel> ?: figure out the limits of the spec; figure out what can be done to extend these limits
  200. # [10:30] * Quits: darobin (rberjon@public.cloak) (Client closed connection)
  201. # [10:31] <jhammel> Ken Kenia: primary concern for chrome team is website compatability
  202. # [10:31] <jhammel> Ken Kenia: can test websites across browsers quickly
  203. # [10:31] <jhammel> Ken Kenia: we don't use webdriver as pervasively as Opera
  204. # [10:31] <jhammel> Larry Masinter: Does webkit use webdriver?
  205. # [10:32] <jhammel> Ken Kenia: not currently with internal testing
  206. # [10:32] <jhammel> Larry Masinter: should it?
  207. # [10:32] <jhammel> Simon: there are at least two projects that are based on webkit that need to do testing; so yes
  208. # [10:33] <jhammel> Simon: it simplifies the vendors work; it simplifies the driver's work
  209. # [10:33] <jhammel> Wilhelm: is there anything this WG can do to help with the politics of webkit?
  210. # [10:33] <jhammel> Wilheml: if so we should do it
  211. # [10:33] <jhammel> Simon: webkit is worked largely on by Chromium; though Apple depends on it too
  212. # [10:34] <jhammel> Simon: is there anything we can do to encourage participation by MS?
  213. # [10:34] <jhammel> John: let's talk about that later
  214. # [10:34] * Quits: kkania (~kkania@public.cloak) (kkania)
  215. # [10:35] * Quits: simonstewart (~simonstewart@public.cloak) (simonstewart)
  216. # [10:35] * Joins: sms (~simonstewart@public.cloak)
  217. # [10:36] * Quits: bryan (~bryan@public.irc.w3.org) (Ping timeout: 20 seconds)
  218. # [10:36] * Quits: byungjung (~byungjung@public.irc.w3.org) (Ping timeout: 20 seconds)
  219. # [10:37] * Quits: JonathanJ1 (~hollobit@public.cloak) (Ping timeout: 20 seconds)
  220. # [10:46] * Quits: eranm (~eranm@public.cloak) ("This computer has gone to sleep")
  221. # [10:58] * Quits: JohnJansen_ (~JohnJansen@public.irc.w3.org) ("Page closed")
  222. # [11:01] <wilhelm> RRSAgent, draft minutes
  223. # [11:01] <RRSAgent> I have made the request to generate http://www.w3.org/2012/10/29-testing-minutes.html wilhelm
  224. # [11:03] * Joins: JohnJansen (~JohnJansen@public.cloak)
  225. # [11:07] * Joins: davidburns (~davidburns@public.cloak)
  226. # [11:07] * Joins: kkania (~kkania@public.cloak)
  227. # [11:07] * Joins: eranm (~eranm@public.cloak)
  228. # [11:07] <sms> Here we go again!
  229. # [11:07] <wilhelm> Chair: sms
  230. # [11:08] <sms> Chair: simonstewart
  231. # [11:08] <wilhelm> Scribe: wilhelm
  232. # [11:08] <sms> Ohhh... I'm back as sms
  233. # [11:08] <sms> Interesting
  234. # [11:08] <wilhelm> Topic: Discussion of open issues in the spec
  235. # [11:08] <jhammel> http://lists.w3.org/Archives/Public/public-test-infra/2012OctDec/0019.html
  236. # [11:08] * Joins: byungjung (~byungjung@public.irc.w3.org)
  237. # [11:09] <wilhelm> (See list of open issues in the agenda.)
  238. # [11:10] * Quits: eranm (~eranm@public.cloak) (Ping timeout: 20 seconds)
  239. # [11:10] * Joins: eranm (~eranm@public.cloak)
  240. # [11:10] <wilhelm> sms: Some parts of the spec is integer-heavy. (Points to error codes.) We could use strings instead.
  241. # [11:10] <wilhelm> Topic: Interoperability
  242. # [11:11] <wilhelm> sms: The spec, as written, does not describe a transport mechanism and how to encode data.
  243. # [11:11] * Joins: JonathanJ (~hollobit@public.cloak)
  244. # [11:12] <wilhelm> sms: This is for historical reasons. Different drivers use different protocols.
  245. # [11:12] <wilhelm> sms: It is possible to follow the spec - and not be interoperable.
  246. # [11:14] <wilhelm> sms: Suggestion, listed as a note in the spec: implementations should allow the use of JSON wire protocol.
  247. # [11:15] <wilhelm> sms: It would be possible to write an implementation specific to one language. For example a proprietary connector for mobile.
  248. # [11:15] <wilhelm> sms: How do we allow people the freedom to choose the transport mechanism they prefer? JSON+HTTP may not be the most efficient.
  249. # [11:16] <wilhelm> sms: At the same time introducing a new device/platform/browser must be easy.
  250. # [11:16] <wilhelm> jhammel: The goal is to encourage it, not enforce it?
  251. # [11:16] <wilhelm> sms: We could say "must".
  252. # [11:16] <JonathanJ> rrsagent, draft minutes
  253. # [11:16] <RRSAgent> I have made the request to generate http://www.w3.org/2012/10/29-testing-minutes.html JonathanJ
  254. # [11:16] <wilhelm> sms: This is currently in a non-normative section.
  255. # [11:17] <wilhelm> sms: We could make that spec normative.
  256. # [11:17] <wilhelm> wilhelm: Why shouldn't we?
  257. # [11:17] <wilhelm> sms: Nokia was against using JSON over HTTP. Maybe they don't mind a shim.
  258. # [11:18] <wilhelm> sms: One suggestion is we mandate that every implementation must have the shim.
  259. # [11:20] <wilhelm> (Tangent about malicious commits to the conformance test suite using something else than the JSON wire protocol.)
  260. # [11:20] <wilhelm> andreastt: Has other specs faced this problem?
  261. # [11:21] <wilhelm> sms: WebDriver is the only out of process spec that tries to have a consistent API.
  262. # [11:21] <wilhelm> andreastt: It makes sense for me to enforce this for the spec to be practically useful. It should support a unified transport protocol.
  263. # [11:21] <wilhelm> sms: This is a fairly safe tech stack.
  264. # [11:22] * Quits: kkania (~kkania@public.cloak) (kkania)
  265. # [11:22] <wilhelm> ACTION: Make the section on the JSON wire protocol normative
  266. # [11:22] * RRSAgent records action 1
  267. # [11:23] <wilhelm> (Discussion on whether all drivers will be part of the open source project.)
  268. # [11:25] <wilhelm> (Discussion on language agnosticism.)
  269. # [11:26] <wilhelm> sms: If you go into a Microsoft shop and say "I want to use this Java program", that's not going to work. By having a standalone executable people can choose the bindings they prefer.
  270. # [11:28] <wilhelm> sms: I don't want a duplication of effort in the transport layer. If you use the JSON wire protocol, and have a shim, you can use any langauge or driver.
  271. # [11:30] <wilhelm> sms: The shim should be on the side of the browser vendor.
  272. # [11:31] <wilhelm> kkania: Is there a reason for out-of-process instead of in-process executable?
  273. # [11:31] <wilhelm> sms: This is a may. Implementors are free to bake this into their browser.
  274. # [11:31] <wilhelm> andreastt: These are implementation specifics, no? If you are writing something for your own uses, this doesn't cause any trouble.
  275. # [11:32] <wilhelm> kkania: Is there a reason for why we want JSON over HTTP?
  276. # [11:32] <wilhelm> sms: It works remotely. It works over every single client language you can think about implementing. Even more than loading a DLL.
  277. # [11:32] <wilhelm> sms: Works independently of bitness (32 vs 64 bit).
  278. # [11:33] <wilhelm> andreastt: And this only covers the C implementations.
  279. # [11:33] <wilhelm> sms: We settled on JSON over HTTP because all these languages have a HTTP and JSON library. We considered thrift and protbufs.
  280. # [11:34] <wilhelm> sms: I wrote a JS client that used XHR.
  281. # [11:34] * Joins: darobin (rberjon@public.cloak)
  282. # [11:34] <wilhelm> sms: One of the major audiences are people testing their web applications. Many of these people don't have root.
  283. # [11:35] <wilhelm> sms: They might not even allow you to install any software. This rapidly became a nightmare.
  284. # [11:35] <wilhelm> andreastt: In the millitary, you may not even have access to the Internet.
  285. # [11:35] <wilhelm> jhammel: You might even do this manually via telnet, typing everything.
  286. # [11:36] <wilhelm> sms: This is currently covered by appendix E. This will be moved into the body of the spec, as normative prose.
  287. # [11:36] <wilhelm> Topic: Internationalised input
  288. # [11:37] <wilhelm> sms: There are two use cases for internationalised input.
  289. # [11:37] <wilhelm> sms: Am I doing proper roundtripping with international characters?
  290. # [11:37] * Quits: plh (plehegar@public.cloak) (Ping timeout: 60 seconds)
  291. # [11:38] <wilhelm> sms: I want to make sure my app does the right thing as the user is typing using an IME (or similar).
  292. # [11:38] <wilhelm> sms: If you use sendKeys with international characters the character makes it into the input field, but it is nothing like what the user actually does.
  293. # [11:39] <wilhelm> eranm: IME is only used for complex alphabets.
  294. # [11:39] <wilhelm> andreastt: We have not done any work on IMEs. We don't check if the keys exist on the keyboard.
  295. # [11:40] <wilhelm> andreastt: There have been several requests from our users for support of changing the charset of the keyboard. This is a difficult problem.
  296. # [11:40] <wilhelm> sms: Mobiles have different input methods.
  297. # [11:40] <wilhelm> sms: Choose a different keyboard, long press on E to get É, etc.
  298. # [11:41] <wilhelm> andreastt: On fature phones you have predefined buttons that can be programmed. This also applies to some smartphones. Programmable keys.
  299. # [11:41] <wilhelm> andreastt: You don't know what's going to be on the keyboard.
  300. # [11:41] <wilhelm> sms: The IME stuff we have is very desktop specific and requires a lot of knowledge about the machine you're running on. Is this a reasonable thing to have in the spec?
  301. # [11:42] <wilhelm> eranm: Since we've added support, nobody has actually used it.
  302. # [11:42] <wilhelm> eranm: There are 1.5 billion people using complex scripts. Solicit input from them?
  303. # [11:42] <wilhelm> eranm: Hebrew/Arabic are much simpler. What we have may be good enough.
  304. # [11:43] <wilhelm> sms: So we should move IME to non-normative.
  305. # [11:43] <wilhelm> andreastt: É is registered as two different characters in the browser.
  306. # [11:43] <JonathanJ> rrsagent, draft minutes
  307. # [11:43] <RRSAgent> I have made the request to generate http://www.w3.org/2012/10/29-testing-minutes.html JonathanJ
  308. # [11:44] <wilhelm> andreastt: Complicating factor: OS specific stuff.
  309. # [11:44] * Joins: plh (plehegar@public.cloak)
  310. # [11:44] <wilhelm> sms: And different keyboard layouts: Norwegian/English/etc.
  311. # [11:44] <wilhelm> sms: Sometimes there will be a mapping to a key, sometimes it won't.
  312. # [11:44] <wilhelm> sms: If there is a character on the keyboard, we can just send the right character.
  313. # [11:45] <wilhelm> sms: In the case where a key is not on the keyboard (shalom in Hebrew) we just stuff in the right characters.
  314. # [11:46] <wilhelm> davidburns: We should not go in detail on this.
  315. # [11:46] <wilhelm> andreastt: What should the spec cover? I don't think this fits. A library on top of the sendKeys implementation makes sense.
  316. # [11:47] <wilhelm> davidburns: This may be covered in the Widgets spec.
  317. # [11:47] <wilhelm> sms: I'm hearing: We specificy that you must be able to do internationalised input, but don't specifiy how that is done.
  318. # [11:47] <MikeSmith> btw, somewhat related to this topic, Norbert Lindenberg of http://norbertlindenberg.com/2012/10/ecmascript-internationalization-api/index.html is here at TPAC this week
  319. # [11:48] <wilhelm> eranm: We emulate shift-a for A. Should we spec this?
  320. # [11:48] * Joins: kkania (~kkania@public.cloak)
  321. # [11:48] <wilhelm> sms: We also do the alt keys on Window.
  322. # [11:48] <wilhelm> s/Window/Windows
  323. # [11:49] <wilhelm> JonathanJ: IME is very complicated.
  324. # [11:50] <wilhelm> ACTION: JonathanJ to give input on non-latin character input
  325. # [11:50] * RRSAgent records action 2
  326. # [11:50] <wilhelm> ACTION: davidburns to look into how the DOM spec handles keyboard events and internationalisation
  327. # [11:50] * RRSAgent records action 3
  328. # [11:51] <wilhelm> andreastt: The current IME section is... nothing.
  329. # [11:52] <wilhelm> sms: There is a series of commands for handling IME in code. Document these as non-normative.
  330. # [11:52] <wilhelm> eranm: Two ways of using IME: Enable it in the OS, input latin characters. Or give me a list of IMEs and interact with them. We should document both, but the first is definitely non-normative.
  331. # [11:53] <wilhelm> eranm: We should listen to people who actually use this.
  332. # [11:53] <wilhelm> Topic: ARIA locators?
  333. # [11:54] <wilhelm> sms: An accessible web is a good web. Should we add ARIA as another type of selector?
  334. # [11:54] <wilhelm> sms: I don't know if the ARIA specs have any APIs that browsers should implement.
  335. # [11:54] <wilhelm> sms: Is there an equivalent to querySelector for ARIA? I don't think there is.
  336. # [11:55] <wilhelm> JohnJansen: I haven't seen one.
  337. # [11:55] <wilhelm> sms: Given the way we implement XPath, CSS selectors, etc - by delegating to the browser - and there is no API for this in the browser, let's not add this.
  338. # [11:55] <wilhelm> Topic: Shadow DOM
  339. # [11:55] <wilhelm> sms: This'll be fun.
  340. # [11:56] <wilhelm> sms: Is everyone familiar with what the shadow DOM is?
  341. # [11:56] <wilhelm> davidburns: Shadow DOM is an object model that is hidden away from view. In a <video> tag, the browser generates a number of hidden elements (play button, etc.) you may want to interact with.
  342. # [11:57] <wilhelm> davidburns: How should we access these elements?
  343. # [11:57] <sms> http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html
  344. # [11:57] <wilhelm> davidburns: If we query the DOM, the browser won't give us the shadow DOM elements.
  345. # [11:58] <wilhelm> sms: A shadow host appears as a single element in the DOM. You find a wealth of badness beneath it. It nests - turtles all the way down.
  346. # [11:59] <wilhelm> andreastt: Is there any way to expose that in the browser today?
  347. # [11:59] <wilhelm> sms: The render tree expands everything out, but not in the DOM.
  348. # [11:59] <wilhelm> sms: How do we want to present this to users?
  349. # [11:59] <wilhelm> sms: Chrome just switched this on.
  350. # [11:59] <wilhelm> davidburns: It's behind a command-line flag.
  351. # [11:59] <wilhelm> sms: No, it's on by default.
  352. # [12:00] <wilhelm> jhammel: Does each browser have a different shadow DOM for <video>?
  353. # [12:01] <wilhelm> sms: Facebook like button is a good candidate for shadow DOM.
  354. # [12:02] <wilhelm> sms: My suggestion: If you do a findByTagName within a findByTagName('video'), you query within a shadow host.
  355. # [12:03] <wilhelm> sms: We should follow the model of the JS world.
  356. # [12:03] <wilhelm> sms: Don't cast to a specific shadowElement.
  357. # [12:03] <wilhelm> sms: Does this sound reasonable?
  358. # [12:04] <wilhelm> davidburns: Yes.
  359. # [12:04] <wilhelm> davidburns: There will be a lot more shadow elements in the future. They simplify a lot.
  360. # [12:04] <wilhelm> sms: Once you're in the shadow DOM, it looks like a regular DOM.
  361. # [12:05] <wilhelm> sms: Do we want to indicate to the user that the element they're looking at is the root of a shadow DOM?
  362. # [12:05] <wilhelm> andreastt: I suggest we don't.
  363. # [12:05] <wilhelm> sms: I'm leaning that way too.
  364. # [12:05] <wilhelm> andreastt: You could do it yourself in JS.
  365. # [12:06] <wilhelm> eranm: If you don't have to return something, don't.
  366. # [12:06] <wilhelm> sms: My preference is to not add anything to our spec that we don't need to.
  367. # [12:06] <wilhelm> ACTION: Write a section on handling the shadow DOM that mirrors the JS APIs
  368. # [12:06] * RRSAgent records action 4
  369. # [12:07] <wilhelm> jhammel: We should write conformance tests for this.
  370. # [12:07] <wilhelm> sms: We should do this for all parts of the spec.
  371. # [12:07] <wilhelm> Topic: Error codes - strings or numbers?
  372. # [12:08] <wilhelm> sms: At the moment we always return numbered codes. We happen to know what it means through constants.
  373. # [12:08] <wilhelm> sms: Great for us, since we are familiar with it. Difficult for others trying to debug the wire protocol.
  374. # [12:08] <wilhelm> sms: The numbers don't make any sense.
  375. # [12:09] <wilhelm> sms: "People who observe the wire traffic would like to understand what is going on without having to look up the numbers". Counter-argument: "They can just look it up, we carry on as now."
  376. # [12:10] <wilhelm> jhammel: Mild pro-string.
  377. # [12:10] <wilhelm> jhammel: They are human-readable, which is good.
  378. # [12:11] <wilhelm> andreastt: I'm for keeping the numbers. If we keep the numbers, we should rework whether all of these are neccessary.
  379. # [12:11] <wilhelm> andreastt: Categorize and put in groups.
  380. # [12:11] <wilhelm> andreastt: If we transfer strings, that's a lot more data.
  381. # [12:11] <wilhelm> andreastt: Then we'd need to set a limit here.
  382. # [12:11] * Quits: byungjung (~byungjung@public.irc.w3.org) (Ping timeout: 20 seconds)
  383. # [12:11] <wilhelm> sms: You don't want the collected works of Shakespeare as a status code.
  384. # [12:12] <wilhelm> sms: You could use numbers in the scope protocol and translate in the shim.
  385. # [12:12] <wilhelm> andreastt: That may be overkill.
  386. # [12:13] <wilhelm> sms: If we used strings, we would use the summary field, with spaces.
  387. # [12:13] <wilhelm> sms: The numbers come from the original IE implementation.
  388. # [12:14] <wilhelm> sms: So far, we've just used the next unused number for new error codes.
  389. # [12:15] <wilhelm> andreastt: Options: 1. Use strings. 2. Use ints that are grouped. 3. Keep things as they are.
  390. # [12:15] <wilhelm> sms: This change would have to be in Selenium 3. Major, breaking change.
  391. # [12:16] <wilhelm> sms: We could keep the old error codes for a while.
  392. # [12:16] <wilhelm> eranm: The numbers are used across languages. A string would mean less confusion than ints (which are opaque strings).
  393. # [12:16] <wilhelm> jhammel: If we stick with numbers, we should have sensible groupings.
  394. # [12:17] <wilhelm> sms: We need to figure out what the groupings are.
  395. # [12:17] <wilhelm> andreastt: What happens if a webdriver binding doesn't have the complete list of error codes?
  396. # [12:17] <wilhelm> sms: If the local end sees an error it doesn't know, just throw the base WebDriver exception.
  397. # [12:18] * Quits: plh (plehegar@public.cloak) ("always accept cookies")
  398. # [12:18] <wilhelm> andreastt: Are all the errors here fatal?
  399. # [12:18] <wilhelm> sms: Yes.
  400. # [12:18] * Quits: shepazu (schepers@public.cloak) ("is sleepy")
  401. # [12:18] <wilhelm> andreastt: How will we treat success?
  402. # [12:18] * Quits: Lachy (~Lachy@public.cloak) ("Computer has gone to sleep.")
  403. # [12:19] <wilhelm> sms: Empty string or 0.
  404. # [12:19] <wilhelm> andreastt: If we decide to go with strings, do we still want a normative list of error messages?
  405. # [12:19] <wilhelm> sms: We must have a normative list of error messages. (This should be extensible, with a prefix?.)
  406. # [12:20] <wilhelm> sms: As vendor X, how do I add new status codes?
  407. # [12:20] <wilhelm> sms: Opera has 1000, MS has 2000? Or private use areas like in Unicode?
  408. # [12:21] <wilhelm> sms: The private use area of the unicode that we use for sendkeys to do things like down, etc, overlap with emoji.
  409. # [12:21] <wilhelm> sms: So far we've got away with it.
  410. # [12:21] <wilhelm> sms: We may have a problem.
  411. # [12:21] <wilhelm> sms: (This is a separate issue.)
  412. # [12:21] <wilhelm> andreastt: If we use strings, vendors can use an arbitrary strings.
  413. # [12:22] <wilhelm> andreastt: There may be collisions
  414. # [12:22] <wilhelm> sms: This is covered under vendor-specific extensions: -moz, -o. We guarantee to not have an error starting with -.
  415. # [12:23] * Joins: shepazu (schepers@public.cloak)
  416. # [12:23] <wilhelm> sms: We should probably do the same for error codes.
  417. # [12:24] <eranm> wilhelm, can I propose another agenda item? It's related to the next one, about a bunch of html5-related APIs that currently exist in WebDriver and we should decide what we want to do with them.
  418. # [12:25] <wilhelm> sms: Vendor-specific extension could be: "-o Bookmark not found", "-o-Bookmark not found".
  419. # [12:26] <wilhelm> sms: Humans use spaces. We should use spaces if we decide to go for strings.
  420. # [12:27] <wilhelm> sms: I don't want to use both strings and numbers: 404 Not found
  421. # [12:27] <wilhelm> davidburns: My preference is pruned numbers.
  422. # [12:29] <wilhelm> sms: Overlap between vendor error codes is a problem. The client doesn't know which browser it uses.
  423. # [12:29] <wilhelm> kkania: I like strings.
  424. # [12:29] <wilhelm> kkania: Only objection to strings is performance. I don't see that as a big deal.
  425. # [12:30] * Quits: darobin (rberjon@public.cloak) (Client closed connection)
  426. # [12:30] <wilhelm> jhammel: They are a bit English-specific.
  427. # [12:30] <wilhelm> sms: So is everything else.
  428. # [12:30] <wilhelm> andreastt: Opera leans towards strings.
  429. # [12:30] <wilhelm> JohnJansen: No opinion.
  430. # [12:31] <wilhelm> jhammel: Mozilla is on the fence.
  431. # [12:31] <wilhelm> sms: I suggest we move to strings.
  432. # [12:31] * Quits: ArtB (~abarsto@public.cloak) ("Leaving.")
  433. # [12:31] <wilhelm> sms: That means a new field on the response headers.
  434. # [12:31] <wilhelm> sms: In the spec, it will always be strings.
  435. # [12:33] <wilhelm> sms: If we had numbers, we need to give different numbers to different companies.
  436. # [12:33] <wilhelm> sms: The client side should be as generic as possible, and just works.
  437. # [12:34] * Quits: kkania (~kkania@public.cloak) (kkania)
  438. # [12:35] * Quits: shepazu (schepers@public.cloak) ("is sleepy")
  439. # [12:36] <wilhelm> ACTION: In the common case of success, the status code is left as the null value. If omitted, treat it as null.
  440. # [12:36] * RRSAgent records action 5
  441. # [12:36] <wilhelm> ACTION: Strings replace numbers in errors
  442. # [12:36] * RRSAgent records action 6
  443. # [12:36] <wilhelm> Topic: Lunch! Woho!
  444. # [12:38] * Quits: JonathanJ (~hollobit@public.cloak) (Ping timeout: 20 seconds)
  445. # [12:48] * Quits: eranm (~eranm@public.cloak) ("This computer has gone to sleep")
  446. # [12:57] * Quits: shadi (shadi@public.cloak) (Ping timeout: 60 seconds)
  447. # [13:02] * Disconnected
  448. # [13:03] * Attempting to rejoin channel #testing
  449. # [13:03] * Rejoined channel #testing
  450. # [13:06] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
  451. # [13:46] * Joins: shepazu (schepers@public.cloak)
  452. # [13:48] * Joins: Lachy (~Lachy@public.cloak)
  453. # [13:48] * Joins: a12u (~androirc@public.cloak)
  454. # [13:50] * Joins: abarsto (~abarsto@public.cloak)
  455. # [13:50] * abarsto is now known as ArtB
  456. # [13:53] * Joins: eranm (~eranm@public.cloak)
  457. # [14:04] * Joins: shadi (shadi@public.cloak)
  458. # [14:06] * Joins: glenn (~gadams@public.cloak)
  459. # [14:08] * Joins: kkania (~kkania@public.cloak)
  460. # [14:11] <wilhelm> Topic: Taking shit out
  461. # [14:12] <wilhelm> davidburns: We have our own definition of "window". We should align this with HTML5.
  462. # [14:12] <wilhelm> andreastt: Chrome operates with browsers as opposed to windows, no?
  463. # [14:12] <wilhelm> kkania: It's a separate browser class, not a separate process.
  464. # [14:13] <wilhelm> andreastt: In Opera you can have multiple windows with multiple tabs. (This applies to all browsers.)
  465. # [14:13] <wilhelm> andreastt: A window is a tab.
  466. # [14:14] <wilhelm> sms: The example we have now is: 1 OS-level window with 2 tabs, 1 OS-level window with 1 tab (chapter 6.3). Each tab is considered a window.
  467. # [14:14] * Joins: byungjung_ (~byungjung@public.irc.w3.org)
  468. # [14:14] <wilhelm> davidburns: jgraham suggested having a top-level browsing context.
  469. # [14:14] <wilhelm> sms: Is that a tab or an OS-level window?
  470. # [14:14] <wilhelm> sms: I think it's a tab. I'm cool with that.
  471. # [14:16] <wilhelm> sms: (Quouting HTML definition of top-level browsing context.)
  472. # [14:16] <wilhelm> sms: I'm happy with window to be top-level browsing context.
  473. # [14:17] <wilhelm> ACTION: Windows are to be the same as a top-level browsing context (as defined in HTML)
  474. # [14:17] * RRSAgent records action 7
  475. # [14:17] <sms> http://www.whatwg.org/specs/web-apps/2007-10-26/multipage/section-windows.html#parent
  476. # [14:18] <wilhelm> sms: (Quoting WebDriver spec on ordering of top-level browsing contexts across multiple OS-level windows.)
  477. # [14:19] * Joins: plh (plehegar@public.cloak)
  478. # [14:19] * Joins: shadi_ (shadi@public.cloak)
  479. # [14:19] <wilhelm> andreastt: Why is this a should?
  480. # [14:19] <wilhelm> sms: It's nice to have, but it's not required.
  481. # [14:19] * Quits: shadi_ (shadi@public.cloak) (Client closed connection)
  482. # [14:19] <wilhelm> (Speaking of the ordering of top-level browsing contexts.)
  483. # [14:21] <wilhelm> kkania: Why have this clause at all?
  484. # [14:21] <wilhelm> sms: Unskilled testers will observe the behaviour and expect it.
  485. # [14:21] <wilhelm> andreastt: This is difficult to implement.
  486. # [14:22] <wilhelm> sms: We can choose to take as much complexity as possible close to us, and away from testers. This is difficult for us. Given the opportuinty, we should try to make the lives of testers as easy as possible.
  487. # [14:23] <wilhelm> andreastt: (Detailing complexities in keeping track of the correct order.)
  488. # [14:23] * Joins: darobin (rberjon@public.cloak)
  489. # [14:24] <wilhelm> kkania: For Chrome, this is easy to implement.
  490. # [14:24] <wilhelm> kkania: Shouldn't this be a must?
  491. # [14:25] <wilhelm> sms: Should the should be a must, or do we drop the clause?
  492. # [14:25] <wilhelm> davidburns: I go for the arbitrary option (may).
  493. # [14:25] <wilhelm> andreastt: I don't get the logic behind that this is how testers think.
  494. # [14:25] <wilhelm> andreastt: I believe they expect the order they opened them.
  495. # [14:26] <wilhelm> sms: You prefer to take this section out?
  496. # [14:26] <wilhelm> andreastt: Yes.
  497. # [14:26] <wilhelm> kkania: I don't have a strong opinion.
  498. # [14:26] <wilhelm> sms: So we take out this section.
  499. # [14:26] * Quits: shepazu (schepers@public.cloak)
  500. # [14:26] <wilhelm> sms: Window-ordering is non-deterministic.
  501. # [14:26] * Joins: shepazu (schepers@public.cloak)
  502. # [14:27] <wilhelm> ACTION: Remove the proposed ordering section in 6.3
  503. # [14:27] * RRSAgent records action 8
  504. # [14:28] <wilhelm> sms: A set in Java is unordered.
  505. # [14:29] <wilhelm> sms: I would like to take out XPath piece, but I don't think that is a good idea.
  506. # [14:29] <wilhelm> eranm: getText?
  507. # [14:30] <wilhelm> sms: Visibility and shown text has been flagged for being moved to CSS OM. We need to discuss this with them.
  508. # [14:30] <wilhelm> ACTION: sms to discuss with CSS WG to hand over visibility to CSS OM
  509. # [14:30] * RRSAgent records action 9
  510. # [14:31] <wilhelm> eranm: Handling of invalid SSL certificates.
  511. # [14:31] <wilhelm> sms: (Quotes spec chapter 5.2.1.)
  512. # [14:33] <wilhelm> sms: The default is to accept invalid certificates during testing.
  513. # [14:33] <wilhelm> davidburns: Should this be true by default?
  514. # [14:34] <wilhelm> sms: No, to address our largest audience.
  515. # [14:34] * Joins: JonathanJ (~hollobit@public.cloak)
  516. # [14:34] <wilhelm> davidburns: (Describing case of compromised mobile device.)
  517. # [14:36] <wilhelm> sms: This is a desired capability, not a required capability.
  518. # [14:38] <JonathanJ> rrsagent, draft minutes
  519. # [14:38] <RRSAgent> I have made the request to generate http://www.w3.org/2012/10/29-testing-minutes.html JonathanJ
  520. # [14:39] <wilhelm> sms: A sensible default is probably to allow access to insecure HTTPS to accomodate testers without control over their environment.
  521. # [14:39] <wilhelm> davidburns: The opposite would be a secure default.
  522. # [14:40] <wilhelm> sms: WebDriver itself is an insecure entity.
  523. # [14:40] <wilhelm> andreastt: I would expect the browser to behave normally.
  524. # [14:41] <wilhelm> sms: Testers doing manual testing against these shitty environments may have saved the override to accept the invalid certificate.
  525. # [14:41] <wilhelm> sms: They would forget about it and expect the test to just work.
  526. # [14:42] <wilhelm> sms: They'd blame WebDriver.
  527. # [14:43] <wilhelm> andreastt: The test author may expect that, but not a user.
  528. # [14:44] <wilhelm> andreastt: How does Chrome work here?
  529. # [14:44] <wilhelm> kkania: There is a command-line option for ignoring these messages.
  530. # [14:45] <wilhelm> andreastt: So for Chrome, this would involve setting said command-line option?
  531. # [14:45] <wilhelm> kkania: Yes.
  532. # [14:45] <wilhelm> eranm: Users would see the message and enable the flag, given the opposite default.
  533. # [14:46] <wilhelm> sms: We get bug reports on this.
  534. # [14:46] <eranm> wilhelm, my point was it doesn't make sense burdening every user with enabling this flag again and again
  535. # [14:47] <wilhelm> sms: The majority opinion is against mine. The default is secureSsl set to true.
  536. # [14:49] <wilhelm> andreastt: Our security peoplea are okay with this as long as we're running in an automated test mode.
  537. # [14:49] <wilhelm> davidburns: We're fine with it.
  538. # [14:49] <wilhelm> kkania: I'm fine with it.
  539. # [14:49] <wilhelm> sms: Default is allow insecure and local end can override that.
  540. # [14:49] * Quits: darobin (rberjon@public.cloak) (Client closed connection)
  541. # [14:50] <wilhelm> JohnJansen: How do you know if you're running in an automated test mode?
  542. # [14:50] <wilhelm> andreastt: A flag.
  543. # [14:50] <wilhelm> JohnJansen: A hacker can use that flag?
  544. # [14:50] <wilhelm> andreastt: Yes.
  545. # [14:50] <wilhelm> andreastt: You can enable the flag, but you can't trick the user to connect to a remote client.
  546. # [14:51] * Joins: a1zu (~androirc@public.cloak)
  547. # [14:52] * Quits: a12u (~androirc@public.cloak) (Client closed connection)
  548. # [14:52] * Joins: a12u (~androirc@public.cloak)
  549. # [14:54] * Quits: a1zu (~androirc@public.cloak) (Ping timeout: 20 seconds)
  550. # [15:01] <JonathanJ> rrsagent, draft minutes
  551. # [15:01] <RRSAgent> I have made the request to generate http://www.w3.org/2012/10/29-testing-minutes.html JonathanJ
  552. # [15:02] * Joins: darobin (rberjon@public.cloak)
  553. # [15:05] <jhammel> Scribe: jhammel
  554. # [15:05] <jhammel> sms: exceptions
  555. # [15:06] * Joins: trackbot (trackbot@public.cloak)
  556. # [15:06] <trackbot> Sorry... I don't know anything about this channel
  557. # [15:06] <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)
  558. # [15:06] <jhammel> eranm: browser connection: if the browser is offline, it makes sense to include in the standard as this is user-controlled
  559. # [15:06] <jhammel> davidburns: e.g. manifests
  560. # [15:07] <jhammel> sms: some browsers get really upset if you take them offline and try to communicate with them with other processes (i.e. Firefox)
  561. # [15:07] <jhammel> davidburns: haven't tried with marionette, but this may work better
  562. # [15:07] <jhammel> sms: if you start the browser in offline mode you couldn't open a socket
  563. # [15:08] <jhammel> jhammel: this might be fixed
  564. # [15:08] <jhammel> andreastt: is this something we want?
  565. # [15:08] <jhammel> andreastt: i support it
  566. # [15:08] <jhammel> davidburns: we support it
  567. # [15:08] <jhammel> davidburns: we need to find out where our boundary's finished and where another group begins
  568. # [15:09] <jhammel> davidburns: should be supported, since a user should be able to turn off the browser
  569. # [15:09] <plh> s/JohnJansen: How do you know if you're running in an automated test mode?//
  570. # [15:09] <plh> s/andreastt: A flag.//
  571. # [15:09] <jhammel> sms: how does the browser react? how do we continue controlling it?
  572. # [15:09] <plh> s/JohnJansen: A hacker can use that flag?//
  573. # [15:09] <plh> s/andreastt: Yes.
  574. # [15:09] <plh> s/andreastt: Yes.//
  575. # [15:09] <plh> s/andreastt: You can enable the flag, but you can't
  576. # [15:09] <plh> trick the user to connect to a remote client.//
  577. # [15:09] <jhammel> davidburns: if we can't access them, the offline mode should redirect to those pages
  578. # [15:09] <plh> s/andreastt: You can enable the flag, but you can't trick the user to connect to a remote client.//
  579. # [15:10] * plh rrsagent, generate minutes
  580. # [15:10] <RRSAgent> I have made the request to generate http://www.w3.org/2012/10/29-testing-minutes.html plh
  581. # [15:10] <jhammel> davidburns: the local side should be able to continue to talk to the browser
  582. # [15:10] <jhammel> sms: there's a difference between being offline and being able to reach into the browser
  583. # [15:10] <jhammel> eranm: application cache: the only API we have is to figure out the state of the applicaiton cache
  584. # [15:11] <jhammel> davidburns: the one thing, up for discussion, is clearing application cache; at the moment there is no JS input to clear application cache
  585. # [15:11] <jhammel> davidburns: chrome has asked for it and Jonas Sicking has asked for it as well
  586. # [15:11] <jhammel> davidburns: same as cookies
  587. # [15:12] <jhammel> davidburns: where possible, should delegate to the web apps working group
  588. # [15:12] <jhammel> eranm: so applicaiton cache is out of scope here?
  589. # [15:12] <jhammel> davidburns: yes
  590. # [15:12] <jhammel> andreastt: we have exposed the application cache for opera driver
  591. # [15:12] <jhammel> eranm: next: local storage access
  592. # [15:13] <jhammel> davidburns: i'm in favor of not looking after that; again, can be done with JS
  593. # [15:13] <jhammel> davidburns: local APIs could do the heavy lifting, but it is beyond scope of webdriver
  594. # [15:13] <jhammel> davidburns: we'd just be executing script with proper context
  595. # [15:14] <jhammel> sms: do we allow them to setup data prior to running their tests? do we treat them like cookies?
  596. # [15:14] <jhammel> davidburns: i'd go the cookie root
  597. # [15:14] <jhammel> sms: example: if you're on google.com you can't setup local storage for bing.com
  598. # [15:14] <jhammel> sms: but what if you need to?
  599. # [15:14] <jhammel> andreastt: it depends on how the profile is setup
  600. # [15:15] <jhammel> eranm: we allow modifying local storage in the same way we allow modifying cookies?
  601. # [15:15] <jhammel> davidburns: yes
  602. # [15:16] <jhammel> eranm: next: geolocation: api for getting current location and setting it?
  603. # [15:16] <jhammel> eranm: getting it is useful; setting it?
  604. # [15:16] <jhammel> wilhelm: use-case: you want to test your app that checks for restaurants nearby
  605. # [15:16] <jhammel> sms: setting definitely belongs in the standard
  606. # [15:17] <jhammel> andreastt: i'm fine with exposing get as well
  607. # [15:17] <jhammel> davidburns: from an API point of view it makes sense to have both get and set
  608. # [15:18] <jhammel> sms: companies seriously send people out with mobile phones and get them to stand in places, and then get the data from the phone
  609. # [15:19] <jhammel> sms: it was brought up: "What if you never call set?"
  610. # [15:19] <jhammel> sms: it seems the actual physical location of the device is what you get back
  611. # [15:19] <jhammel> davidburns: that sounds sane
  612. # [15:20] <jhammel> eranm: if the location is set in a test, the browser should not respond with location confirmation
  613. # [15:20] <jhammel> wilhelm: i load the browser and load the page that wants to find restaurants nearby
  614. # [15:21] <jhammel> wilhelm: it asks for confirmation and i deny it
  615. # [15:21] <jhammel> wilhelm: presumedly your browser has some behaviour if this happens
  616. # [15:21] <jhammel> sms: should this be a capability
  617. # [15:21] <jhammel> andreastt: this should not be a capability
  618. # [15:21] <jhammel> sms: how do you deal with a popup: "Maps wants to share your location..."?
  619. # [15:22] <jhammel> sms: as a user you do know this is coming; should this be treated as an alert?
  620. # [15:22] <jhammel> andreastt: we should treat this as SSL
  621. # [15:22] <jhammel> sms: so that's a capability
  622. # [15:22] <jhammel> sms: you'd have to restart the browser to test; that seems fair
  623. # [15:23] <jhammel> sms: if we've set it to false, we say "No you absolutely can't have my location"
  624. # [15:23] <jhammel> wilhelm: it makes sense to mirror SSL
  625. # [15:23] <jhammel> wilhelm: permissive by default
  626. # [15:23] <jhammel> andreastt: we should still keep the API for getting the settings
  627. # [15:24] <jhammel> andreastt: what wil be the result of the actions if you're on a browser without geolocation?
  628. # [15:24] <jhammel> sms: we won't expose that capability
  629. # [15:24] <jhammel> sms: there will be a capability that says: i won't support this ability
  630. # [15:24] <jhammel> sms: e.g. null for location
  631. # [15:25] <jhammel> andreastt: we're setting a precedent for how to handle these capabilities [wrt enableSSL parity]
  632. # [15:25] <jhammel> sms: if we're happy with that we should go for it gung ho;
  633. # [15:26] <jhammel> new topic: davidburns: Mozilla has a big standing against DB storage
  634. # [15:26] <jhammel> sms: database storage has been deprecated
  635. # [15:27] <jhammel> Philippe : the reason it disappeared is because since Microsoft and Mozilla didn't implement it, they basically killed it
  636. # [15:28] <jhammel> sms: one of the nice things is that we can send pure javascript and have it executed
  637. # [15:28] <jhammel> Philippe: that got replaced by indexdb
  638. # [15:28] <jhammel> Philippe: IE10, Mozilla, Chrome are doing it
  639. # [15:29] <jhammel> JohnJansen: it is more performant than other data storage solutions
  640. # [15:29] <jhammel> andreastt: supported in chrome, firefox, and IE
  641. # [15:29] <jhammel> andreastt: none of the mobile phones except ???
  642. # [15:30] <jhammel> Philippe: switching to indexdb but not widely deployed yet
  643. # [15:30] <jhammel> sms: i'm for holding off until someone asks for it
  644. # [15:30] <jhammel> sms: does anything else have anything to discuss today?
  645. # [15:31] <jhammel> sms: do we want webdriver OSS project to become the tomcat of the webdriver spec?
  646. # [15:31] <jhammel> davidburns: your suggesting the tests be in the selenium project?
  647. # [15:32] <jhammel> sms: they will be in the w3c, but selenium can have more tests
  648. # [15:33] <jhammel> sms: we could continue the status quo
  649. # [15:34] <jhammel> sms: agenda for tomorrow: writing tests
  650. # [15:34] <jhammel> andreastt: ... HTML contacts
  651. # [15:35] <jhammel> andreastt: canvas, svg, xhtml, xml...
  652. # [15:35] * Quits: byungjung_ (~byungjung@public.irc.w3.org) (Ping timeout: 20 seconds)
  653. # [15:35] <jhammel> sms: if its covered by the w3c spec it is fair game
  654. # [15:36] <jhammel> sms: what about plain text?
  655. # [15:36] <jhammel> sms: maybe text as well
  656. # [15:37] <jhammel> sms: another thing that we don't handle is pdf
  657. # [15:38] <jhammel> Philippe: [putting text in a <pre>] is part of the HTML5 spec
  658. # [15:39] * Parts: kkania (~kkania@public.cloak) (kkania)
  659. # [15:39] <plh> [adjourned]
  660. # [15:39] * plh rrsagent, generate minutes
  661. # [15:39] <RRSAgent> I have made the request to generate http://www.w3.org/2012/10/29-testing-minutes.html plh
  662. # [15:39] <plh> rrsagent, bye
  663. # [15:39] <RRSAgent> I see 9 open action items saved in http://www.w3.org/2012/10/29-testing-actions.rdf :
  664. # [15:39] <RRSAgent> ACTION: Make the section on the JSON wire protocol normative [1]
  665. # [15:39] * Quits: eranm (~eranm@public.cloak) ("This computer has gone to sleep")
  666. # [15:39] <RRSAgent> recorded in http://www.w3.org/2012/10/29-testing-irc#T10-19-30
  667. # [15:39] <RRSAgent> ACTION: JonathanJ to give input on non-latin character input [2]
  668. # [15:39] <plh> zakim, bye
  669. # [15:39] <RRSAgent> recorded in http://www.w3.org/2012/10/29-testing-irc#T10-46-40
  670. # [15:39] <RRSAgent> ACTION: davidburns to look into how the DOM spec handles keyboard events and internationalisation [3]
  671. # [15:39] <RRSAgent> recorded in http://www.w3.org/2012/10/29-testing-irc#T10-47-39
  672. # [15:39] <RRSAgent> ACTION: Write a section on handling the shadow DOM that mirrors the JS APIs [4]
  673. # [15:39] <RRSAgent> recorded in http://www.w3.org/2012/10/29-testing-irc#T11-03-22
  674. # [15:39] <RRSAgent> ACTION: In the common case of success, the status code is left as the null value. If omitted, treat it as null. [5]
  675. # [15:39] <RRSAgent> recorded in http://www.w3.org/2012/10/29-testing-irc#T11-32-40
  676. # [15:39] <RRSAgent> ACTION: Strings replace numbers in errors [6]
  677. # [15:39] <RRSAgent> recorded in http://www.w3.org/2012/10/29-testing-irc#T11-33-08
  678. # [15:39] <RRSAgent> ACTION: Windows are to be the same as a top-level browsing context (as defined in HTML) [7]
  679. # [15:39] <RRSAgent> recorded in http://www.w3.org/2012/10/29-testing-irc#T13-13-48
  680. # [15:39] <RRSAgent> ACTION: Remove the proposed ordering section in 6.3 [8]
  681. # [15:39] <RRSAgent> recorded in http://www.w3.org/2012/10/29-testing-irc#T13-24-28
  682. # [15:39] <RRSAgent> ACTION: sms to discuss with CSS WG to hand over visibility to CSS OM [9]
  683. # [15:40] <RRSAgent> recorded in http://www.w3.org/2012/10/29-testing-irc#T13-27-35
  684. # [15:40] * Parts: RRSAgent (rrsagent@public.irc.w3.org) (RRSAgent)
  685. # [15:40] * Quits: sms (~simonstewart@public.cloak) (sms)
  686. # [15:42] * Quits: JonathanJ (~hollobit@public.cloak) (Ping timeout: 20 seconds)
  687. # [15:42] * Quits: plh (plehegar@public.cloak) ("always accept cookies")
  688. # [15:46] * Quits: jhammel (~jhammel@public.cloak) (Ping timeout: 20 seconds)
  689. # [15:47] * Joins: jhammel (~jhammel@public.cloak)
  690. # [15:47] * Quits: a12u (~androirc@public.cloak) (Ping timeout: 20 seconds)
  691. # [15:53] * Quits: darobin (rberjon@public.cloak) (Client closed connection)
  692. # [15:55] * Joins: a12u (~androirc@public.cloak)
  693. # [15:56] * Quits: jhammel (~jhammel@public.cloak) (Ping timeout: 20 seconds)
  694. # [15:56] * Quits: JohnJansen (~JohnJansen@public.cloak) (Ping timeout: 20 seconds)
  695. # [16:02] * Quits: davidburns (~davidburns@public.cloak) (Client closed connection)
  696. # [16:03] * Joins: eranm (~eranm@public.cloak)
  697. # [16:04] * Joins: darobin (rberjon@public.cloak)
  698. # [16:04] * Quits: trackbot (trackbot@public.cloak) (Client closed connection)
  699. # [16:05] * Joins: eranm_ (~eranm@public.cloak)
  700. # [16:07] * Joins: a1zu (~androirc@public.cloak)
  701. # [16:07] * Quits: a12u (~androirc@public.cloak) (Client closed connection)
  702. # [16:07] * Quits: eranm (~eranm@public.cloak) (Ping timeout: 60 seconds)
  703. # [16:17] * Joins: JohnJansen (~JohnJansen@public.cloak)
  704. # [16:20] * Joins: JonathanJ (~hollobit@public.cloak)
  705. # [16:23] * Joins: jhammel (~jhammel@public.cloak)
  706. # [16:38] * Joins: tpacbot (~nodebot@public.cloak)
  707. # [16:47] * Joins: plh (plehegar@public.cloak)
  708. # [17:05] * Quits: JonathanJ (~hollobit@public.cloak) (Ping timeout: 60 seconds)
  709. # [17:06] * Quits: darobin (rberjon@public.cloak) (Client closed connection)
  710. # [17:11] * Quits: shepazu (schepers@public.cloak) ("is sleepy")
  711. # [17:18] * Quits: a1zu (~androirc@public.cloak) (Ping timeout: 60 seconds)
  712. # [17:19] * Quits: MikeSmith (~MikeSmith@public.cloak) (MikeSmith)
  713. # [17:36] * Quits: Lachy (~Lachy@public.cloak) ("Computer has gone to sleep.")
  714. # [17:38] * Quits: eranm_ (~eranm@public.cloak) ("This computer has gone to sleep")
  715. # [17:48] * Quits: ArtB (~abarsto@public.cloak) ("Leaving.")
  716. # [17:49] * Joins: Lachy (~Lachy@public.cloak)
  717. # [17:53] * Quits: Lachy (~Lachy@public.cloak) ("Computer has gone to sleep.")
  718. # [17:55] * Joins: darobin (rberjon@public.cloak)
  719. # [17:59] * Quits: shadi (shadi@public.cloak)
  720. # [18:00] * Quits: tpacbot (~nodebot@public.cloak) (Client closed connection)
  721. # [18:02] * Joins: Lachy (~Lachy@public.cloak)
  722. # [18:05] * Parts: jari (~jari@public.cloak) (jari)
  723. # [18:06] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
  724. # [18:07] * Joins: eranm (~eranm@public.cloak)
  725. # [18:08] * Quits: eranm (~eranm@public.cloak) ("Leaving")
  726. # [18:10] * Quits: plh (plehegar@public.cloak) (Ping timeout: 60 seconds)
  727. # [18:11] * Joins: a12u (~androirc@public.cloak)
  728. # [18:21] * Quits: jhammel (~jhammel@public.cloak) ("leaving")
  729. # [18:24] * Joins: a1zu (~androirc@public.cloak)
  730. # [18:24] * Quits: a12u (~androirc@public.cloak) (Client closed connection)
  731. # [18:26] * Quits: JohnJansen (~JohnJansen@public.cloak) (Ping timeout: 60 seconds)
  732. # [18:26] * Quits: a1zu (~androirc@public.cloak) ("AndroIRC - Android IRC Client ( http://www.androirc.com )")
  733. # [18:27] * Quits: Lachy (~Lachy@public.cloak) ("Computer has gone to sleep.")
  734. # [18:32] * Quits: darobin (rberjon@public.cloak) (Client closed connection)
  735. # [18:35] * Joins: glenn (~gadams@public.cloak)
  736. # [19:08] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
  737. # [21:48] * Joins: glenn (~gadams@public.cloak)
  738. # [23:04] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
  739. # [23:31] * Joins: glenn (~gadams@public.cloak)
  740. # [23:47] * Joins: tpacbot (~nodebot@public.cloak)
  741. # Session Close: Tue Oct 30 00:00:00 2012

The end :)