Options:
- # Session Start: Mon Oct 29 00:00:00 2012
- # Session Ident: #testing
- # [00:22] * Joins: Lachy (~Lachy@public.cloak)
- # [06:24] * Quits: Lachy (~Lachy@public.cloak) (Ping timeout: 20 seconds)
- # [06:29] * Joins: byungjung (~byungjung@public.cloak)
- # [06:31] * Joins: MikeSmith (~MikeSmith@public.cloak)
- # [06:31] * Parts: byungjung (~byungjung@public.irc.w3.org)
- # [07:38] * Joins: Lachy (~Lachy@public.cloak)
- # [08:00] * Quits: MikeSmith (~MikeSmith@public.cloak) (MikeSmith)
- # [08:09] * Quits: Lachy (~Lachy@public.cloak) ("Computer has gone to sleep.")
- # [08:42] * Joins: bryan (~bryan@public.irc.w3.org)
- # [08:48] <wilhelm> 'Morning!
- # [08:48] <jgraham> Hi ho
- # [08:49] * Joins: byungjung (~byungjung@public.irc.w3.org)
- # [08:51] * Joins: simonstewart (~simonstewart@public.cloak)
- # [08:52] * Quits: simonstewart (~simonstewart@public.cloak) (Client closed connection)
- # [08:53] * Joins: sms (~simonstewart@public.cloak)
- # [08:53] <sms> He shoots! He scores!
- # [08:53] * Joins: RRSAgent (rrsagent@public.irc.w3.org)
- # [08:53] <RRSAgent> logging to http://www.w3.org/2012/10/29-testing-irc
- # [08:53] * Joins: jhammel (~jhammel@public.cloak)
- # [08:54] * Joins: Lachy (~Lachy@public.cloak)
- # [08:55] <wilhelm> RRSAgent, draft minutes
- # [08:55] <RRSAgent> I have made the request to generate http://www.w3.org/2012/10/29-testing-minutes.html wilhelm
- # [08:56] * Joins: eranm (~eranm@public.cloak)
- # [08:57] <wilhelm> Meeting: Browser Testing and Tools WG, Monday, TPAC
- # [08:57] <wilhelm> Chair: wilhelm
- # [08:57] * Joins: kkania (~kkania@public.cloak)
- # [08:57] <wilhelm> Agenda: http://lists.w3.org/Archives/Public/public-test-infra/2012OctDec/0019.html
- # [08:58] * Joins: abarsto (~abarsto@public.cloak)
- # [08:58] * abarsto is now known as ArtB
- # [09:03] <wilhelm> RRSAgent, make log public
- # [09:03] <RRSAgent> I have made the request, wilhelm
- # [09:04] * Joins: jari (~jari@public.cloak)
- # [09:04] <sms> Hi jari
- # [09:04] <sms> I should change my nick
- # [09:04] * sms is now known as simonstewart
- # [09:04] <simonstewart> That's better
- # [09:04] <jari> hi
- # [09:05] * Joins: JohnJansen_ (~JohnJansen@public.irc.w3.org)
- # [09:05] <simonstewart> The room's looking a little bare now
- # [09:05] <simonstewart> (physical room, that is)
- # [09:06] * Joins: ato (~ato@public.cloak)
- # [09:06] * ato is now known as andreastt
- # [09:06] * andreastt waves
- # [09:06] * simonstewart waves back
- # [09:09] <simonstewart> Starting in 5 minutes
- # [09:09] * simonstewart starts large countdown clock
- # [09:10] * Joins: shadi (shadi@public.cloak)
- # [09:10] <jgraham> (does it have the countdown music for the last 30 seconds?)
- # [09:10] <jhammel> it should!
- # [09:11] * Joins: shepazu (schepers@public.cloak)
- # [09:11] <simonstewart> I'll be sure to hum it loudly
- # [09:12] * Quits: shepazu (schepers@public.cloak)
- # [09:12] <wilhelm> Scribe: jhammel
- # [09:12] * Joins: shepazu (schepers@public.cloak)
- # [09:15] <wilhelm> RRSAgent, draft minutes
- # [09:15] <RRSAgent> I have made the request to generate http://www.w3.org/2012/10/29-testing-minutes.html wilhelm
- # [09:15] <jhammel> wilhelm: is the list of would-be attendents publically available?
- # [09:15] * Joins: plh (plehegar@public.cloak)
- # [09:16] <wilhelm> jhammel: https://www.w3.org/2002/09/wbs/35125/TPAC2012/registrants
- # [09:16] <jhammel> thanks
- # [09:16] <simonstewart> We've had our 5 minutes
- # [09:18] * simonstewart stops playing the countdown clock video
- # [09:18] <simonstewart> And we're off!
- # [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?
- # [09:19] * plh wonders if Mike Smith is in the Testing WG f2f
- # [09:23] <jhammel> introductions: Michael Smith, Andreas Tolfsen, Shangyi Chen, Jeff Hammel, Larry Masinter, Wilhelm Andersen, Simon Stewart, [more]
- # [09:26] <jhammel> introductions: Byungjung Kim, John Jansen, Ken Kenia
- # [09:27] <jhammel> simonstewart: 3 audiences for driving a browser
- # [09:27] <jhammel> simonstewart: 1. people that want to drive a web application end to end
- # [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
- # [09:29] <jhammel> simonstewart: webdriver integrates tightly with the browser; so webdriver + selenium merged to become selenium 2
- # [09:30] <jhammel> simonstewart: webdriver is currently the API of selenium
- # [09:30] <jhammel> </aside>
- # [09:30] <jhammel> 2nd group of people: browser vendors
- # [09:31] <jhammel> andreastt: Opera's made a huge undertaking in converting testing to use the webdriver API
- # [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)
- # [09:32] <jhammel> simonstewart: i've thrown together a quick demo
- # [09:33] <jhammel> simonstewart: walk through demo: first create a browser instance; get a particular URL ...
- # [09:34] <jhammel> simonstewart: webdriver represents a browser instance, but people are interested in elements on a page; [demos how to get an element]
- # [09:35] <jhammel> simonstewart: summary: we're going to google, searching for cheese, then arrowing down for autocomplete
- # [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
- # [09:38] <jhammel> larry masinter: there are no assertions?
- # [09:39] <jhammel> simonstewart: no, assertions aren't part of the webdriver API; this is left to whoever is writing the tests/scripts
- # [09:40] * Quits: plh (plehegar@public.cloak) (Ping timeout: 60 seconds)
- # [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
- # [09:41] <jhammel> simonstewart: there is a JS binding for webdriver for nodejs
- # [09:42] <jhammel> simonstewart: there are multiple implementations of webdriver; the OSS project is where the webdriver work began
- # [09:42] <jhammel> simonstewart: opera were the first implementators of webdriver; written separately, but using the OSS project to ensure compatability
- # [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
- # [09:43] <jhammel> Larry Masinter: You want to test scrubbing through a video; is that doable?
- # [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
- # [09:44] <jhammel> simonstewart: example: canvas; writing to canvas isn't generally done with testability in mind
- # [09:45] * Joins: plh (plehegar@public.cloak)
- # [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)
- # [09:45] <jhammel> wilhelm: isn't the video element just shadow DOM?
- # [09:46] <jhammel> simonstewart: one of our topics is dealing with the shadow DOM
- # [09:46] <jhammel> simonstewart: other open questions: SVG, a11y
- # [09:46] <jhammel> simonstewart: a surprising amount of web pages are still JS and HTML
- # [09:47] <jhammel> Larry Masinter: having a roadmap of what needs to be done would be really useful
- # [09:47] <jhammel> simonstewart: there is a section on extending the protocol; extending the APIs + vendor extensions
- # [09:47] <jhammel> simonstewart: example: wouldn't it be nice to have a API for bookmarks? However this is done differently across browsers
- # [09:47] <jhammel> simonstewart: process: experiment; see what works and doesn't; consolidate on what works
- # [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
- # [09:49] <jhammel> simonstewart: then figuring out what people really want
- # [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
- # [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)
- # [09:51] <jhammel> Andreas Tolfsen: we can look at the webdriver API as part of that infrastructure
- # [09:51] <jhammel> Andreas: we use webdriver to run the tests; then we use another framework actually handle the testing
- # [09:51] * Joins: MikeSmith (~MikeSmith@public.cloak)
- # [09:52] <jhammel> Andreas: webdriver needs to be much more generic than just browser testing
- # [09:53] <MikeSmith> RRSAgent, make minutes
- # [09:53] <RRSAgent> I have made the request to generate http://www.w3.org/2012/10/29-testing-minutes.html MikeSmith
- # [09:53] <jhammel> Andreas: the screenshot story is a bit complicated
- # [09:55] <jhammel> Andreas: if we take screenshots externally, should that be part of the spec? otherwise, this could trigger a window repaint
- # [09:56] <jhammel> jhammel: so webdriver is fundamentally a browser automation framework, not a testing framework
- # [09:56] <jhammel> simonstewart: yes
- # [09:56] <jhammel> Larry Masinter: but it is the browser testing charter?
- # [09:57] <MikeSmith> RRSAgent, make minutes
- # [09:57] <RRSAgent> I have made the request to generate http://www.w3.org/2012/10/29-testing-minutes.html MikeSmith
- # [09:57] <jhammel> Simon Stewart: yes, we need to ensure that webdriver supports all that is needed to test
- # [09:57] <jhammel> Larry Masinter: I wonder if we could do fuzzing
- # [09:57] <jhammel> Andreas: it would be difficult to try to put all security testing into webdriver
- # [09:58] <jhammel> Simon Stewart: tests that involve using a browser like a user are good candidates for webdriver automation
- # [09:59] <jhammel> Wilhelm: Next topic: State of the union: where is the spec right now?
- # [09:59] <jhammel> Simon: I've landed a bunch of edits; the specification is moving forward
- # [10:00] <jhammel> Simon: the OSS selenium project; 15-100 checkins / week ; most of this is refining capabilities
- # [10:00] <jhammel> Simon: (handling edge cases, etc); the broad strokes are fairly well defined
- # [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
- # [10:01] <jhammel> Simon: some sections are fairly flushed out; some are skeletal
- # [10:01] <jhammel> Simon: the implementations are further along than the specification because of a common test suite
- # [10:02] <jhammel> Wilhelm: which sections are finished?
- # [10:02] * Joins: glenn (~gadams@public.cloak)
- # [10:02] * Joins: JonathanJ1 (~hollobit@public.cloak)
- # [10:03] <jhammel> Simon: Commands+Responses flushed out ...; Switching windows; Running without focus : spec says you should; ...
- # [10:03] <jhammel> Simon: if you can use the OSS tests section 10 makes a lot of sense
- # [10:04] <jhammel> Simon: cookies = WIP; ...; Modal dialogues: skeletal; screenshots aren't flushed out
- # [10:05] <jhammel> Simon: How we do logging in webdriver: logging is out of process
- # [10:05] <jhammel> Simon: selenium grid: driver + client may be running on different machines
- # [10:06] <jhammel> simonstewart: vs in process; maybe console.log has all we care about
- # [10:06] <jhammel> Larry Masinter: You have logging but no assertions
- # [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
- # [10:07] <jhammel> Larry Masinter: The logs would include assertion failures
- # [10:07] <jhammel> Simon: No; it is only internal logging
- # [10:07] <jhammel> Larry Masinter: What do you need to do with the logs that require standardization
- # [10:07] <jhammel> e.g. the console of the browser
- # [10:07] <jhammel> Larry Masinter: If different browsers log differently, does that matter?
- # [10:08] <jhammel> Simon: There isn't a standard for the content of the logs
- # [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
- # [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
- # [10:10] <jhammel> Simon: we need that format in order to be able to get the logs
- # [10:10] <jhammel> Simon: we haven't put assertions in, but we've given you the ability to put assertions in
- # [10:10] <jhammel> Simon: its not active logging; its fairly passive
- # [10:12] <jhammel> Larry Masinter: roadmap: how do you ensure adequate consistency? are we writing our specs too precisely?
- # [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
- # [10:14] <jhammel> Larry Masinter: there may be operations that can only be done with multitouch, etc
- # [10:14] <jhammel> Simon Stewart: you can query your webdriver instance for the capabilities it supports
- # [10:14] <jhammel> Simon Stewart: e.g. do i support touch actions?
- # [10:15] <jhammel> Larry Masinter: would you use media queries to determine what tests are run?
- # [10:15] <jhammel> Simon Stewart: no; in the OSS project, you only run tests if the assumption is true
- # [10:16] * Quits: byungjung (~byungjung@public.irc.w3.org) (Ping timeout: 20 seconds)
- # [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
- # [10:17] <jhammel> John Jansen: How do i easily determine the diff between red+blue?
- # [10:18] <jhammel> Simon Stewart: using diff from the VCS; would you prefer a different way?
- # [10:18] * Joins: byungjung (~byungjung@public.irc.w3.org)
- # [10:18] <jhammel> John: is that pushed decided by the wg?
- # [10:18] <jhammel> Simon Stewart: Yes
- # [10:19] <jhammel> Wilhelm: is there any particular reason why you care about the blue one over the red one?
- # [10:19] <jhammel> John: mostly out of habit
- # [10:19] <jhammel> Simon: because of the way we're writing the specification, blue isn't invalid
- # [10:20] <simonstewart> http://dvcs.w3.org/hg/webdriver/raw-file/tip/webdriver-spec.html#commands-and-responses
- # [10:20] <jhammel> Wilhelm: Blue refers to the published working draft; red is the editor draft
- # [10:20] <simonstewart> http://dvcs.w3.org/hg/webdriver/raw-file/tip/webdriver-spec.html
- # [10:20] <simonstewart> http://www.w3.org/TR/webdriver/
- # [10:21] <simonstewart> jhammel: those links probably won't be in the minutes unless you scribe them
- # [10:21] <jhammel> Wilhelm: What do you all want from the webdriver spec? What do you want from this meeting
- # [10:21] <jhammel> location of webdriver spec: http://www.w3.org/TR/webdriver/
- # [10:21] <simonstewart> thanks :)
- # [10:22] <jhammel> andreastt: we want web developers to be able to use opera when testing
- # [10:22] * Joins: darobin (rberjon@public.cloak)
- # [10:22] <jhammel> Andreas: to ensure that they have site compatability
- # [10:22] <jhammel> Andreas: last year, we released our HTML5 parser; we also got sites to run our test suite versus their sites
- # [10:24] <jhammel> Jeff Hammel: trying to figure out what Mozilla needs to do to get Marionette + webdriver on spec
- # [10:24] <jhammel> Shangyi Chen: trying to observe what is the progress is being done
- # [10:25] <jhammel> Shangyi Chen: Baidu using webdriver
- # [10:26] <jhammel> John Jansen: trying to solve big problems at microsoft; this is one point of input
- # [10:26] <jhammel> Wilhelm: last time i wanted to test my browser; today i want to test my sites with various browsers
- # [10:27] <jhammel> Wilhelm: want the spec to move forward; want all WGs to test all the specs they're working on
- # [10:27] <jhammel> wilhelm: want to be able to point to a spec to say, 'Use this spec to test all other specs'
- # [10:28] <jhammel> Simon: working on webdriver for 7 years now; has become the de facto way of testing web apps
- # [10:28] <jhammel> Simon: I want to standardize it; as the web gets more capability, it becomes harder and harder
- # [10:28] * Quits: ArtB (~abarsto@public.cloak) (Client closed connection)
- # [10:28] * Joins: abarsto (~abarsto@public.cloak)
- # [10:28] * abarsto is now known as ArtB
- # [10:28] <jhammel> Simon: need support from the browser vendors; webdriver is one of the tools in the arsenal
- # [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
- # [10:30] <jhammel> ?: Make sure the spec is understood; the more help we can get from browser vendors, the better
- # [10:30] <jhammel> ?: figure out the limits of the spec; figure out what can be done to extend these limits
- # [10:30] * Quits: darobin (rberjon@public.cloak) (Client closed connection)
- # [10:31] <jhammel> Ken Kenia: primary concern for chrome team is website compatability
- # [10:31] <jhammel> Ken Kenia: can test websites across browsers quickly
- # [10:31] <jhammel> Ken Kenia: we don't use webdriver as pervasively as Opera
- # [10:31] <jhammel> Larry Masinter: Does webkit use webdriver?
- # [10:32] <jhammel> Ken Kenia: not currently with internal testing
- # [10:32] <jhammel> Larry Masinter: should it?
- # [10:32] <jhammel> Simon: there are at least two projects that are based on webkit that need to do testing; so yes
- # [10:33] <jhammel> Simon: it simplifies the vendors work; it simplifies the driver's work
- # [10:33] <jhammel> Wilhelm: is there anything this WG can do to help with the politics of webkit?
- # [10:33] <jhammel> Wilheml: if so we should do it
- # [10:33] <jhammel> Simon: webkit is worked largely on by Chromium; though Apple depends on it too
- # [10:34] <jhammel> Simon: is there anything we can do to encourage participation by MS?
- # [10:34] <jhammel> John: let's talk about that later
- # [10:34] * Quits: kkania (~kkania@public.cloak) (kkania)
- # [10:35] * Quits: simonstewart (~simonstewart@public.cloak) (simonstewart)
- # [10:35] * Joins: sms (~simonstewart@public.cloak)
- # [10:36] * Quits: bryan (~bryan@public.irc.w3.org) (Ping timeout: 20 seconds)
- # [10:36] * Quits: byungjung (~byungjung@public.irc.w3.org) (Ping timeout: 20 seconds)
- # [10:37] * Quits: JonathanJ1 (~hollobit@public.cloak) (Ping timeout: 20 seconds)
- # [10:46] * Quits: eranm (~eranm@public.cloak) ("This computer has gone to sleep")
- # [10:58] * Quits: JohnJansen_ (~JohnJansen@public.irc.w3.org) ("Page closed")
- # [11:01] <wilhelm> RRSAgent, draft minutes
- # [11:01] <RRSAgent> I have made the request to generate http://www.w3.org/2012/10/29-testing-minutes.html wilhelm
- # [11:03] * Joins: JohnJansen (~JohnJansen@public.cloak)
- # [11:07] * Joins: davidburns (~davidburns@public.cloak)
- # [11:07] * Joins: kkania (~kkania@public.cloak)
- # [11:07] * Joins: eranm (~eranm@public.cloak)
- # [11:07] <sms> Here we go again!
- # [11:07] <wilhelm> Chair: sms
- # [11:08] <sms> Chair: simonstewart
- # [11:08] <wilhelm> Scribe: wilhelm
- # [11:08] <sms> Ohhh... I'm back as sms
- # [11:08] <sms> Interesting
- # [11:08] <wilhelm> Topic: Discussion of open issues in the spec
- # [11:08] <jhammel> http://lists.w3.org/Archives/Public/public-test-infra/2012OctDec/0019.html
- # [11:08] * Joins: byungjung (~byungjung@public.irc.w3.org)
- # [11:09] <wilhelm> (See list of open issues in the agenda.)
- # [11:10] * Quits: eranm (~eranm@public.cloak) (Ping timeout: 20 seconds)
- # [11:10] * Joins: eranm (~eranm@public.cloak)
- # [11:10] <wilhelm> sms: Some parts of the spec is integer-heavy. (Points to error codes.) We could use strings instead.
- # [11:10] <wilhelm> Topic: Interoperability
- # [11:11] <wilhelm> sms: The spec, as written, does not describe a transport mechanism and how to encode data.
- # [11:11] * Joins: JonathanJ (~hollobit@public.cloak)
- # [11:12] <wilhelm> sms: This is for historical reasons. Different drivers use different protocols.
- # [11:12] <wilhelm> sms: It is possible to follow the spec - and not be interoperable.
- # [11:14] <wilhelm> sms: Suggestion, listed as a note in the spec: implementations should allow the use of JSON wire protocol.
- # [11:15] <wilhelm> sms: It would be possible to write an implementation specific to one language. For example a proprietary connector for mobile.
- # [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.
- # [11:16] <wilhelm> sms: At the same time introducing a new device/platform/browser must be easy.
- # [11:16] <wilhelm> jhammel: The goal is to encourage it, not enforce it?
- # [11:16] <wilhelm> sms: We could say "must".
- # [11:16] <JonathanJ> rrsagent, draft minutes
- # [11:16] <RRSAgent> I have made the request to generate http://www.w3.org/2012/10/29-testing-minutes.html JonathanJ
- # [11:16] <wilhelm> sms: This is currently in a non-normative section.
- # [11:17] <wilhelm> sms: We could make that spec normative.
- # [11:17] <wilhelm> wilhelm: Why shouldn't we?
- # [11:17] <wilhelm> sms: Nokia was against using JSON over HTTP. Maybe they don't mind a shim.
- # [11:18] <wilhelm> sms: One suggestion is we mandate that every implementation must have the shim.
- # [11:20] <wilhelm> (Tangent about malicious commits to the conformance test suite using something else than the JSON wire protocol.)
- # [11:20] <wilhelm> andreastt: Has other specs faced this problem?
- # [11:21] <wilhelm> sms: WebDriver is the only out of process spec that tries to have a consistent API.
- # [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.
- # [11:21] <wilhelm> sms: This is a fairly safe tech stack.
- # [11:22] * Quits: kkania (~kkania@public.cloak) (kkania)
- # [11:22] <wilhelm> ACTION: Make the section on the JSON wire protocol normative
- # [11:22] * RRSAgent records action 1
- # [11:23] <wilhelm> (Discussion on whether all drivers will be part of the open source project.)
- # [11:25] <wilhelm> (Discussion on language agnosticism.)
- # [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.
- # [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.
- # [11:30] <wilhelm> sms: The shim should be on the side of the browser vendor.
- # [11:31] <wilhelm> kkania: Is there a reason for out-of-process instead of in-process executable?
- # [11:31] <wilhelm> sms: This is a may. Implementors are free to bake this into their browser.
- # [11:31] <wilhelm> andreastt: These are implementation specifics, no? If you are writing something for your own uses, this doesn't cause any trouble.
- # [11:32] <wilhelm> kkania: Is there a reason for why we want JSON over HTTP?
- # [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.
- # [11:32] <wilhelm> sms: Works independently of bitness (32 vs 64 bit).
- # [11:33] <wilhelm> andreastt: And this only covers the C implementations.
- # [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.
- # [11:34] <wilhelm> sms: I wrote a JS client that used XHR.
- # [11:34] * Joins: darobin (rberjon@public.cloak)
- # [11:34] <wilhelm> sms: One of the major audiences are people testing their web applications. Many of these people don't have root.
- # [11:35] <wilhelm> sms: They might not even allow you to install any software. This rapidly became a nightmare.
- # [11:35] <wilhelm> andreastt: In the millitary, you may not even have access to the Internet.
- # [11:35] <wilhelm> jhammel: You might even do this manually via telnet, typing everything.
- # [11:36] <wilhelm> sms: This is currently covered by appendix E. This will be moved into the body of the spec, as normative prose.
- # [11:36] <wilhelm> Topic: Internationalised input
- # [11:37] <wilhelm> sms: There are two use cases for internationalised input.
- # [11:37] <wilhelm> sms: Am I doing proper roundtripping with international characters?
- # [11:37] * Quits: plh (plehegar@public.cloak) (Ping timeout: 60 seconds)
- # [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).
- # [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.
- # [11:39] <wilhelm> eranm: IME is only used for complex alphabets.
- # [11:39] <wilhelm> andreastt: We have not done any work on IMEs. We don't check if the keys exist on the keyboard.
- # [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.
- # [11:40] <wilhelm> sms: Mobiles have different input methods.
- # [11:40] <wilhelm> sms: Choose a different keyboard, long press on E to get É, etc.
- # [11:41] <wilhelm> andreastt: On fature phones you have predefined buttons that can be programmed. This also applies to some smartphones. Programmable keys.
- # [11:41] <wilhelm> andreastt: You don't know what's going to be on the keyboard.
- # [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?
- # [11:42] <wilhelm> eranm: Since we've added support, nobody has actually used it.
- # [11:42] <wilhelm> eranm: There are 1.5 billion people using complex scripts. Solicit input from them?
- # [11:42] <wilhelm> eranm: Hebrew/Arabic are much simpler. What we have may be good enough.
- # [11:43] <wilhelm> sms: So we should move IME to non-normative.
- # [11:43] <wilhelm> andreastt: É is registered as two different characters in the browser.
- # [11:43] <JonathanJ> rrsagent, draft minutes
- # [11:43] <RRSAgent> I have made the request to generate http://www.w3.org/2012/10/29-testing-minutes.html JonathanJ
- # [11:44] <wilhelm> andreastt: Complicating factor: OS specific stuff.
- # [11:44] * Joins: plh (plehegar@public.cloak)
- # [11:44] <wilhelm> sms: And different keyboard layouts: Norwegian/English/etc.
- # [11:44] <wilhelm> sms: Sometimes there will be a mapping to a key, sometimes it won't.
- # [11:44] <wilhelm> sms: If there is a character on the keyboard, we can just send the right character.
- # [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.
- # [11:46] <wilhelm> davidburns: We should not go in detail on this.
- # [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.
- # [11:47] <wilhelm> davidburns: This may be covered in the Widgets spec.
- # [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.
- # [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
- # [11:48] <wilhelm> eranm: We emulate shift-a for A. Should we spec this?
- # [11:48] * Joins: kkania (~kkania@public.cloak)
- # [11:48] <wilhelm> sms: We also do the alt keys on Window.
- # [11:48] <wilhelm> s/Window/Windows
- # [11:49] <wilhelm> JonathanJ: IME is very complicated.
- # [11:50] <wilhelm> ACTION: JonathanJ to give input on non-latin character input
- # [11:50] * RRSAgent records action 2
- # [11:50] <wilhelm> ACTION: davidburns to look into how the DOM spec handles keyboard events and internationalisation
- # [11:50] * RRSAgent records action 3
- # [11:51] <wilhelm> andreastt: The current IME section is... nothing.
- # [11:52] <wilhelm> sms: There is a series of commands for handling IME in code. Document these as non-normative.
- # [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.
- # [11:53] <wilhelm> eranm: We should listen to people who actually use this.
- # [11:53] <wilhelm> Topic: ARIA locators?
- # [11:54] <wilhelm> sms: An accessible web is a good web. Should we add ARIA as another type of selector?
- # [11:54] <wilhelm> sms: I don't know if the ARIA specs have any APIs that browsers should implement.
- # [11:54] <wilhelm> sms: Is there an equivalent to querySelector for ARIA? I don't think there is.
- # [11:55] <wilhelm> JohnJansen: I haven't seen one.
- # [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.
- # [11:55] <wilhelm> Topic: Shadow DOM
- # [11:55] <wilhelm> sms: This'll be fun.
- # [11:56] <wilhelm> sms: Is everyone familiar with what the shadow DOM is?
- # [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.
- # [11:57] <wilhelm> davidburns: How should we access these elements?
- # [11:57] <sms> http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html
- # [11:57] <wilhelm> davidburns: If we query the DOM, the browser won't give us the shadow DOM elements.
- # [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.
- # [11:59] <wilhelm> andreastt: Is there any way to expose that in the browser today?
- # [11:59] <wilhelm> sms: The render tree expands everything out, but not in the DOM.
- # [11:59] <wilhelm> sms: How do we want to present this to users?
- # [11:59] <wilhelm> sms: Chrome just switched this on.
- # [11:59] <wilhelm> davidburns: It's behind a command-line flag.
- # [11:59] <wilhelm> sms: No, it's on by default.
- # [12:00] <wilhelm> jhammel: Does each browser have a different shadow DOM for <video>?
- # [12:01] <wilhelm> sms: Facebook like button is a good candidate for shadow DOM.
- # [12:02] <wilhelm> sms: My suggestion: If you do a findByTagName within a findByTagName('video'), you query within a shadow host.
- # [12:03] <wilhelm> sms: We should follow the model of the JS world.
- # [12:03] <wilhelm> sms: Don't cast to a specific shadowElement.
- # [12:03] <wilhelm> sms: Does this sound reasonable?
- # [12:04] <wilhelm> davidburns: Yes.
- # [12:04] <wilhelm> davidburns: There will be a lot more shadow elements in the future. They simplify a lot.
- # [12:04] <wilhelm> sms: Once you're in the shadow DOM, it looks like a regular DOM.
- # [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?
- # [12:05] <wilhelm> andreastt: I suggest we don't.
- # [12:05] <wilhelm> sms: I'm leaning that way too.
- # [12:05] <wilhelm> andreastt: You could do it yourself in JS.
- # [12:06] <wilhelm> eranm: If you don't have to return something, don't.
- # [12:06] <wilhelm> sms: My preference is to not add anything to our spec that we don't need to.
- # [12:06] <wilhelm> ACTION: Write a section on handling the shadow DOM that mirrors the JS APIs
- # [12:06] * RRSAgent records action 4
- # [12:07] <wilhelm> jhammel: We should write conformance tests for this.
- # [12:07] <wilhelm> sms: We should do this for all parts of the spec.
- # [12:07] <wilhelm> Topic: Error codes - strings or numbers?
- # [12:08] <wilhelm> sms: At the moment we always return numbered codes. We happen to know what it means through constants.
- # [12:08] <wilhelm> sms: Great for us, since we are familiar with it. Difficult for others trying to debug the wire protocol.
- # [12:08] <wilhelm> sms: The numbers don't make any sense.
- # [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."
- # [12:10] <wilhelm> jhammel: Mild pro-string.
- # [12:10] <wilhelm> jhammel: They are human-readable, which is good.
- # [12:11] <wilhelm> andreastt: I'm for keeping the numbers. If we keep the numbers, we should rework whether all of these are neccessary.
- # [12:11] <wilhelm> andreastt: Categorize and put in groups.
- # [12:11] <wilhelm> andreastt: If we transfer strings, that's a lot more data.
- # [12:11] <wilhelm> andreastt: Then we'd need to set a limit here.
- # [12:11] * Quits: byungjung (~byungjung@public.irc.w3.org) (Ping timeout: 20 seconds)
- # [12:11] <wilhelm> sms: You don't want the collected works of Shakespeare as a status code.
- # [12:12] <wilhelm> sms: You could use numbers in the scope protocol and translate in the shim.
- # [12:12] <wilhelm> andreastt: That may be overkill.
- # [12:13] <wilhelm> sms: If we used strings, we would use the summary field, with spaces.
- # [12:13] <wilhelm> sms: The numbers come from the original IE implementation.
- # [12:14] <wilhelm> sms: So far, we've just used the next unused number for new error codes.
- # [12:15] <wilhelm> andreastt: Options: 1. Use strings. 2. Use ints that are grouped. 3. Keep things as they are.
- # [12:15] <wilhelm> sms: This change would have to be in Selenium 3. Major, breaking change.
- # [12:16] <wilhelm> sms: We could keep the old error codes for a while.
- # [12:16] <wilhelm> eranm: The numbers are used across languages. A string would mean less confusion than ints (which are opaque strings).
- # [12:16] <wilhelm> jhammel: If we stick with numbers, we should have sensible groupings.
- # [12:17] <wilhelm> sms: We need to figure out what the groupings are.
- # [12:17] <wilhelm> andreastt: What happens if a webdriver binding doesn't have the complete list of error codes?
- # [12:17] <wilhelm> sms: If the local end sees an error it doesn't know, just throw the base WebDriver exception.
- # [12:18] * Quits: plh (plehegar@public.cloak) ("always accept cookies")
- # [12:18] <wilhelm> andreastt: Are all the errors here fatal?
- # [12:18] <wilhelm> sms: Yes.
- # [12:18] * Quits: shepazu (schepers@public.cloak) ("is sleepy")
- # [12:18] <wilhelm> andreastt: How will we treat success?
- # [12:18] * Quits: Lachy (~Lachy@public.cloak) ("Computer has gone to sleep.")
- # [12:19] <wilhelm> sms: Empty string or 0.
- # [12:19] <wilhelm> andreastt: If we decide to go with strings, do we still want a normative list of error messages?
- # [12:19] <wilhelm> sms: We must have a normative list of error messages. (This should be extensible, with a prefix?.)
- # [12:20] <wilhelm> sms: As vendor X, how do I add new status codes?
- # [12:20] <wilhelm> sms: Opera has 1000, MS has 2000? Or private use areas like in Unicode?
- # [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.
- # [12:21] <wilhelm> sms: So far we've got away with it.
- # [12:21] <wilhelm> sms: We may have a problem.
- # [12:21] <wilhelm> sms: (This is a separate issue.)
- # [12:21] <wilhelm> andreastt: If we use strings, vendors can use an arbitrary strings.
- # [12:22] <wilhelm> andreastt: There may be collisions
- # [12:22] <wilhelm> sms: This is covered under vendor-specific extensions: -moz, -o. We guarantee to not have an error starting with -.
- # [12:23] * Joins: shepazu (schepers@public.cloak)
- # [12:23] <wilhelm> sms: We should probably do the same for error codes.
- # [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.
- # [12:25] <wilhelm> sms: Vendor-specific extension could be: "-o Bookmark not found", "-o-Bookmark not found".
- # [12:26] <wilhelm> sms: Humans use spaces. We should use spaces if we decide to go for strings.
- # [12:27] <wilhelm> sms: I don't want to use both strings and numbers: 404 Not found
- # [12:27] <wilhelm> davidburns: My preference is pruned numbers.
- # [12:29] <wilhelm> sms: Overlap between vendor error codes is a problem. The client doesn't know which browser it uses.
- # [12:29] <wilhelm> kkania: I like strings.
- # [12:29] <wilhelm> kkania: Only objection to strings is performance. I don't see that as a big deal.
- # [12:30] * Quits: darobin (rberjon@public.cloak) (Client closed connection)
- # [12:30] <wilhelm> jhammel: They are a bit English-specific.
- # [12:30] <wilhelm> sms: So is everything else.
- # [12:30] <wilhelm> andreastt: Opera leans towards strings.
- # [12:30] <wilhelm> JohnJansen: No opinion.
- # [12:31] <wilhelm> jhammel: Mozilla is on the fence.
- # [12:31] <wilhelm> sms: I suggest we move to strings.
- # [12:31] * Quits: ArtB (~abarsto@public.cloak) ("Leaving.")
- # [12:31] <wilhelm> sms: That means a new field on the response headers.
- # [12:31] <wilhelm> sms: In the spec, it will always be strings.
- # [12:33] <wilhelm> sms: If we had numbers, we need to give different numbers to different companies.
- # [12:33] <wilhelm> sms: The client side should be as generic as possible, and just works.
- # [12:34] * Quits: kkania (~kkania@public.cloak) (kkania)
- # [12:35] * Quits: shepazu (schepers@public.cloak) ("is sleepy")
- # [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.
- # [12:36] * RRSAgent records action 5
- # [12:36] <wilhelm> ACTION: Strings replace numbers in errors
- # [12:36] * RRSAgent records action 6
- # [12:36] <wilhelm> Topic: Lunch! Woho!
- # [12:38] * Quits: JonathanJ (~hollobit@public.cloak) (Ping timeout: 20 seconds)
- # [12:48] * Quits: eranm (~eranm@public.cloak) ("This computer has gone to sleep")
- # [12:57] * Quits: shadi (shadi@public.cloak) (Ping timeout: 60 seconds)
- # [13:02] * Disconnected
- # [13:03] * Attempting to rejoin channel #testing
- # [13:03] * Rejoined channel #testing
- # [13:06] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
- # [13:46] * Joins: shepazu (schepers@public.cloak)
- # [13:48] * Joins: Lachy (~Lachy@public.cloak)
- # [13:48] * Joins: a12u (~androirc@public.cloak)
- # [13:50] * Joins: abarsto (~abarsto@public.cloak)
- # [13:50] * abarsto is now known as ArtB
- # [13:53] * Joins: eranm (~eranm@public.cloak)
- # [14:04] * Joins: shadi (shadi@public.cloak)
- # [14:06] * Joins: glenn (~gadams@public.cloak)
- # [14:08] * Joins: kkania (~kkania@public.cloak)
- # [14:11] <wilhelm> Topic: Taking shit out
- # [14:12] <wilhelm> davidburns: We have our own definition of "window". We should align this with HTML5.
- # [14:12] <wilhelm> andreastt: Chrome operates with browsers as opposed to windows, no?
- # [14:12] <wilhelm> kkania: It's a separate browser class, not a separate process.
- # [14:13] <wilhelm> andreastt: In Opera you can have multiple windows with multiple tabs. (This applies to all browsers.)
- # [14:13] <wilhelm> andreastt: A window is a tab.
- # [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.
- # [14:14] * Joins: byungjung_ (~byungjung@public.irc.w3.org)
- # [14:14] <wilhelm> davidburns: jgraham suggested having a top-level browsing context.
- # [14:14] <wilhelm> sms: Is that a tab or an OS-level window?
- # [14:14] <wilhelm> sms: I think it's a tab. I'm cool with that.
- # [14:16] <wilhelm> sms: (Quouting HTML definition of top-level browsing context.)
- # [14:16] <wilhelm> sms: I'm happy with window to be top-level browsing context.
- # [14:17] <wilhelm> ACTION: Windows are to be the same as a top-level browsing context (as defined in HTML)
- # [14:17] * RRSAgent records action 7
- # [14:17] <sms> http://www.whatwg.org/specs/web-apps/2007-10-26/multipage/section-windows.html#parent
- # [14:18] <wilhelm> sms: (Quoting WebDriver spec on ordering of top-level browsing contexts across multiple OS-level windows.)
- # [14:19] * Joins: plh (plehegar@public.cloak)
- # [14:19] * Joins: shadi_ (shadi@public.cloak)
- # [14:19] <wilhelm> andreastt: Why is this a should?
- # [14:19] <wilhelm> sms: It's nice to have, but it's not required.
- # [14:19] * Quits: shadi_ (shadi@public.cloak) (Client closed connection)
- # [14:19] <wilhelm> (Speaking of the ordering of top-level browsing contexts.)
- # [14:21] <wilhelm> kkania: Why have this clause at all?
- # [14:21] <wilhelm> sms: Unskilled testers will observe the behaviour and expect it.
- # [14:21] <wilhelm> andreastt: This is difficult to implement.
- # [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.
- # [14:23] <wilhelm> andreastt: (Detailing complexities in keeping track of the correct order.)
- # [14:23] * Joins: darobin (rberjon@public.cloak)
- # [14:24] <wilhelm> kkania: For Chrome, this is easy to implement.
- # [14:24] <wilhelm> kkania: Shouldn't this be a must?
- # [14:25] <wilhelm> sms: Should the should be a must, or do we drop the clause?
- # [14:25] <wilhelm> davidburns: I go for the arbitrary option (may).
- # [14:25] <wilhelm> andreastt: I don't get the logic behind that this is how testers think.
- # [14:25] <wilhelm> andreastt: I believe they expect the order they opened them.
- # [14:26] <wilhelm> sms: You prefer to take this section out?
- # [14:26] <wilhelm> andreastt: Yes.
- # [14:26] <wilhelm> kkania: I don't have a strong opinion.
- # [14:26] <wilhelm> sms: So we take out this section.
- # [14:26] * Quits: shepazu (schepers@public.cloak)
- # [14:26] <wilhelm> sms: Window-ordering is non-deterministic.
- # [14:26] * Joins: shepazu (schepers@public.cloak)
- # [14:27] <wilhelm> ACTION: Remove the proposed ordering section in 6.3
- # [14:27] * RRSAgent records action 8
- # [14:28] <wilhelm> sms: A set in Java is unordered.
- # [14:29] <wilhelm> sms: I would like to take out XPath piece, but I don't think that is a good idea.
- # [14:29] <wilhelm> eranm: getText?
- # [14:30] <wilhelm> sms: Visibility and shown text has been flagged for being moved to CSS OM. We need to discuss this with them.
- # [14:30] <wilhelm> ACTION: sms to discuss with CSS WG to hand over visibility to CSS OM
- # [14:30] * RRSAgent records action 9
- # [14:31] <wilhelm> eranm: Handling of invalid SSL certificates.
- # [14:31] <wilhelm> sms: (Quotes spec chapter 5.2.1.)
- # [14:33] <wilhelm> sms: The default is to accept invalid certificates during testing.
- # [14:33] <wilhelm> davidburns: Should this be true by default?
- # [14:34] <wilhelm> sms: No, to address our largest audience.
- # [14:34] * Joins: JonathanJ (~hollobit@public.cloak)
- # [14:34] <wilhelm> davidburns: (Describing case of compromised mobile device.)
- # [14:36] <wilhelm> sms: This is a desired capability, not a required capability.
- # [14:38] <JonathanJ> rrsagent, draft minutes
- # [14:38] <RRSAgent> I have made the request to generate http://www.w3.org/2012/10/29-testing-minutes.html JonathanJ
- # [14:39] <wilhelm> sms: A sensible default is probably to allow access to insecure HTTPS to accomodate testers without control over their environment.
- # [14:39] <wilhelm> davidburns: The opposite would be a secure default.
- # [14:40] <wilhelm> sms: WebDriver itself is an insecure entity.
- # [14:40] <wilhelm> andreastt: I would expect the browser to behave normally.
- # [14:41] <wilhelm> sms: Testers doing manual testing against these shitty environments may have saved the override to accept the invalid certificate.
- # [14:41] <wilhelm> sms: They would forget about it and expect the test to just work.
- # [14:42] <wilhelm> sms: They'd blame WebDriver.
- # [14:43] <wilhelm> andreastt: The test author may expect that, but not a user.
- # [14:44] <wilhelm> andreastt: How does Chrome work here?
- # [14:44] <wilhelm> kkania: There is a command-line option for ignoring these messages.
- # [14:45] <wilhelm> andreastt: So for Chrome, this would involve setting said command-line option?
- # [14:45] <wilhelm> kkania: Yes.
- # [14:45] <wilhelm> eranm: Users would see the message and enable the flag, given the opposite default.
- # [14:46] <wilhelm> sms: We get bug reports on this.
- # [14:46] <eranm> wilhelm, my point was it doesn't make sense burdening every user with enabling this flag again and again
- # [14:47] <wilhelm> sms: The majority opinion is against mine. The default is secureSsl set to true.
- # [14:49] <wilhelm> andreastt: Our security peoplea are okay with this as long as we're running in an automated test mode.
- # [14:49] <wilhelm> davidburns: We're fine with it.
- # [14:49] <wilhelm> kkania: I'm fine with it.
- # [14:49] <wilhelm> sms: Default is allow insecure and local end can override that.
- # [14:49] * Quits: darobin (rberjon@public.cloak) (Client closed connection)
- # [14:50] <wilhelm> JohnJansen: How do you know if you're running in an automated test mode?
- # [14:50] <wilhelm> andreastt: A flag.
- # [14:50] <wilhelm> JohnJansen: A hacker can use that flag?
- # [14:50] <wilhelm> andreastt: Yes.
- # [14:50] <wilhelm> andreastt: You can enable the flag, but you can't trick the user to connect to a remote client.
- # [14:51] * Joins: a1zu (~androirc@public.cloak)
- # [14:52] * Quits: a12u (~androirc@public.cloak) (Client closed connection)
- # [14:52] * Joins: a12u (~androirc@public.cloak)
- # [14:54] * Quits: a1zu (~androirc@public.cloak) (Ping timeout: 20 seconds)
- # [15:01] <JonathanJ> rrsagent, draft minutes
- # [15:01] <RRSAgent> I have made the request to generate http://www.w3.org/2012/10/29-testing-minutes.html JonathanJ
- # [15:02] * Joins: darobin (rberjon@public.cloak)
- # [15:05] <jhammel> Scribe: jhammel
- # [15:05] <jhammel> sms: exceptions
- # [15:06] * Joins: trackbot (trackbot@public.cloak)
- # [15:06] <trackbot> Sorry... I don't know anything about this channel
- # [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)
- # [15:06] <jhammel> eranm: browser connection: if the browser is offline, it makes sense to include in the standard as this is user-controlled
- # [15:06] <jhammel> davidburns: e.g. manifests
- # [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)
- # [15:07] <jhammel> davidburns: haven't tried with marionette, but this may work better
- # [15:07] <jhammel> sms: if you start the browser in offline mode you couldn't open a socket
- # [15:08] <jhammel> jhammel: this might be fixed
- # [15:08] <jhammel> andreastt: is this something we want?
- # [15:08] <jhammel> andreastt: i support it
- # [15:08] <jhammel> davidburns: we support it
- # [15:08] <jhammel> davidburns: we need to find out where our boundary's finished and where another group begins
- # [15:09] <jhammel> davidburns: should be supported, since a user should be able to turn off the browser
- # [15:09] <plh> s/JohnJansen: How do you know if you're running in an automated test mode?//
- # [15:09] <plh> s/andreastt: A flag.//
- # [15:09] <jhammel> sms: how does the browser react? how do we continue controlling it?
- # [15:09] <plh> s/JohnJansen: A hacker can use that flag?//
- # [15:09] <plh> s/andreastt: Yes.
- # [15:09] <plh> s/andreastt: Yes.//
- # [15:09] <plh> s/andreastt: You can enable the flag, but you can't
- # [15:09] <plh> trick the user to connect to a remote client.//
- # [15:09] <jhammel> davidburns: if we can't access them, the offline mode should redirect to those pages
- # [15:09] <plh> s/andreastt: You can enable the flag, but you can't trick the user to connect to a remote client.//
- # [15:10] * plh rrsagent, generate minutes
- # [15:10] <RRSAgent> I have made the request to generate http://www.w3.org/2012/10/29-testing-minutes.html plh
- # [15:10] <jhammel> davidburns: the local side should be able to continue to talk to the browser
- # [15:10] <jhammel> sms: there's a difference between being offline and being able to reach into the browser
- # [15:10] <jhammel> eranm: application cache: the only API we have is to figure out the state of the applicaiton cache
- # [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
- # [15:11] <jhammel> davidburns: chrome has asked for it and Jonas Sicking has asked for it as well
- # [15:11] <jhammel> davidburns: same as cookies
- # [15:12] <jhammel> davidburns: where possible, should delegate to the web apps working group
- # [15:12] <jhammel> eranm: so applicaiton cache is out of scope here?
- # [15:12] <jhammel> davidburns: yes
- # [15:12] <jhammel> andreastt: we have exposed the application cache for opera driver
- # [15:12] <jhammel> eranm: next: local storage access
- # [15:13] <jhammel> davidburns: i'm in favor of not looking after that; again, can be done with JS
- # [15:13] <jhammel> davidburns: local APIs could do the heavy lifting, but it is beyond scope of webdriver
- # [15:13] <jhammel> davidburns: we'd just be executing script with proper context
- # [15:14] <jhammel> sms: do we allow them to setup data prior to running their tests? do we treat them like cookies?
- # [15:14] <jhammel> davidburns: i'd go the cookie root
- # [15:14] <jhammel> sms: example: if you're on google.com you can't setup local storage for bing.com
- # [15:14] <jhammel> sms: but what if you need to?
- # [15:14] <jhammel> andreastt: it depends on how the profile is setup
- # [15:15] <jhammel> eranm: we allow modifying local storage in the same way we allow modifying cookies?
- # [15:15] <jhammel> davidburns: yes
- # [15:16] <jhammel> eranm: next: geolocation: api for getting current location and setting it?
- # [15:16] <jhammel> eranm: getting it is useful; setting it?
- # [15:16] <jhammel> wilhelm: use-case: you want to test your app that checks for restaurants nearby
- # [15:16] <jhammel> sms: setting definitely belongs in the standard
- # [15:17] <jhammel> andreastt: i'm fine with exposing get as well
- # [15:17] <jhammel> davidburns: from an API point of view it makes sense to have both get and set
- # [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
- # [15:19] <jhammel> sms: it was brought up: "What if you never call set?"
- # [15:19] <jhammel> sms: it seems the actual physical location of the device is what you get back
- # [15:19] <jhammel> davidburns: that sounds sane
- # [15:20] <jhammel> eranm: if the location is set in a test, the browser should not respond with location confirmation
- # [15:20] <jhammel> wilhelm: i load the browser and load the page that wants to find restaurants nearby
- # [15:21] <jhammel> wilhelm: it asks for confirmation and i deny it
- # [15:21] <jhammel> wilhelm: presumedly your browser has some behaviour if this happens
- # [15:21] <jhammel> sms: should this be a capability
- # [15:21] <jhammel> andreastt: this should not be a capability
- # [15:21] <jhammel> sms: how do you deal with a popup: "Maps wants to share your location..."?
- # [15:22] <jhammel> sms: as a user you do know this is coming; should this be treated as an alert?
- # [15:22] <jhammel> andreastt: we should treat this as SSL
- # [15:22] <jhammel> sms: so that's a capability
- # [15:22] <jhammel> sms: you'd have to restart the browser to test; that seems fair
- # [15:23] <jhammel> sms: if we've set it to false, we say "No you absolutely can't have my location"
- # [15:23] <jhammel> wilhelm: it makes sense to mirror SSL
- # [15:23] <jhammel> wilhelm: permissive by default
- # [15:23] <jhammel> andreastt: we should still keep the API for getting the settings
- # [15:24] <jhammel> andreastt: what wil be the result of the actions if you're on a browser without geolocation?
- # [15:24] <jhammel> sms: we won't expose that capability
- # [15:24] <jhammel> sms: there will be a capability that says: i won't support this ability
- # [15:24] <jhammel> sms: e.g. null for location
- # [15:25] <jhammel> andreastt: we're setting a precedent for how to handle these capabilities [wrt enableSSL parity]
- # [15:25] <jhammel> sms: if we're happy with that we should go for it gung ho;
- # [15:26] <jhammel> new topic: davidburns: Mozilla has a big standing against DB storage
- # [15:26] <jhammel> sms: database storage has been deprecated
- # [15:27] <jhammel> Philippe : the reason it disappeared is because since Microsoft and Mozilla didn't implement it, they basically killed it
- # [15:28] <jhammel> sms: one of the nice things is that we can send pure javascript and have it executed
- # [15:28] <jhammel> Philippe: that got replaced by indexdb
- # [15:28] <jhammel> Philippe: IE10, Mozilla, Chrome are doing it
- # [15:29] <jhammel> JohnJansen: it is more performant than other data storage solutions
- # [15:29] <jhammel> andreastt: supported in chrome, firefox, and IE
- # [15:29] <jhammel> andreastt: none of the mobile phones except ???
- # [15:30] <jhammel> Philippe: switching to indexdb but not widely deployed yet
- # [15:30] <jhammel> sms: i'm for holding off until someone asks for it
- # [15:30] <jhammel> sms: does anything else have anything to discuss today?
- # [15:31] <jhammel> sms: do we want webdriver OSS project to become the tomcat of the webdriver spec?
- # [15:31] <jhammel> davidburns: your suggesting the tests be in the selenium project?
- # [15:32] <jhammel> sms: they will be in the w3c, but selenium can have more tests
- # [15:33] <jhammel> sms: we could continue the status quo
- # [15:34] <jhammel> sms: agenda for tomorrow: writing tests
- # [15:34] <jhammel> andreastt: ... HTML contacts
- # [15:35] <jhammel> andreastt: canvas, svg, xhtml, xml...
- # [15:35] * Quits: byungjung_ (~byungjung@public.irc.w3.org) (Ping timeout: 20 seconds)
- # [15:35] <jhammel> sms: if its covered by the w3c spec it is fair game
- # [15:36] <jhammel> sms: what about plain text?
- # [15:36] <jhammel> sms: maybe text as well
- # [15:37] <jhammel> sms: another thing that we don't handle is pdf
- # [15:38] <jhammel> Philippe: [putting text in a <pre>] is part of the HTML5 spec
- # [15:39] * Parts: kkania (~kkania@public.cloak) (kkania)
- # [15:39] <plh> [adjourned]
- # [15:39] * plh rrsagent, generate minutes
- # [15:39] <RRSAgent> I have made the request to generate http://www.w3.org/2012/10/29-testing-minutes.html plh
- # [15:39] <plh> rrsagent, bye
- # [15:39] <RRSAgent> I see 9 open action items saved in http://www.w3.org/2012/10/29-testing-actions.rdf :
- # [15:39] <RRSAgent> ACTION: Make the section on the JSON wire protocol normative [1]
- # [15:39] * Quits: eranm (~eranm@public.cloak) ("This computer has gone to sleep")
- # [15:39] <RRSAgent> recorded in http://www.w3.org/2012/10/29-testing-irc#T10-19-30
- # [15:39] <RRSAgent> ACTION: JonathanJ to give input on non-latin character input [2]
- # [15:39] <plh> zakim, bye
- # [15:39] <RRSAgent> recorded in http://www.w3.org/2012/10/29-testing-irc#T10-46-40
- # [15:39] <RRSAgent> ACTION: davidburns to look into how the DOM spec handles keyboard events and internationalisation [3]
- # [15:39] <RRSAgent> recorded in http://www.w3.org/2012/10/29-testing-irc#T10-47-39
- # [15:39] <RRSAgent> ACTION: Write a section on handling the shadow DOM that mirrors the JS APIs [4]
- # [15:39] <RRSAgent> recorded in http://www.w3.org/2012/10/29-testing-irc#T11-03-22
- # [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]
- # [15:39] <RRSAgent> recorded in http://www.w3.org/2012/10/29-testing-irc#T11-32-40
- # [15:39] <RRSAgent> ACTION: Strings replace numbers in errors [6]
- # [15:39] <RRSAgent> recorded in http://www.w3.org/2012/10/29-testing-irc#T11-33-08
- # [15:39] <RRSAgent> ACTION: Windows are to be the same as a top-level browsing context (as defined in HTML) [7]
- # [15:39] <RRSAgent> recorded in http://www.w3.org/2012/10/29-testing-irc#T13-13-48
- # [15:39] <RRSAgent> ACTION: Remove the proposed ordering section in 6.3 [8]
- # [15:39] <RRSAgent> recorded in http://www.w3.org/2012/10/29-testing-irc#T13-24-28
- # [15:39] <RRSAgent> ACTION: sms to discuss with CSS WG to hand over visibility to CSS OM [9]
- # [15:40] <RRSAgent> recorded in http://www.w3.org/2012/10/29-testing-irc#T13-27-35
- # [15:40] * Parts: RRSAgent (rrsagent@public.irc.w3.org) (RRSAgent)
- # [15:40] * Quits: sms (~simonstewart@public.cloak) (sms)
- # [15:42] * Quits: JonathanJ (~hollobit@public.cloak) (Ping timeout: 20 seconds)
- # [15:42] * Quits: plh (plehegar@public.cloak) ("always accept cookies")
- # [15:46] * Quits: jhammel (~jhammel@public.cloak) (Ping timeout: 20 seconds)
- # [15:47] * Joins: jhammel (~jhammel@public.cloak)
- # [15:47] * Quits: a12u (~androirc@public.cloak) (Ping timeout: 20 seconds)
- # [15:53] * Quits: darobin (rberjon@public.cloak) (Client closed connection)
- # [15:55] * Joins: a12u (~androirc@public.cloak)
- # [15:56] * Quits: jhammel (~jhammel@public.cloak) (Ping timeout: 20 seconds)
- # [15:56] * Quits: JohnJansen (~JohnJansen@public.cloak) (Ping timeout: 20 seconds)
- # [16:02] * Quits: davidburns (~davidburns@public.cloak) (Client closed connection)
- # [16:03] * Joins: eranm (~eranm@public.cloak)
- # [16:04] * Joins: darobin (rberjon@public.cloak)
- # [16:04] * Quits: trackbot (trackbot@public.cloak) (Client closed connection)
- # [16:05] * Joins: eranm_ (~eranm@public.cloak)
- # [16:07] * Joins: a1zu (~androirc@public.cloak)
- # [16:07] * Quits: a12u (~androirc@public.cloak) (Client closed connection)
- # [16:07] * Quits: eranm (~eranm@public.cloak) (Ping timeout: 60 seconds)
- # [16:17] * Joins: JohnJansen (~JohnJansen@public.cloak)
- # [16:20] * Joins: JonathanJ (~hollobit@public.cloak)
- # [16:23] * Joins: jhammel (~jhammel@public.cloak)
- # [16:38] * Joins: tpacbot (~nodebot@public.cloak)
- # [16:47] * Joins: plh (plehegar@public.cloak)
- # [17:05] * Quits: JonathanJ (~hollobit@public.cloak) (Ping timeout: 60 seconds)
- # [17:06] * Quits: darobin (rberjon@public.cloak) (Client closed connection)
- # [17:11] * Quits: shepazu (schepers@public.cloak) ("is sleepy")
- # [17:18] * Quits: a1zu (~androirc@public.cloak) (Ping timeout: 60 seconds)
- # [17:19] * Quits: MikeSmith (~MikeSmith@public.cloak) (MikeSmith)
- # [17:36] * Quits: Lachy (~Lachy@public.cloak) ("Computer has gone to sleep.")
- # [17:38] * Quits: eranm_ (~eranm@public.cloak) ("This computer has gone to sleep")
- # [17:48] * Quits: ArtB (~abarsto@public.cloak) ("Leaving.")
- # [17:49] * Joins: Lachy (~Lachy@public.cloak)
- # [17:53] * Quits: Lachy (~Lachy@public.cloak) ("Computer has gone to sleep.")
- # [17:55] * Joins: darobin (rberjon@public.cloak)
- # [17:59] * Quits: shadi (shadi@public.cloak)
- # [18:00] * Quits: tpacbot (~nodebot@public.cloak) (Client closed connection)
- # [18:02] * Joins: Lachy (~Lachy@public.cloak)
- # [18:05] * Parts: jari (~jari@public.cloak) (jari)
- # [18:06] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
- # [18:07] * Joins: eranm (~eranm@public.cloak)
- # [18:08] * Quits: eranm (~eranm@public.cloak) ("Leaving")
- # [18:10] * Quits: plh (plehegar@public.cloak) (Ping timeout: 60 seconds)
- # [18:11] * Joins: a12u (~androirc@public.cloak)
- # [18:21] * Quits: jhammel (~jhammel@public.cloak) ("leaving")
- # [18:24] * Joins: a1zu (~androirc@public.cloak)
- # [18:24] * Quits: a12u (~androirc@public.cloak) (Client closed connection)
- # [18:26] * Quits: JohnJansen (~JohnJansen@public.cloak) (Ping timeout: 60 seconds)
- # [18:26] * Quits: a1zu (~androirc@public.cloak) ("AndroIRC - Android IRC Client ( http://www.androirc.com )")
- # [18:27] * Quits: Lachy (~Lachy@public.cloak) ("Computer has gone to sleep.")
- # [18:32] * Quits: darobin (rberjon@public.cloak) (Client closed connection)
- # [18:35] * Joins: glenn (~gadams@public.cloak)
- # [19:08] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
- # [21:48] * Joins: glenn (~gadams@public.cloak)
- # [23:04] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
- # [23:31] * Joins: glenn (~gadams@public.cloak)
- # [23:47] * Joins: tpacbot (~nodebot@public.cloak)
- # Session Close: Tue Oct 30 00:00:00 2012
The end :)