08:38:43 RRSAgent has joined #testing 08:38:43 logging to http://www.w3.org/2012/04/19-testing-irc 08:39:05 RRSAgent, stop 08:39:41 Meeting: Informal meeting on the WebDriver spec, London, April 19th 08:39:47 Chair: wilhelm 08:40:29 RRSAgent, draft minutes 08:40:29 I have made the request to generate http://www.w3.org/2012/04/19-testing-minutes.html wilhelm 08:40:44 RRSAgent, make log public 08:41:07 RRSAgent, draft minutes 08:41:07 I have made the request to generate http://www.w3.org/2012/04/19-testing-minutes.html wilhelm 08:45:31 guest has joined #testing 09:00:46 guest has joined #testing 09:03:36 RRSAgent, stop 09:23:56 Scribe: simonstewart 09:23:56 I like cheese 09:24:17 topic: introductions 09:24:34 Topic: introductions 09:24:48 RRSAgent, draft minutes 09:24:48 I have made the request to generate http://www.w3.org/2012/04/19-testing-minutes.html wilhelm 09:25:44 wilhelm: starts the meeting 09:27:11 guest: We're getting you set up now. Starting with introductions. 09:27:42 simonstewart has joined #testing 09:29:05 wilhelm: works as a independent consultant, chair of the browser tools and testing group 09:29:23 eranm: works at google on simonstewart's team. Works on user interactions 09:29:35 jarib: works on webdriver. works at finn.no. Does the ruby bindings 09:29:41 danielwh: works at google on webdriver 09:29:48 I do the same thing 09:30:06 jimevans: works at salesforce.com. Works on Webdriver (the IE and .net bindings) 09:30:13 freynaud: works at ebay on automation and Grid 09:30:29 jleyba: googled. Focuses on JS testing and does the JS bindings 09:30:37 andreastt: works at opera. 09:30:45 represents their browser automation team 09:30:56 raga: works at experia as a test lead 09:31:09 samit: works for TomTom as a tech lead, and the maintainer of the selenium IDE 09:31:20 wilhelm: why are we here, how the process works 09:31:43 wilhelm: there are several reasons for writing the webdriver spec. 09:32:08 wilhelm: wore the test manager hat at opera for several years 09:32:32 wilhelm: Goal is still the same. The W3 should be able to write tests for the new specs 09:32:45 wilhelm: The easy stuff has already been done (e.g.: rendering (!)) 09:32:55 wilhelm: Things that use JS assertions are already done too 09:33:07 wilhelm: difficult part: testing things that require some sort of user interaction 09:33:37 wilhelm: opera originally considered watir and webdriver. Didn't care about automating websites, just the browser 09:33:59 wilhelm: in the testing IG at the w3c we're trying to reach a consensus about which tools should be used. 09:34:15 wilhelm: Goal is to get all w3c standards to be able to use the webdriver api to write tests 09:34:20 wilhelm: therefore we need a spec 09:34:56 wilhelm: in addition, there's the benefits for the OSS project to have a proper and clear spec. 09:35:31 wilhelm: Also, I believe we can use the spec as a tool to bring other people on board with the browser automation effort 09:36:06 wilhelm: finally, the w3c has a patent policy that members of a working group must follow. 09:36:25 wilhelm: reduces legal risk for people implementing the standard 09:36:35 wilhelm: it's also my birthday. 09:37:02 wilhelm: we'll talk until lunch and then clear up and disputes in the spec afterwards 09:37:29 raga: will this replace any other specs? 09:37:44 wilhelm: will just focus on browser automation, allowing others to test the things that webdriver does 09:38:11 wilhelm: notice that this is an informal meeting, so anyone can join in. Would be happy to help new members come and join the group 09:38:34 wilhelm: I hereby invite all of you as invited experts to the WG. 09:39:17 http://dvcs.w3.org/hg/webdriver/raw-file/tip/webdriver-spec.html 09:39:20 Scribe: wilhelm 09:39:22 rambighananthan has joined #testing 09:39:24 Topic: Spec overview 09:39:45 simonstewart: I've never done this before – if you have questions, just ask. 09:39:57 simonstewart: Skipping the abstract… 09:40:08 simonstewart: Leaping straight into the introduction. 09:40:56 … Missing expected use cases in the introduction. 09:41:14 … Three use cases should be added: people who want to test web sites, … 09:41:40 … people who are working on a browser itself and want to verify that the browser works correctly, people who write specifications that define how a browser should behave. 09:42:18 … We would be dead in the water if we were to define everything independenlty. We cross-reference other specs where applicable. 09:42:38 … If you find an error in the spec where we should be referring to another spec, please let us know. 09:43:10 … Naming the two sides of the API. Traditionally you define client and server. These are overloaded terms. 09:43:22 … One end is the test or the user, one end is the browser that is being automated. 09:44:33 … Deliberately not mentioning how things are routed. How commands are formatted are up to implementors. 09:45:08 … There will be a non-normative section on the JSON wire protocol, which the most common implementation. 09:45:22 … We intend to provide as much as possible in Web IDL format. 09:46:34 … The webdriver spec will lay out commands that can be used, as well as a way these can be extended by vendors, avoiding clashes. 09:47:51 … (Detailing steps of commands and responses – see spec for exact details.) 09:48:35 … We'd like people to be able to do send additonal information with commands and responses. (Screenshots on error, authentication, &c.) 09:49:15 … Open question: should we require implementors to preserve the order of the fields? 09:49:23 others: Not important. 09:50:21 simonstewart: The numeric error codes have gaps due to legacy. 09:51:40 simonstewart: … There's definitely a hierarchy of error codes, similar to in HTTP. 09:51:49 … Yes, perhaps we should group them together. 09:52:12 jleyba: We have implicit error codes as well due to the underlying HTTP. 09:53:01 jimevans: We're not specifiying that the transport will be HTTP. 09:53:48 jleyba: We should validate commands. If you don't give the expected parameters, server may blow up. 09:53:53 simonstewart: Missing part here. 09:54:38 simonstewart: Status codes should encapsulate all possible errors. 09:54:45 jimevans: Currently we don't. 09:55:16 jleyba: We should have classes of error codes where vendors may extend (say 600 range). 09:56:07 simonstewart: Users generally don't do the right thing with error codes. 09:56:31 kevin: Are integers defined to be unsigned in WebIDL? 09:56:35 simonstewart: These are unsigned. 09:58:12 rambighananthan: When our scripts look for elements, they may not be in the right place. Is there a way to assert whether an element is within a given area? 09:58:28 simonstewart: This is already possible on the client using the available information about position and size. 09:58:49 … Goal is to keep the spec small. We want to define the building blocks people can build more complex things with. 09:58:59 ACTION: Go through the status codes 09:59:44 simonstewart: Spec uses capabilities in two different ways. Desired capabilities. Capabilities object for responses – this is what I support. 10:00:09 … The interface has a map of a dictionary of capabilities. 10:00:16 … Occasional objects. 10:00:33 … Two methods: boolean has method, get method. 10:01:42 kevin: In section 3.1.1 doesn't allow arbitrary objects to be returned. 10:01:53 simonstewart: How do you encode objects to send across the wire? 10:02:00 … Maybe we should tighten up the spec here. 10:02:51 andreastt: The capabilities we have now is an unholy mess. 10:03:02 kevin: How is null represented in Web IDL? 10:03:14 simonstewart: I don't know Web IDL very well. Feel free to correct things. 10:03:39 samit: Are we planning to standardize capability names? 10:03:44 simonstewart: We will standardize a set. 10:04:29 … We need a non-normative appendix of capability names with a link back to the section that defines it. 10:05:54 simonstewart: Some vendors may use other protocol formats. 10:07:00 simonstewart: Section 3.1.1 – must be of type boolan, string, numerical, dictionary. 10:07:23 … Dictionary can contain keys of type string and types above. 10:08:08 … Serialization format must be clearly defined. Simplest is dictionaries. 10:09:04 … This section is merely defining data types. 10:09:25 kevin: It should be called out that the absence of a value is NULL. 10:11:20 jleyba: get returns the raw value of a capability and makes an interpretation of that value. 10:13:17 simonstewart: Many questions here are due to me not understanding how to write Web IDL. Text may be easier to read. 10:13:30 (union types: http://dev.w3.org/2006/webapi/WebIDL/#idl-union) 10:13:59 samit: Can you give an example of when mutable capabilities are needed? 10:14:13 simonstewart: “I want Firefox 3.6 with this particular profile”. 10:14:37 … You might not know this when you start. 10:14:57 dawagner: Is this an implementation detail? 10:15:08 simonstewart: I'm happy to drop this. 10:15:14 jleyba: I vote for dropping it. 10:15:17 simonstewart: I'm fine with that. 10:16:17 Scribe: jari 10:16:29 jleyba has joined #testing 10:16:37 simonstewart: topic: sessions 10:16:40 dawagner has joined #testing 10:16:45 SamitBadle has joined #testing 10:16:47 topic: sessions 10:17:13 simonstewart: each session given uuid, opaque string 10:17:47 discussion removing the requirement of a uuid 10:20:09 simonstewart: (describing sessions - see spec) 10:20:59 jleyba: do we want to define a format for the command name? 10:21:13 simonstewart: want a format that allows for vendor extension 10:21:52 jleyba: current names based on firefox implementation, should we standardize on that? 10:22:26 simonstewart: nice to have human readable command names 10:22:56 simonstewart: do we want command names to be case sensitive? 10:23:10 eranm: no benefit 10:23:49 kmenard has joined #testing 10:24:30 Action: section 3 - specify command names as case sensitive 10:25:07 simonstewart: (continues reading from the section 4.1) 10:26:12 SamitBadle: change sessionId from SHOULD to MUST? 10:26:42 not, just asking. 10:27:09 simonstewart: why is explained later in same section 10:27:21 clear? 10:30:22 jleyba: asking if the remote end needs to respect sessionId created by the local end 10:32:29 jleyba: some capabilities should be set in stone 10:33:19 simonstewart: client should check what it gets back 10:34:33 discussion around fuzzy capability matching 10:38:13 Action: Add a "required capabilities" parameter when creating the session (Section 4.1) 10:41:33 pmfji for 'required capabilities' you might define an 'isRequired(capability)' method. 10:41:50 discussing problems around required parameters when the capabilities object is an unordered set - the first capability checked would fail 10:43:19 jleyba: spec should say the remote end should collect as many capabilities as it can before it fail 10:43:25 MikeSmith_ has joined #testing 10:43:34 simonstewart: i'm ok with that 10:46:01 discussing required capabilities in the context of grid implementation (i.e. intermediate nodes) 10:47:15 simonstewart: (continues reading from section 4.1) 10:48:07 eranm: what was conclusion on UUID? 10:48:25 simonstewart: remote end free to ignore UUIDs provided by the client 10:49:44 jleyba: don't see why local end should ever be able to set the UUID 10:50:47 simonstewart: known use cases exist, do we want to close the door on those? 10:51:30 abarsto has joined #testing 10:55:11 Action: server should make sure the UUID provided by the client is unique, not used before (Section 4.1) 10:58:56 Action: fix "0" string in 4.1. point 6 11:00:05 andreastt: how to specify different products in the capabilities? 11:00:10 simonstewart: use browserName 11:01:17 jleyba: are we standardizing browserNames? 11:01:33 simonstewart: no. ultimately each implementation will pick a browserName 11:03:14 SamitBadle has joined #testing 11:04:49 simonstewart: (reading section 4.1.1.1) 11:04:55 pmfji: perhaps use a dotted notation for capability names, e.g. "platform.version" instead of platformVersion etc. 11:05:36 simonstewart: just taking what's already there 11:06:38 SamitBadle: could we leave out "ANY" and just not send a platform capability? 11:07:17 kmenard: spec says "may be used" 11:07:55 simonstewart: may also be used to indicate that current OS is unknown from the remote end 11:09:42 hugs: what capability would differentiate e.g. iPhone from iPad? 11:10:03 simonstewart: spec says implementors may add additional platform names 11:11:08 (reading through section 4.1.2) 11:12:36 simonstewart: missing from this error handling section, required capabilitiy not fulfilled 11:15:00 simonstewart: (reading section 4.1.3) 11:17:02 discussing the non-normativity of this section 11:18:38 Topic: Navigation (Section 5) 11:19:34 simonstewart: (reading from Section 5) 11:20:47 Action: Navigating between HTTP vs HTTPS domains 11:21:56 andreastt: are we restricting ourselves to dealing with HTML? 11:22:15 simonstewart: opens up a can of worms dealing with other things 11:22:21 wilhelm: needs to deal with XML content 11:22:36 simonstewart: page load strategies deals with HTML/HTTP 11:22:46 simonstewart: can have non-normative section on XML 11:22:47 wilhelm: ok 11:23:51 jleyba: is the intent that these strategies apply only when explicitly say they apply, or do they apply to every command? 11:24:52 simonstewart: see section 5.2 11:26:55 jari: http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#current-document-readiness 11:27:00 Action: link to HTML spec for document.readyState 11:28:42 Action: Say explicitly that vendors can add additional page load strategies 11:30:24 Action: Link Section 5 to Section 13 11:32:02 simonstewart: (reading section 5.1) 11:33:35 simonstewart: (reading section 5.1.1) 11:34:36 Action: Clarify in section 5.1.1 that this applies to all kinds of invalid certificates, not only self-signed ones. 11:35:51 Action: Section 5.1.1 shouldn't use WebDriverException 11:37:14 simonstewart: page load strategy specifies when the next command will execute 11:37:27 Action: Swap order of 5.1 and 5.2 11:38:57 breaking for lunch 11:45:14 timeless has joined #testing 11:45:37 Rrsagent, pointer 11:45:37 See http://www.w3.org/2012/04/19-testing-irc#T11-45-37 11:49:37 guest2 has joined #testing 11:54:33 jleyba has joined #testing 12:16:14 chwells has joined #testing 12:38:59 jimevans has joined #testing 12:39:17 freynaud has joined #testing 12:40:24 SamitBadle has joined #testing 12:44:08 scribe: eranm 12:44:51 wilhelm: morning session was useful, suggest continue in the same format - going over the chapters 12:45:31 Topic: Controlling windows (section 6) 12:45:46 simonstewart: browser tabs are counted as separate windows 12:46:04 darobin has joined #testing 12:46:33 jleyba: window.top is a frame, happens to be the top-most frame. Say that when switching to a window you switch to a top-most frame. 12:47:02 wilhelm: the html specification uses the term "browsing context" 12:47:32 simonstewart: todo: define frame. 12:48:03 simonstewart: 6.2 window handles. 12:48:04 http://www.whatwg.org/specs/web-apps/current-work/#windows 12:48:17 simonstewart: suggesting a window class to refer to 12:49:48 hugs has joined #testing 12:50:26 jimevans: window IDs returned from the IE driver are no longer the HWND, this is an opaque string 12:50:58 action: we should make clear that the window handle is unique within the session 12:51:42 andreastt: assuming we're talking about visible windows 12:52:28 jleyba: chrome also has hidden windows, we may have to be more restrictive 12:52:54 action: andreastt and jleyba, re-word the language in 6.3 on the windows returned from there 12:54:55 jimevans: suggests specifying that the order of handles returned from getWindowHandles does not imply anything about the order of opened windows 12:55:45 simonstewart: the returned value will be changed to a set of strings to emphasize the order is not defined 12:56:53 freynaud: calling window.close is difficult for the grid, because it does not know the driver is done when the last window is closed 12:57:56 action: in section 6.4, take out the equivalence to quit. 12:58:18 use case brought up by SamitBadle is the last window of a mobile browser 12:58:35 (use case brought up by andreastt ) 12:59:28 action: maximise should be in 6.5 as well 13:00:37 andreastt: what happens when the command is called for a browser that cannot be resized? 13:00:53 action: define an exception if the browser cannot be resized to the specified size 13:01:03 (case: chrome cannot be resized to less than 200 pixels) 13:01:55 action: maximise and full screen are needed as commands. 13:02:39 jimevans: maximising and resizing to the screen size are not the same 13:05:37 simonstewart: leave positioning out for now, not enough use cases to justify it 13:07:22 RRSAgent, draft minutes 13:07:22 I have made the request to generate http://www.w3.org/2012/04/19-testing-minutes.html wilhelm 13:08:28 simonstewart: explaining os-specific scaling (window zoom). 13:08:40 jleyba: is that like pinch gesture on mobile? others: no 13:09:36 action: jleyba and andreastt will write section 6.6 about window zoom 13:10:45 jleyba: what happens if the window is no longer there? simonstewart : an exception is thrown if the window does not exist anymore 13:11:46 eranm: when a new window opens, we should specify commands are still processed in the original window. simonstewart : handled in section 7. 13:11:56 topic: 7 Where commands are handled 13:13:23 action: fix typo in 7.1, window._top -> window.top 13:14:49 jleyba: section 7.2, if the id attribute is not standard on window, we should not check for it 13:15:31 wilhelm: editorial comment: use normative words in section 7.2, (must/should) 13:15:56 action: use normative words in section 7.2, (must/should) 13:17:06 action: jleyba : document which commands are safe to execute without a window. 13:18:33 simonstewart: closing the last window is not possible only on some platforms (mobile), definitely possible on others (OS X) 13:20:41 eranm: does the section about multiple windows in 7.2 only about the multiple windows being opened on start-up? 13:21:20 simonstewart: could also happen when attaching to an existing browser 13:22:14 simonstewart: when you create a new session, if that new session creates only one window, this is the current window. 13:22:24 simonstewart: in case more than one window is being opened, then you have to make a choice 13:23:38 action: change throws clauses to error clauses (errors are returned, could be translated to exceptions in the client side) 13:24:01 action: add null as an option in 7.3 (frame specification can be null, in which case it's the top-most one) 13:24:56 action: be explicit in 7.3 that domain boundaries can be crossed 13:25:50 action: section 7.3, step 2.1 should be changed to null (see action 24) 13:27:17 simonstewart: section 7.3, step 3: so frame/iframe elements could be found and used in a switchToFrame command 13:28:31 topic: 8, running without focus. 13:29:53 jleyba: do we want the ability to switch up? simonstewart: users can find the way down again 13:30:39 SamitBadle: what happens when switching to a frame then switching to another window and switching back? simonstewart: specification says switching to a window switches to the top-most frame in it. 13:31:55 plh has joined #testing 13:37:05 #2863 13:40:06 topic: 9 elements 13:41:36 jleyba: suggest specifying that all IDs, unless specified otherwise, are UUIDs. 13:41:58 action: specify that all IDs, unless specified otherwise, are UUIDs. 13:43:58 klm: introducing himself: Michael Klepnikov, working at Google on latency testing, interested in WebDriver. Specifically interested in browsers exporting existing information about timing of actions. 13:44:57 http://dvcs.w3.org/hg/webdriver/raw-file/tip/webdriver-spec.html#logging 13:45:00 switching to section D, logging: 13:45:05 topic: D, logging (klm's interest) 13:47:10 simonstewart: the basic idea is that there's a logs interface which is queried for a specific kind of logs: browser logs, etc. 13:47:43 simonstewart: this is a uniform interface for getting logs for any stage, from the test itself , through the grid, to the browser launching itself 13:47:57 wilhelm: which problem are we trying to solve? 13:48:53 simonstewart: the test has failed, user would like to see the reason of the failure: out-of-memory in an intermediate step, commands executed before finding an event timed out. 13:49:19 hugs: another example is getting the javascript console before looking at the failure of the tests 13:50:43 davidburns has joined #testing 13:50:57 davidburns: do you want to be dialed into this meeting? 13:51:14 yea for a bit if that is ok? 13:51:48 simonstewart: ^ 13:52:16 eranm or dawagner: do you know the incantation to get davidburns in? 13:52:27 freynaud_ has joined #testing 13:52:30 dawagner, can you invite? 13:52:32 last time we did a Google hangout 13:52:47 Yep, davidburns: Email address? 13:52:55 simonstewart: define a mechanism for moving logs 13:53:01 david.burns@theautomatedtester.co.uk 13:53:16 davidburns, is that your google+ account? 13:53:23 eranm: yup 13:53:53 You should have email 13:53:55 simonstewart: when calling getlogs(), do I get the partial logs since the last invocation or all logs ? 13:54:33 wilhelm: mentions another spec about logging. 13:54:53 http://www.w3.org/2011/08/browser-testing-charter.html 13:54:55 SamitBadle: which performance data are we interested in? 13:55:48 klm: will instruct the browser to start collecting the performance data. Once that's collected, it should be in a separate channel, not polluted with other logging data 13:56:27 simonstewart: fyi https://twitter.com/#!/AutomatedTester/status/192764437348880384 13:56:34 freynaud: provide incremental logs, so you know which period of logs you're getting 13:56:54 klm: don't see a difference between console logs and timing logs 13:58:30 simonstewart: suggest passing a filter when fetching the messages 13:59:07 simonstewart: start recording X log type, stop recording X log type, get all categories of log types, clear logs. 14:00:46 klm: if there are two parts of the test framework that don't know about each other, incremental vs. full could be a problem 14:02:04 simonstewart: clear is called for a specific type, subsequent get will return logs from the last clear or start record commands 14:04:11 andreastt: some logs are document-specific, some logs are server-global, do we mix them? 14:04:25 simonstewart: call clear and get logs for logs you care about. 14:05:14 simonstewart, andreastt : when a session is deleted, the logs should be deleted as well. 14:07:31 simonstewart, the spec should define how to clear and collect the logs, each log type will have specific details which will not be specified here. 14:08:40 action: simonstewart : write section D on logs 14:08:49 topic: 9, Elements (back) 14:10:11 simonstewart: the spec does not define the protocols or the transport layer, how commands are transmitted. 14:10:31 simonstewart: different types of encodings are suitable for different kinds of devices. 14:14:49 action: eranm: section 9.1, the WebElementList SHOULD be immutable. 14:15:39 action: simonstewart switch WebElementList to array of WebElement (native WebIDL) 14:16:00 jari: there's even a readonly type. 14:16:08 http://www.w3.org/TR/WebIDL/#idl-array 14:18:49 hugs, can we move XPath to be last? simonstewart : other locator strategies may be implemented using that. Agrees to moving it down. 14:19:11 action: 9.2.2. change to javascript. 14:19:36 action: jleyba section 9.2.3 shorten capability name 14:20:53 action: jleyba , section 9.2.4 re-phrase to use CSS selectors other than xpath. 14:21:26 dawagner: we currently disallow compound CSS selectors, not disallowed by the spec. 14:22:35 wilhelm: clarifies that specifying a css selector "h1,h2" will return elements of either type. 14:23:08 action: simonstewart : allow compound css selectors. Get rid of class selectors. 14:24:47 action: section 9.2.5, spell out availability of functionality against html and xhtml 14:25:28 action: section 9.2.5 drop step 3 14:26:13 simonstewart: 9.2.7 aria - using the accessibility API. 14:27:39 http://www.w3.org/TR/wai-aria/ 14:27:43 action: write section 9.2.7 , if you're familiar with the spec. 14:31:13 RRSAgent, draft minutes 14:31:13 I have made the request to generate http://www.w3.org/2012/04/19-testing-minutes.html wilhelm 14:38:47 wilhelm: we have 21.5 minutes left 14:41:14 action: dawagner : visibility ancestry is different than dom ancestry 14:41:37 jleyba: section 10 bullet 3, is in accurate. 14:41:41 inaccurate. 14:45:28 action: dawagner : follow up on 10, last bullet point - element inside a fixed-sized parent, outside the size. 14:47:53 discussion about properties, attributes, regarding section 10.1 14:49:24 jari, dawagner : we should not conflate attributes and properties. 14:51:25 action: 10.1, re-work this section so that only style and aliases are left over. 14:54:36 slightly relevant section of the HTML spec on properties vs attributes: http://www.whatwg.org/specs/web-apps/current-work/#reflecting-content-attributes-in-idl-attributes 14:54:52 dawagner, we could do aliasing in the client libraries. simonstewart : let's leave in the spec 14:55:53 action: section 10.1.2.1 css should always be lower case, colour should always be rgba. 14:59:52 scribe: jari 15:01:42 Action: 10.1.1 - reword to be consistent with the HTML spec (see http://www.whatwg.org/specs/web-apps/current-work/#reflecting-content-attributes-in-idl-attributes) 15:02:40 jleyba: what about non-standard boolean attributes? 15:03:52 dawagner: example: "disabled" on input elements different from "disabled" on a div 15:05:06 Action: 10.1.1 - general cleanup 15:05:34 simonstewart: (reading section 10.1.2) 15:07:00 simonstewart: HTML4 and HTML5 differs in the boolean value of disabled="cheese" and disabled="disabled" 15:08:29 Action: wilhelm investigates HTML4 vs HTML5 and boolean attributes (esp. disabled on input vs non-input elements) 15:11:48 simonstewart: moving to section 10.1.3 15:12:07 plh_ has joined #testing 15:13:31 Action: getElementAttribute algorithm should be explicit why we're special casing URLs (reason: always return absolute URLs) 15:16:44 Action: 10.1.3 - "algorithm defined above" should be named and linked 15:16:46 + iframes, frame, link, map, area 15:17:14 simonstewart: moving on to 10.2 15:17:57 I am heading out, will try join in about 15 mins again 15:21:08 eranm has joined #testing 15:23:31 reading through the algorithm for getting the visible text of an element 15:25:05 action: dawagner: Fix 1.1 of the rendering text algorithm 15:26:29 jimevans: is there need for a command to determine the presence of an element? 15:26:54 jleyba: the efficient way to do this has always been established 15:27:01 s/always/already 15:27:29 not going to be added. 15:27:55 jleyba: reads section 11, Executing JavaScript 15:29:43 davidburns has joined #testing 15:30:13 Action: use "DOMString" WebIDL type over "string" 15:32:16 jleyba: (reading section 11.1, 11.2, 11.3) 15:36:53 dawagner: 11.1: Argument type; dictionary should be of Argument types 15:37:21 Action: limit recursion depth in recursive algorithms (a SHOULD) 15:38:12 discussing alert() in user-provided javascript 15:38:28 simonstewart: should return null to user and browser is in undefined state 15:39:02 jleyba: section 11.4, what do we do with unhandled javascript exceptions on the page? need API for capturing and checking 15:39:24 simonstewart: should be able to use captured logs 15:39:39 jleyba: if there's an unhandled error and you haven't queried for it, the next command should fail 15:39:46 simonstewart: no 15:40:07 jleyba: could be optionally enabled 15:40:23 jleyba: similar to how alerts are handled 15:41:18 jleyba: store errors that have occured on session; add getJavaScriptErrors 15:42:25 jleyba: webdriver perfectly capable of propagating failure when JS errors occur 15:43:20 simonstewart: not sure; gut feeling, seems like overkill 15:43:31 simonstewart: not enough people care about this 15:44:16 leaving this as an open question 15:45:08 dawagner: could have more specific type than UnknownError when we know what's happening (Section 11.3 step 2) 15:45:29 jleyba: could also not throw and just return null 15:45:38 dawagner: makes more sense to throw 15:48:18 Action: link to DOM4 instead of DOM3 15:50:11 RRSAgent, draft minutes 15:50:11 I have made the request to generate http://www.w3.org/2012/04/19-testing-minutes.html wilhelm 15:51:04 darobin has joined #testing 15:52:31 RRSAgent, bye 15:52:31 I see 50 open action items saved in http://www.w3.org/2012/04/19-testing-actions.rdf : 15:52:31 ACTION: Go through the status codes [1] 15:52:31 recorded in http://www.w3.org/2012/04/19-testing-irc#T09-58-59 15:52:31 ACTION: section 3 - specify command names as case sensitive [2] 15:52:31 recorded in http://www.w3.org/2012/04/19-testing-irc#T10-24-30 15:52:31 ACTION: Add a "required capabilities" parameter when creating the session (Section 4.1) [3] 15:52:31