SV_MEETING_TITLE -- 11 Jan 2012

<dawagner> Just invited you to a hangout

<MikeSmith> dawagner, no, not seeing any invite

<dawagner> re-invited you

<dawagner> If no joy, I've encircled you (I'm Daniel Wagner-Hall, dawagner@gmail.com), feel free to invite me to a new one

<dawagner> MikeSmith: Any progress?

<MikeSmith> yup

<MikeSmith> thanks

<MikeSmith> calling in now

<scribe> Scribe: wilhelm

dburns: The current spec consists of a general outline
... spec in two parts: the user side, how people would interact with it, and the IDL side and browser impleemntation
... One of the things we need to work out is how to reference commands, &c.
... We have functional areas of different areas written out. How we turn those areas into functions people can actually use is an open question.
... There is also a mapping defined for the JSON wire protocol.
... At the moment the spec is very light. Today we should figure out how to fill the missing parts.
... How should we interact with IME?
... We need to find and document our open issues.
... If a new language was to create bindings for WebDriver, what would they need to do? What should be tested? Looking from that perspective may help us write the spec.
... How should we actually turn the general requirements into spec form?
... However we write the requirements must work for the different languages we support and want to support. The Ruby bidings are quite flat – .NET is not.

<andreastt> http://dvcs.w3.org/hg/webdriver/raw-file/515b648d58ff/webdriver-spec.html

<andreastt> ^-- the spec

dburns: We try to avoid defining things that are defined somewhere else. Focus, for example, is delegated to HTML5.

MikeSmith: Often what happens after we get quite far along with a spec, is that people come along and ask for use cases and requirements.
... There is a cost to documenting that, but it also helps pre-empt problems you can run into later.
... There is genuine value in having the use cases and requirements documented.
... Someone in the group should commit to write that down.
... One example of this is from the XML Speech Incubator Group.

<MikeSmith> example of a use-cases doc: http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech-20111206/#use-cases

MikeSmith: Such a document helps document what the use cases really are, and may help getting other vendors on board.

andreastt: We need a clear definition of what a window is.
... Added complexity on mobile and TVs.
... Another issue is how the get command should be working. Currently in OperaDriver we have two ways to figure out if the page has actually loaded.
... Some browsers may not be able to fulfill everything, but we should define the ideal.

daniel: We need to define context boundaries, for example between frames.

eran: Similar for interaction. What happens if you move the mouse by a certain offset?

daniel: There are areas where we have complexity in the webdriver implenmentation. We should specify where that complexity should live.
... Yes, stuff like atoms, advanced user interactions. Some of that could be provided by WebDriver or by the browser.

andreastt: A definition of a client and server is missing.
... Example: It is possible to be access the scope protocol from JavaScript, in the browser.
... We should perphaps note that local and remote can be the same thing.

eran: Everything related to localStorage, network state on or off, is missing.
... This is supported in mobile browsers.

andreastt: There is a missing section on vendor extensions.
... What is the core of WebDriver?
... We have Opera-specific stuff.
... Taking a screenshot of a limited area of the screen would be nice to get in the core API.

eran: File upload is missing.

daniel: Permissions model. If we are going to require the driver to do what it wants with the browser, we should state that specifically.

eran: We should allow users to check if SSL certificates are valid, self-signed, etc.

andreastt: In Opera, we have workarounds for browser dialogs - upgrade, installation dialog. Not accessible from JavaScript.
... Command-line option to ignore such dialogs.

(Similar in Firefox)

daniel: We need to define when click returns as well as get.

andreastt: What should happen with syntethic click?

daniel: Every modal behaviour must be defined.
... In the talk of sessions, the only operation we define is creating one. The lifetime and destruction of one should probably be defined.

andreastt: The spec mentions about:blank. This isn't just a plain page.

wilhelm: Should the spec be relevant for end-users, or just implementers?

dburns: Should be defined in idiomatic ways.
... Users have been pointed to the tests. Usecases may help in a similar way.

daniel: Section on modal dialogs is listed as non-normative, despite its MUST statement.
... What is handling non-HTML content?

andreastt: XML, SVG

dburns: We need to be very careful about how we spec SVG interaction. Different uses of SVG.

daniel: Where do we stop? How much should we spec?

wilhelm: From a W3C perspective, I would like to test all W3C specs using these tools. Whether or not that is possible is an open question.

dburns: Should executescript support VBScript?

andreastt: (Dart?)

wilhelm: For many of these technical questions, I suggest deferring to the editors. Make your best judgement. Put it in the spec. Await positive or negative reactions.
... You may also delegate to someone else where applicable.

dburns: How do we handle IME?

eran: We have an existing API that actually works.

wilhelm: What about, say, touch events?

