Browser testing and tools WG, WebDriver spec -- 11 Nov 2013

<wilhelm> Scribe: MikeSmith

<wilhelm> ScribeNick:: MikeSmith

<simonstewart> Here we go!

Intro

<MikeSmith> wilhelm giving introductory comments

<MikeSmith> simonstewart is here, gives self-intro

<MikeSmith> simonstewart is from Facebook

<MikeSmith> AutomatedTester David Burns frmo MOzilla

<MikeSmith> Mark Fischer from Google

<MikeSmith> @@ from GOogle, working WebDriver

<MikeSmith> @@ From SkPlanet

<MikeSmith> Mr. Lee from Korea, @@ COmmunications

<MikeSmith> @@ from Korea

<cwdoh> first guy, His name is hyunsuk shin.

<MikeSmith> @@ From Shanghai, Baidu

<MikeSmith> Denis from W3C

<MikeSmith> Isobe-san from Japan

<MikeSmith> Kawada-san from Japan

<MikeSmith> Minami-san from Toshia

<MikeSmith> Journalist

<MikeSmith> @@

<MikeSmith> @@ from @@

<MikeSmith> Wong Wei from Beijing

<MikeSmith> Erika from Microsoft

<MikeSmith> @@ from Tencent

<MikeSmith> @@

<MikeSmith> some other folks who are observers from Korea

<MikeSmith> Kim from Korea

<MikeSmith> @@ from Microsoft china

<MikeSmith> Mr. Lee from CSI

What the hell are we working on and how far along are we?

<MikeSmith> simonstewart describes the purpose of the WEbDriver API

<MikeSmith> ... which is it automate the behavior of a user

<MikeSmith> ... runs out of process

<MikeSmith> ... and runs outside of the JavaScript sandbox

<MikeSmith> ... and runns "outside the glass"

<MikeSmith> ... can do cross-site testing, for example

<MikeSmith> ... and can test things that are not possible to test just with JavaScript

<MikeSmith> simonstewart: started with Microsoft driver, then Opera driver, and Chrome driver, with some preliminary support for Android

<MikeSmith> ... and MOzilla, and also btw, Mozilla has a project called Marionette

<simonstewart> Started with Selenium WebDriver, which is home of the current IEDriver and firefoxdriver

<MikeSmith> simonstewart: last f2f we had was in Boston

<MikeSmith> simonstewart: we have various language bindings

Agenda review

<simonstewart> http://www.w3.org/wiki/WebDriver/2013-TPAC-F2F

<MikeSmith> - Shadow DOM - Current spec API vs Future API

<MikeSmith> - Handling of Accelerometer

<MikeSmith> - Scroll to Element API

<MikeSmith> - Window Management

<MikeSmith> - Define Interactable vs Visible semantics

Shadow DOM

<MikeSmith> mark describes purpose of Shadow DOM

<simonstewart> Does anyone have a spare MacBook Air video adapter? Mini-DVI to VGA, I think?

<cwdoh> i have

<simonstewart> Definitely VGA.

<cwdoh> sorry

<cwdoh> Mac to VGa

<cwdoh> ?

<simonstewart> Mac to VGA

<simonstewart> Yes

<simonstewart> Thankyou, cwdoh!

<MikeSmith> mark: issue with Shadow DOM is that interacts differently in terms of how we normally do testing

<MikeSmith> Gao gives short presentation about Shadow DOM

<MikeSmith> Gao: right now, we have to include a lot of verbosity in our testing code just to be able to get to Shadow DOM content

<simonstewart> Interesting point about the cross-shadow DOM interactions.

<MikeSmith> Gao: even worse for deeply-nested shadow dom

<MikeSmith> Gao shows proposed new API, which makes the testing code look much cleaner and shorter

<jimevans> is the proposal available online for inspection?

<MikeSmith> Gao discusses pros and cons of new proposed api

<MikeSmith> simonstewart: what happens when you have multiple shadow documents attached to the same shadow root?

<MikeSmith> mark: you get a list back

<MikeSmith> mark: most important thing is that a web element, once located, should continue to be usable

<MikeSmith> ... that's where you really get the biggest advantage in terms of the test size

<MikeSmith> ... the switchTo* additions are less importan

