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