eran: Touch events is the least mature part. How do you define this in a meaningful way? Do we define speed, range of movement?

daniel: Several sections are based on our current behaviour. Is this always beneficial? (findByClassName, cookies)

andreastt: Watir allows selecting by link text (<a>foo</a>).

daniel: bylinktext and gettext behave differently.

eran: There is duplication between the new and old interaction stuff.

andreastt: A touchy area, but often requested: Return the active element.

RRSAgen, make log public

andreastt: Should we have more timeouts than we currently have? If so, how should we specify page load timeouts, etc?
... In OperaDriver, we have one timeout for EcmaScript, there's a page load timeout.

dburns: That's relevant for click and get.

daniel: Specifying timeouts is part of specifying commands.

andreastt: In Opera, there is an API for listing available frames.

dburns: In Firefox, you may list which tabs are available, and which is focused.

wilhelm: Where do browsers disagree today?

andreastt: Colours.

dburns: Some return CSS, some use computed value.

daniel: They disagree in the JS executing wherever browsers diagree in script engines.

eran: Does everyone use atoms for get?

(Yes)

daniel: For cookies, access levels are different in different browsers. You can't always get expiry date.

andreastt: We make assertions on whether elements are displayed and enabled, as we need to be able to click disabled elements when testing the browser.

daniel: isdisplayed is inconsistent.
... Chrome does some special checks.

andreastt: We need to add middle-click.

daniel: The open question of modifier keys on different OSes.

andreastt: COuld be delegated to a testing framework.

daniel: Should be delegated to a different layer.
... getpagesource is inconsistent.

andreastt: Candidate for removal?
... What do we mean by elemen.clear?
... JS clear, or click, backspace?

daniel: Submit is going to be fun to specify.
... We should remove it.

wilhelm: Is there any part of the API or spec that is impossible or unreasonably difficult for one browser to support?

daniel: htmlunit is special.

andreastt: Should we treat htmlunit as equal to the full browsers?

daniel: Logs are very ill-defined.
... How do we export the console logs?

andreastt: Logs are also inconsitent.
... Should gettagname return capital letters or lowercase?
... Implementations differ on assertion of whether an element is stale or not.

wilhelm: How should commands and paramters be written in the spec?

dburns: See section 9.1.2 for one propsal.

daniel: The methods are currently a signature rather than a semantic description.

<dawagner> Reference: http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf

dawagner: See section 9.8.1 i EcmaScript for an example of how this may be done.

wilhelm: See also the steps here: http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#dnd

andreastt: Drag and drop is also an open issue. What happens if you drag between different browsers?

(FindElementBy() is being specced on the whiteboard.)

wilhelm: DOM4 spec may be a good example: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html

(Discussion around spec format for this not minuted closely.)

daniel: What do we do about edge cases? What happens if you try get an element when you don't have a document?
... Where do define exceptions to be returned?

simon: What happens if a modal dialog pops up underway?

eran: Yes, I will propse a spec text for section 15. User input.

simon: Opera has an interesting implementation for screenshots.

wilhelm: Can you draft a spec on screenshots, Andreas?

andreastt: Yes.

simon: Jason Leyba knows much about section 12, executing javascript.
... I will speak to him about making a draft.
... Can you write a draft for 11. Rendering text, Daniel?
... It would be interesting to compare to the innerText spec.
... We could make a spec text that browsers may follow natively, to be included in HTML or DOM spec.

dawagner: Yes, I will write a first draft.

simon: Section 10, reading element state, is a low hanging fruit defined in the atoms.
... Colours is part of that.

dawagner: Jim Evans knows a lot about modal dialogs.
... Jason did a lot of frames stuff.

simon: I suggest doing exactly what WebDriver does today. If you have two windows with three tabs each, that's six windows [browsing contexts].
... How do we do window resizing?
... That should go under the controlling windows seciton.

wilhelm: [test suite]

simon: We should do as much testing as we can in JavaScript. For the rest, we fall back to Python.
... David is the right person to lead the work.

andreastt: WRT an official test suite, what do we do with things that happen entirely within WebDriver?

wilhelm: Are there other organizations we want present at the table in the future? MS has been mentioned, Apple has been mentioned.

simon: I'd like an official representative for the Chrome team. I will find a candidate.

wilhelm: WRT other browser vendors, I suggest we move to a FPWD and the actively encourage them to join us.
... What should we specify and what should be left to implementers?

simon: We spec as little as possible to ensure interoperability, delegate to other specifications where we can.

wilhelm: We've made good progress today – I'm running out of things on my list. Let's end the formal part of the meeting here, and do real work the rest of the day.

- DRAFT -

SV_MEETING_TITLE

11 Jan 2012

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output