<MikeSmith> simonstewart: we deal with this now by stashing IDs on the equivalent of a Window

<MikeSmith> simonstewart: I don't think we need switchToFrame

<MikeSmith> trackbot, start meeting

<trackbot> Sorry, but no Tracker is associated with this channel.

<simonstewart> http://www.w3.org/TR/shadow-dom/

<MikeSmith> mark: similar to how content scripts work in chrome xtensions

<simonstewart> wilhelm, can you please add "drag and drop of elements across frames" to the agenda?

<wilhelm> simonstewart: Done.

<simonstewart> Thank you

<MikeSmith> simonstewart: we have decided there will be a shadow root, will have getActiveElement

<MikeSmith> ... weill add an API for finding shadow roots

<MikeSmith> simonstewart: that was remarkably unpainful

<MikeSmith> ... I think that's because we don't know much about shadow dom...

Acceleromator

<MikeSmith> AutomatedTester: using the phrase Acceleromator quite loosly here

<simonstewart> "device orientation" might be a better fit.

<MikeSmith> simonstewart: orientation of the device in 3D space

<jimevans> roll

<MikeSmith> http://dev.w3.org/geo/api/spec-source-orientation.html

<ArtB> ACTION: barstow start a CfC to publish LCWD of DOM Parsing and Serialization [recorded in http://www.w3.org/2013/11/11-testing-minutes.html#action01]

<trackbot> Sorry, but no Tracker is associated with this channel.

<ArtB> ooops

<AutomatedTester> MikeSmith: mobile-jsonwp-spec google group

<MikeSmith> discussing alpha-beta-gamma vs roll-pitch-yaw

<MikeSmith> discussion about what points in maturity of other specs we start to add support in WebDriver for those specs

<MikeSmith> mark: not talking about shadow dom at all in the Webdriver spec would be better than what we have in the WebDriver spec now

<MikeSmith> wilhelm: we should move all unstable stuff to a separate draft

<MikeSmith> simonstewart: happy to punt shadow dom and device orientation

<MikeSmith> fyi http://caniuse.com/#search=orientation

<jimevans> +1 for moving

ScrollToElement API

<MikeSmith> AutomatedTester: this came from some of the open-source projects

<simonstewart> Who requested this again?

<MikeSmith> simonstewart: PageDown

<MikeSmith> Alexei from Selenium open-source porject brought this up

<MikeSmith> mark: so this API would look like, 1. find an element, then 2. scroll to it

<jimevans> what does "scroll to it" mean? scroll it to the top of the view port? the center of the view port? the bottom of the view port? something else? scroll the entire element? only the part that will fit?

<MikeSmith> simonstewart: normally we say, bring the center of the element into the viewport

<MikeSmith> simonstewart: we've yet to need such an API in many years

<MikeSmith> the room was in favor of not having a scroll-to-element API

Window management

<MikeSmith> AutomatedTester: this came from Alexei

<MikeSmith> ... currently the API requires that we pass through a window handle (unique key) but we don't use it

<MikeSmith> simonstewart: we do use it

<MikeSmith> AutomatedTester: take a look at the resize command

<MikeSmith> discussion indicates we might have a bug in the implementations

<MikeSmith> 45 minutes break

<MikeSmith> we will back at 11:15 local time

<Sam_Lin> Hey

<wilhelm> Scribe: wilhelm

<scribe> Chair: simonstewart

Define interactable vs visible semantics

simonstewart: We discussed this at the previous F2F. That hurt quite a lot.
... We should nail this down now.

AutomatedTester: One of the things that come up regularly has to with viewport sizes, where elements end up on top of each other.
... It's possibly just a Gecko bug. If you fire an event, it sometimes fires through an element.
... Technically, it's visible.

simonstewart: Like the clickjacking problem?

AutomatedTester: Yes.
... If you tap it, it would do nothing.
... When automating, it sometimes works, sometimes doesn't.
... When something has overflowed, not in same part of the DOM tree, but overlapping.
... There's problems like that.

(Discussion on specific case where an element is visible not not interactable.)

simonstewart: If you could use tab ordering to get to the element, you'd be okay.
... A problem that a naive implementation of most of the inputs would just find the element and send events to it.
... More advanced implementation: Find the coordinates, interact with those.

Marc: Newer versions if Firefox does this.

simonstewart: FFDriver with native events does this. OS-level equivalent events.

AutomatedTester: Marionette gets this slightly wrong.

simonstewart: IEdriver does the expected thing.
... I think visibility, even if obsucred by z-ordering, you're technically visible.
... "If you're partly obscured, are you visible?"

Marc: The primary use of this is to determine if you can click something.

simonstewart: We have clickjacking tests for this in the Selenium test suite.

<simonstewart> MikeSmith: I have jimevans on skype

simonstewart: It might be reasonable to go: we will do our best to interact with this element, but overlapping elements may intercept the element.

<jimevans> all set thanks

Marc: You want it to click the element you want it to click, or say it can't.
... And error is fine.
... Should we also have a predicate to check if ...

simonstewart: How often do you see problems with this?

Marc: If we take our FF tests and run them in Chrome.
... Tests start failing.
... Some of this is bad tests.
... They wait until something is displayed, so you should be able to click something.
... Not sufficient.
... isInteractable? makes more sense.

AutomatedTester: This matches our use case.
... (Describes this wrt. animations.)

simonstewart: The problem you're talking about sounds like the animation hasn't finished yet when you ask isVisible?.
... THe problem is waiting for the animation to finish. Separate use case.

AutomatedTester: isDisplayed will say true for both cases.
... Top one is visible and interactable. Bottom is visible, but not interactable.

simonstewart: ChromeDriver imeplementation makes sense.

Marc: You'll have to wait for element on top to be gone.
... You don't care about that element. You care about the element underneath.

When can I click on A?

scribe: Your test should not depend on anything else than the element you care about.

simonstewart: Why doesn't your test author know about the covering lightbox?
... You want your tests breaking with a new, unknown lightbox.
... Something that dismisses itself should be easily detectable

Marc: The next time something new is added, you must update all your tests.

simonstewart: If it never?

Marc: If it never happens, you time out.

simonstewart: I'm trying to think of a case where you shouldn't need to edit your test.
... I see why a new API is convenient, but not compelling...
... Use case of "I don't know if my animations are finished"
... If an element is covered by something in z-order, is it visible?
... I say yes.
... What if only one pixel is visible?

Marc: How do you deal with opacity, etc?

AutomatedTester: A user trying to do this: "I can see that element, it it visible"
... If find the element, bounding box...

simonstewart: You'd need that for ever element in that area.
... Very expensive.
... CSS shapes?

AutomatedTester: I agree.
... On mobile, people check if something is visible.

Marc: They're trying to test if something is hidden by another element.
... We cant do that well.
... Screenshot diffing may be better.

simonstewart: Seems like a super-specialized use case.

AutomatedTester: Transforms are super-lightweight.

simonstewart: (Describing why this is still expensive.)

AutomatedTester: But people do it.

simonstewart: I don't believe this happens as often as you think.

AutomatedTester: Disagrees.

simonstewart: Then we should define this in a later version of the spec.

(Discussion on element at point.)

AutomatedTester: Element at point does not support opacity.

simonstewart: And transforms, shapes.
... Do we want to add this additional complexity? Already very expensive.
... To support use case of an inefficient transform.
... This will be used by getText.

AutomatedTester: If we do responsvive design. Something got really big, things start overlapping as it gets smaller...
... What happens in this case?

simonstewart: If you can scroll to it, gettext would return the content.
... Done at the block level.
... We have never paid attention to viewport size.
... If a bit of text was visible, we would return all the text.
... We are verging on having to write an AI for the visibility tests...

<simonstewart> :)

AutomatedTester: Agreed.
... Your average developer will go "I don't understand why this is visible/invisible"
... "I can see this element, it must be visible"

Marc: "I can't see it, it should not be visible."

simonstewart: It's not visible, but displayed.

AutomatedTester: Did we change the spec? The wording is "visibility".

simonstewart: We should change the section name.

<scribe> ACTION: Rename section 10.1: determining visibility > determining displayed [recorded in http://www.w3.org/2013/11/11-testing-minutes.html#action02]

<trackbot> Sorry, but no Tracker is associated with this channel.

trackbot, bye

simonstewart: Conclusion: rename section, we don't try to count all the crazy things try to do.

AutomatedTester: Is there a better word?
... So many synonyms.

simonstewart: isDIsplayed matches people's expectations.

Marc: Matches CSS.

simonstewart: There will always be edge cases. "Opacity of 1%..."
... Not adding options for fuzzy boundaries.
... We want to give this part of the away spec away to some other group. For example CSS.
... It touches both DOM and CSS, so they don't want to take it.
... Maybe we can punt it to Accessibility?

<scribe> ACTION: Discuss isDisplayed with Accessibility groups [recorded in http://www.w3.org/2013/11/11-testing-minutes.html#action03]

AutomatedTester: Other issues with disabled elements in an AT.

simonstewart: If you have overflow hidden, and it's pushed out of its container...

(Discussion between jimevans and simonstewart on overflow hidden and complexity.)

<simonstewart> jimevans: would you suggest any changes to isDisplayed?

<jimevans> my specific case involves elements where in an overflow: hidden, but can be scrolled using gestures a la mobile cases.

<jimevans> can't be scrolled using a mouse gesture, but can be done so via a drag gesture.

<jimevans> current implementations do not allow that element to be "displayed"

AutomatedTester: Easy implementation: Not displayed.

simonstewart: You could do a drag on a mobile.

Marc: Is this a sequence of scroll operations?

simonstewart: Yes.

AutomatedTester: Today, this is reported as not dispayed.
... (Draws this concept on the whiteboard.)

simonstewart: For the sake of simplicity, let's keep it as it is.

AutomatedTester: Easy implementation is keep it. THe correct implementation is that it is displayed.
... As Marc says, you can do actions.

simonstewart: Conclusion: We leave is as-is. We rename the section. We must define "displayed" and "visible".
... Any objections?

<scribe> ACTION: simonstewart to define "displayed" and "visible" in the spec [recorded in http://www.w3.org/2013/11/11-testing-minutes.html#action04]

Interactable elements

simonstewart: Thisis a super-expensive operation.

Marc: Not neccessarily.

(Discussion on methods to determine this.)

Marc: Do element at point at the point you want to click.
... If that's not the element you want to click, throw an exception.

simonstewart: If using the advanced user interaction, you can click the element even if the center of the bounding box is covered.
... You can have an usually complex objects (links) where the center of the rect is irrelevant.

<jimevans> actions are a horrible solution, unless you have a "scroll to element" api, which we've rejected. the workaround is element.scrollIntoView, but that is an explicit bypassing of the "displayed" algorithm.

simonstewart: I feel dirty adding isInteractable.
... It should be redundant?

AutomatedTester: Life's not that easy.

simonstewart: FFOS seems to be the biggest driver for this...

Marc: we use a JS predicament to check if something is clickable..

<jimevans> the bottom line is people want to interact with elements. this sometimes requires waiting for the element to be interactable (whether that's to exist, or to be displayed, or to be in the viewport)

Marc: Checks that it is displayed, and not disabled.
... "Can I click on this button?"

simonstewart: I can see why people want it. It makes me feel dirty.

AutomatedTester: Google brought this up last time.

simonstewart: It feels like a failiure somewhere else in the spec.
... What's the super-tight definition of isInteractable?

Marc: May not be appropraite...

simonstewart: List the ways.

Marc: Can you send keys?
... Can you click?

AutomatedTester: Not clickable, but you can send keys...

simonstewart: If you can be an active element, you can send keys to it.

Marc: Clickable? tappable?

<simonstewart> "Clappable"? "Tickable"?

simonstewart: We are no longer considering keyboard input.

Marc: having a test for this allows you to avoid try, catch.
... This is something you want to wait for.

simonstewart: How would we define it?

<jimevans> if click would throw, return false?

simonstewart: Needs to be done with reference to click and tap.

Marc: How does ChromeDriver do this?

ShuotaoGao: We use an item to function to determine the position of the element. If it's covered..

Marc: How do you detect if it's covered?

<simonstewart> Relevant part of the spec: https://dvcs.w3.org/hg/webdriver/raw-file/tip/webdriver-spec.html#clicking

<Sam_> by some other elements and it is not clickalbe, it returns false.

ShutaoGao: I can check..

(Scribe is having some network issues. Missed part of the discussion here.)

simonstewart: We would be modifying our definiton of interactable, which is already in the spec.
... If the intention is to support your use cases, we can't ignore pointer events.
... You'd need a list of all elements ordered by Z-order.

Marc: And then check which one would get the click.
... Doesn't sound that hard... The browser must be doing something?

AutomatedTester: I don't think there's an exposed API...
... Not implementable?

Marc: CSS pointer events is the one causing us problems...

simonstewart: Life isn't easy!

AutomatedTester: Should we do the easy thing or the right thing?

simonstewart: We did the easy thing with displayed.
... Because we'd already hit an incredibly complex situation.
... We should do the right thing here.
... Our users would be upset and annoyed.
... (if not)

AutomatedTester: I need to talk with the graphics and layout team.

simonstewart: Can you chase them down during lunch?

AutomatedTester: I can try.

Lunch!

We will reconvene at 14:00.

(Lunch is extra long to allow for informal discussions.)

<AutomatedTester> heycam: I should have looked at the spec http://dev.w3.org/csswg/cssom-view/#extensions-to-the-document-interface

<AutomatedTester> there is a specific note on pointer events

<AutomatedTester> thanks again for the help, you made my day!

<heycam> AutomatedTester, great :)

<MikeSmith> _win 16

<scribe> Scribe: wilhelm

Interactable

simonstewart: Is what we discussed implementable?

AutomatedTester: Short answer: yes.

<simonstewart> cssom view model spec

AutomatedTester: We can see if an element is interactable from elementfrompoint.

<jgraham> AutomatedTester, others imput to https://etherpad.mozilla.org/MeHiumCufk welcome

simonstewart: That reference is in a non-nomrative section.

<AutomatedTester> http://dev.w3.org/csswg/cssom-view/#extensions-to-the-document-interface

simonstewart: Is there a normative section?

AutomatedTester: It does a few checks on where X and Y is.
... When we do this, the elmentfrompoint we're looking for is the center.

simonstewart: Not neccessarily the center.

AutomatedTester: Well, some sort of rect.
... If X or Y is negative, it will return null.
... (Quouting spec.)

Marc: Is hit testing defineD?

AutomatedTester: There is no definition here.

<zcorpan> hit testing is not defined

zcorpan: Are you busy in a meeting now? Would you be interested in dropping by the WebDriver meeting on this topic? (c:

<zcorpan> i guess i could drop by

\o/

Second floor, Browser Testing and Tools. Wutong hall.

AutomatedTester: Do we want to force a scroll?
... Our spec is where we want to go, not where we are now.

(Discussion on whether we'd force a scroll)

Marc: Infinite scroll. Don't scroll if you don't have to.

simonstewart: Don't ask if an element is interactable if you don't want to scroll..

AutomatedTester: One of the things we want to figure out with WebDriver is whether an element is interactable.
... Can a user click or interact with element?
... Can we just use elementfrompoint here?

zcorpan: Hit testing isn't defined in any spec yet.
... There is also a quirk in the elementfrompoint API. If you click outside the root element, it will return the root element.

Marc: That's not a problem for us.
... The API is that the user finds a node and wants to click it. We want to verify that the click will hit that node, and not an element further up in the z-index.

simonstewart: The user may want to wait until the element they want to click is available to be clicked.
... There's also the case of a transparent div on top.

zcorpan: You should be able to use elementfrompoint for this.

simonstewart: (Quotes non-normative note on elementfrompoint.)

zcorpan: The normative part is in the algorithm itself.

simonstewart: What if I was insane and used an absolutely positioned iframe over an element?

zcorpan: I haven't tested that.
... You wouldn't be able to return an element in the iframe. CORS.
... X/Y is based on the viewport. There is a proposal for basing it on the document.

AutomatedTester: Gecko has this. Not exposed.

zcorpan: If there is a use case and implementor interest, we can just spec it.

simonstewart: We would use it.

zcorpan: I can see that it can make sense to use document coordinates.

AutomatedTester: Who raised the issue?

zcropan: I can't remember. Probably in bugzilla.

simonstewart: We have an API called isdisplayed. (Describes the feature.)
... It is an incredibly complcated algorithm.
... Particularly with overflow:hidden;, 3D transforms, etc.
... Is there anything in CSSOM we can use?

zcropan: Not right now.

zcorpan: What is the use case?

simonstewart: (Describes how a web application test would use isvisible.)

zcorpan: For extending CSSOM, we need a use case for authors.

simonstewart: (Points to page visibility spec.)

AutomatedTester: If an element is not visible, you can remove elements from DOM for performance.

zcropan: It would be good to write down the use case and send to the list or in a bug.

<scribe> ACTION: Send an email to www-style describing the use case for our visibility check [recorded in http://www.w3.org/2013/11/11-testing-minutes.html#action05]

<scribe> ACTION: Request elementfrompoint with a DOM relative coordinate instead of a viewport relative coordinate [recorded in http://www.w3.org/2013/11/11-testing-minutes.html#action06]

(Discussion on using elementfrompoint as a tool to determine visibility.)

Marc: If you have a partially included element, and use elementfrompoint, it could say it's not displayed.
... We'll end up with a greater amout of inconsistency.
... It'll depend entirely on whether the center pixel is covered up.

simonstewart: We are definiing what these things are. We could add additional things.
... Maybe not just the center pixel of any of the client rects visible.
... Compass: N, NE, E, ... Are any of those visible?

Marc: You'd still get pathological cases.

simonstewart: We already have those.

Marc: Right now, we have good locality on where the pathologicality comes from.
... Losing the locality is what bothers me.
... An overlaying element could be 0% opaque and block the events, or 100% opaque and not block the events.

simonstewart: I'd like to simplify...
... It's hard to escape having interactable and displayed...
... If we could define displayed in terms of interactable, it would be okay.

Marc: They are about two different devices.
... Displayed is about the video. Interactable is about the mouse and input.
... Difference is to be expected.

simonstewart: Mjeeh.

<simonstewart> meh

AutomatedTester: I don't see interactable and displayed as ugly in the spec.

simonstewart: Let's make a decision.

<simonstewart> http://dev.w3.org/csswg/cssom-view/#extensions-to-the-document-interface

simonstewart: We add isInteractable with a non-normative note that it should be based on elementfrompoint.

Marc: I'd like it to have a different name.

simonstewart: Hit test.
... isHittable?

<scribe> ACTION: Create the API for isInteractable and document it [recorded in http://www.w3.org/2013/11/11-testing-minutes.html#action07]

<scribe> ACTION: Come up with a better name than isInteractable [recorded in http://www.w3.org/2013/11/11-testing-minutes.html#action08]

AutomatedTester will do the above two actions.

Drag and drop of elements across frames

simonstewart: "Will elements retain identifier across frames?"
... There isn't a cross-platform accessibilty tree that's shared by ... anything.
... Use case: Doing an advanced user interaction dragging an element from document A to document B.
... Intuitively, this should work without requring switching frame.

<ISL> does this mean the elements will not retain the identifier across frames?

AutomatedTester: Not sure.

simonstewart: I would expect some sort of event ...

AutomatedTester: Can you drag elements from document A to an iframe?
... Possible sandboxing issues.

simonstewart: You can drag elements between frames as long as they are in the same domain.

<ISL> The elements should retain the identifier since the system is responsible for manging these things.

<simonstewart> ISL: Do you mean the ID assigned by webdriver, or the value of "element.id"?

<simonstewart> Presumably the former?

<ISL> yes, the id assigned by webdriver.

simonstewart: The id of the element must change as a new element is created in the other document.

Marc: The element would also exist in the first document.

AutomatedTester: If it's going between documents, it would presumably do createELement..

<simonstewart> http://www.bluestudios.co.uk/blog/sandbox/iframe/iframe.html

AutomatedTester: It deletes the element from page A and creates it on page B.

<ISL> I think the matter is that how system manages this. It does matter if the id might be changed when across frames.

<ISL> my opinion.

<ISL> doesnt*

simonstewart: It is designed to be implented: drag from this element to this element. It would give you the coordinates.

Marc: Targeting the dragend is the difficult part.

simonstewart: Yes.
... You've got a reference to an element in document A and document B.
... You'll get an exception.

Marc: Switch to frame is a pain.

simonstewart: It makes the implementation a lot more complex.

Marc: Throw one layer of abstraction above it.

<ISL> it must be very complex.

Marc: The top-level map would never relase those elements?
... I'm not sure I'd worry about that.
... If it isn't runinng for a long time, who cares?

simonstewart: On mobile, you'll exhaust the memory faster.
... I worry about the implementation. How do you do this without leaking?

<ISL> This is what i've mentioned, the system should handle this.

simonstewart: Element ID should be an opaque string.

Marc: we could incorporate the window ID into the element ID.

simonstewart: It's just a string.

Marc: WebDriver implementors can give it meaning.

AutomatedTester: Mozilla can't do this. Firefox OS: One window, many frames.

simonstewart: Suggestion is: You can maintain a mapping of these prefixes lead to this document...
... Every time you need an element ID, you cycle through the documents.

AutomatedTester: Sounds very expensive.

Marc: you'd start with the current window.
... 99% of the time, it would be fine.

<ISL> Agree with simonstewart, if this algorithm is well designed.

simonstewart: (Draws the concept on the whiteboard.)
... (still drawing and explaining.)

AutomatedTester: It will still be relatively expensive.

Marc: Same expensive in memory.
... Will burn more CPU.

simonstewart: Even with 100 apps...
... 5 frames in each. 500 iframes!
... Hashmap of some sort.
... You're running at 500Mhz+. 2-3ms for the whole operation.

Marc: Someone who wanted to optimize this could encode a window ID into the element ID.

AutomatedTester: Trying to think of worst case scenario on a low-end device.

<ISL> it could cause some confusions by ecnoding two ids in the same.

simonstewart: The element ID is an opaque string.

Marc: If it's a really bad implementation, we alrady have that problem...

<ISL> the system might need a mechanism to manage these two.

AutomatedTester: (Points to whiteboard, explaining.)

simonstewart: If someone has a crap implementation, there's not much we can do for them.
... If they want to make a more efficient implementation, by sending back some info in the element ID, that's fine as well.

<ISL> agree.

AutomatedTester: There are ways of doing it.

simonstewart: There are very few implementations of the remote end.

Marc: Fewer than a dozen.

simonstewart: Performance is a matter for the implementor.

<ISL> yes, the algorithm matters in this discussion.

simonstewart: We can do this in an efficient way, that does not cause memory leaks.

<simonstewart> ISL? How so?

<simonstewart> We've not specified at any point how remote ends look up element IDs and map them to elements

(Further discussion and whiteboard explainations of possible implementations.)

simonstewart: Conclusion: All interaction with elements can only be done if the frame is the active frame.
... Which is basically what we have now in the spec.

Pause

We reconvene at 16:00.

<Automate_> mdas: yt?

<AutomatedTester> jgraham: hey are you on mozilla IRC?

<jgraham> AutomatedTester: I can be

<jgraham> Or yes, but not in this screen session

<AutomatedTester> ok, could you see if fox2mike is in #developers and ask him to allow more connections to mozilla irc from 183.11.223.194

<AutomatedTester> i think that is the right IP

<jgraham> OK, asked

<AutomatedTester> thanks!

<jgraham> AutomatedTester: 07:24 < glob> jgraham, shyam's probably asleep, and this isn't the right channel for that. it's best to file an IT bug (in mozilla.org :: server operations) asking for the limit to be increased

<jgraham> 07:24 < glob> jgraham, make sure you provide the IP address as well as the duration for the increase (eg. if it's for a work week)

<jgraham> AutomatedTester: ^

<AutomatedTester> jgraham: tell glob that I owe him a hug

<simonste_> And we're back

<Ms2ger> Moin

Work on the spec and test suite

Formal discussions are finished for today. We work on the test suite and spec.

We reconvene the formal discussions tomorrow at 09:00.

<AutomatedTester> http://mxr.mozilla.org/mozilla-central/source/testing/marionette/marionette-listener.js

- DRAFT -

Browser testing and tools WG, WebDriver spec

11 Nov 2013

Attendees

Contents

Intro

What the hell are we working on and how far along are we?

Agenda review

Shadow DOM

Acceleromator

ScrollToElement API

Window management

Define interactable vs visible semantics

Interactable elements

Lunch!

Interactable

Drag and drop of elements across frames

Pause

Work on the spec and test suite

Summary of Action Items

Scribe.perl diagnostic output