Selenium 3 and API Change requests - Send them to the list NOW!

[David Burns]

I know that the movement on Selenium 3 has been rather slow but this is a good thing. I know that a number of people would like to get a few API changes in, either signature changes or full changes.

Now is the time to send those emails in to the list so that we can discuss them in case there are some breaking changes. Selenium 3 is a good time for breaking backwards compatibility!

David Burns

[Kevin Menard]

With RC being pulled out, we can get rid of our ancient version of Jetty.  We still need to ship a Selenium server, but I'd like to see that based on virtually anything else.  Jason professed a desire to use netty, I believe.

 

--

Kevin

--

You received this message because you are subscribed to the Google Groups "Selenium Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to selenium-develo...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAPmg_ctt8FJ05bsbiA8%2Bw%2B2YxiQn45fVWRYARdmT5ntnVH77eQ%40mail.gmail.com.

For more options, visit https://groups.google.com/groups/opt_out.

 

[David Lai]

Perhaps some changes around how frames are handled.

I find it annoying when dealing with components that use an iframes, such as rich text editor.

For example, say I want to create a sentence, with 1 line normal text, and 1 line bold.  And the rich text editor has the text portion in the iframe, but the toolbar on the host page.  It's annoying to switch to the iframe, send keys, switch to the toolbar click bold, switch back to the iframe to send more keys, then switch back to the host page to submit the form.

Perhaps we can locate frame like we do web elements and work with them that way.

frame = driver.findFrame(By.css("frame#richtext"))

frame.sendKeys("abcd")

driver.findElement(By.css("#editor button.bold").click()

frame.sendKeys("efgh")

[Jason Leyba]

In no particular order...

1) Rename package: org.openqa.selenium -> org.seleniumhq

2) Attempting to use a WebDriver instance after calling quit() should be a fast error

3) Clean-up and improve explicit wait API

4) Remove implicit waits - this feature causes more trouble than it's worth (and doesn't offer enough over explicit waits)
5) Remove WebDriver.switchTo().frame(String) - that is switching to a frame by its name or ID.  This redundant with WebDriver.switchTo().frame(WebElement).  Switching by name/ID is also ambiguous as to which should be matched first - so we should just standardize on the unambiguous WebElement case.

6) Remove HtmlUnitDriver.  HtmlUnit is not a real browser and does not use a JavaScript engine used by a real browser - it's not worth the trouble.

There's some other internal clean-up I'd like to do, but this is my list of user-facing changes. 

On Tue Jan 28 2014 at 1:41:32 PM, Kevin Menard <ke...@nirvdrum.com> wrote:

With RC being pulled out, we can get rid of our ancient version of Jetty.  We still need to ship a Selenium server, but I'd like to see that based on virtually anything else.  Jason professed a desire to use netty, I believe.

 

--

Kevin

 

 

On Tue, Jan 28, 2014, at 16:39, David Burns wrote:

I know that the movement on Selenium 3 has been rather slow but this is a good thing. I know that a number of people would like to get a few API changes in, either signature changes or full changes.

 

Now is the time to send those emails in to the list so that we can discuss them in case there are some breaking changes. Selenium 3 is a good time for breaking backwards compatibility!

 

David Burns

 

--

You received this message because you are subscribed to the Google Groups "Selenium Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAPmg_ctt8FJ05bsbiA8%2Bw%2B2YxiQn45fVWRYARdmT5ntnVH77eQ%40mail.gmail.com.

For more options, visit https://groups.google.com/groups/opt_out.

 

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/1390945290.8671.76488269.1674EED1%40webmail.messagingengine.com.

[Jason Leyba]

On Tue Jan 28 2014 at 2:24:41 PM, David Lai <sbs...@gmail.com> wrote:

Perhaps some changes around how frames are handled.

I find it annoying when dealing with components that use an iframes, such as rich text editor.

For example, say I want to create a sentence, with 1 line normal text, and 1 line bold.  And the rich text editor has the text portion in the iframe, but the toolbar on the host page.  It's annoying to switch to the iframe, send keys, switch to the toolbar click bold, switch back to the iframe to send more keys, then switch back to the host page to submit the form.

Perhaps we can locate frame like we do web elements and work with them that way.

frame = driver.findFrame(By.css("frame#richtext"))

Too redundant:

WebElement el = driver.findElement(By.css("frame#richtext"));

driver.switchTo().frame(el);

 

frame.sendKeys("abcd")

driver.findElement(By.css("#editor button.bold").click()

frame.sendKeys("efgh")

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to selenium-develo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/5ebd9265-dd41-4037-9ceb-57ab152fd617%40googlegroups.com.

[Christopher Merrill]

I'm new here, so maybe this has been discussed before or there are deep technical reasons that it can't be done.

If I was to improve the frame-handling API, I'd remove the need to switch between them at all. In my mind, this change has two distinct parts:

1) Locate elements in a frame by using the frame as the root. For example:

FrameElement(extends WebElement) frame = (FrameElement) driver.findElement(By.id("frame_id"));

frame.inFramePage().findElement(By.id("element_in_frame"));

2) Interact with elements in and out of the frame without switching. This assumes it is possible to embed the required contextual information into the WebElements returned from the findElement() call:

element_in_outer_page.sendKeys("abc");

element_in_frame.click();

I see this as a much more intuitive API with less cognitive overhead for the programmer.

Chris

To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/-2327880990960143952%40gmail297201516.

For more options, visit https://groups.google.com/groups/opt_out.

--
¡ɹǝʌo ǝɯ lloɹ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı

[Simon Stewart]

Hmmm... API open season wasn't on the game plan for 3.0. We're already causing enough grief with the RC and change from numeric to string based status code changes, so changes in WebDriver are going to be small this time round.

4.0, OTOH....

Simon

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-develo...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAPmg_ctt8FJ05bsbiA8%2Bw%2B2YxiQn45fVWRYARdmT5ntnVH77eQ%40mail.gmail.com.

[Simon Stewart]

Inline

On Wed, Jan 29, 2014 at 6:23 PM, Jason Leyba <jml...@gmail.com> wrote:

In no particular order...

1) Rename package: org.openqa.selenium -> org.seleniumhq

Not this time.

 

2) Attempting to use a WebDriver instance after calling quit() should be a fast error

We already agreed that it would be a fast no-op.

 

3) Clean-up and improve explicit wait API

Concrete suggestion? I'd much rather clean out the less used or carefully designed parts of the support library (event-firing webdriver and the LiFT APIs being the two obvious contenders)

 

4) Remove implicit waits - this feature causes more trouble than it's worth (and doesn't offer enough over explicit waits)

I politely disagree. Yes, it's causing trouble, but the feedback I hear is that it's something that provides some people with a lot of value.

 

5) Remove WebDriver.switchTo().frame(String) - that is switching to a frame by its name or ID.  This redundant with WebDriver.switchTo().frame(WebElement).  Switching by name/ID is also ambiguous as to which should be matched first - so we should just standardize on the unambiguous WebElement case.

I'd be open to that.

 

6) Remove HtmlUnitDriver.  HtmlUnit is not a real browser and does not use a JavaScript engine used by a real browser - it's not worth the trouble.

Really? I think its Peak Trouble days are behind us. However, I'd be fine with the htmlunit guys taking ownership of that driver. Which suggests that our APIs are rock-solid.

Simon

 

There's some other internal clean-up I'd like to do, but this is my list of user-facing changes. 

On Tue Jan 28 2014 at 1:41:32 PM, Kevin Menard <ke...@nirvdrum.com> wrote:

With RC being pulled out, we can get rid of our ancient version of Jetty.  We still need to ship a Selenium server, but I'd like to see that based on virtually anything else.  Jason professed a desire to use netty, I believe.

 

--

Kevin

 

 

On Tue, Jan 28, 2014, at 16:39, David Burns wrote:

I know that the movement on Selenium 3 has been rather slow but this is a good thing. I know that a number of people would like to get a few API changes in, either signature changes or full changes.

 

Now is the time to send those emails in to the list so that we can discuss them in case there are some breaking changes. Selenium 3 is a good time for breaking backwards compatibility!

 

David Burns

 

--

You received this message because you are subscribed to the Google Groups "Selenium Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAPmg_ctt8FJ05bsbiA8%2Bw%2B2YxiQn45fVWRYARdmT5ntnVH77eQ%40mail.gmail.com.

For more options, visit https://groups.google.com/groups/opt_out.

 

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/1390945290.8671.76488269.1674EED1%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to selenium-develo...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/-6180014678882456665%40gmail297201516.

[Jim Evans]

I know some of this has been discussed in IRC, but I want to bring it out here. Most of these are pretty trivial.

• Remove redundant profile options for Firefox in favor of capabilities (native events, accept untrusted certificates, etc.).
• Refactor all browser-specific constructors to use type-safe Options classes instead of raw capabilities maps (in .NET and Java).
• TargetLocator interface's DefaultContent() method should be renamed to reflect switching to top-level frame (.topFrame()? rootFrame()?).
• RemoteWebDriver should directly implement getScreenshot() and throw appropriate exception if browser doesn't support it.
• [.NET only] Timeouts method on IOptions interface should be a property.
• [.NET only] Should consider providing an "interfaces-only" assembly distribution for dependent projects.

[Simon Stewart]

Inline.

On Wed, Jan 29, 2014 at 8:09 PM, Jim Evans <james.h....@gmail.com> wrote:

I know some of this has been discussed in IRC, but I want to bring it out here. Most of these are pretty trivial.

• Remove redundant profile options for Firefox in favor of capabilities (native events, accept untrusted certificates, etc.).

OK

 

• Refactor all browser-specific constructors to use type-safe Options classes instead of raw capabilities maps (in .NET and Java).

We should definitely add Options as a concept. Wondering how this is going to avoid being a complete mess, but maybe I'm just an unnecessarily paranoid soul. 

• TargetLocator interface's DefaultContent() method should be renamed to reflect switching to top-level frame (.topFrame()? rootFrame()?).

Not thought about that before. We could do that.  

• RemoteWebDriver should directly implement getScreenshot() and throw appropriate exception if browser doesn't support it.

Any particular reason for this? 

• [.NET only] Timeouts method on IOptions interface should be a property.

.Net properties are The Daddy. Are you suggesting that the IOptions expose the timeouts that are currently being used by the browser? 

• [.NET only] Should consider providing an "interfaces-only" assembly distribution for dependent projects.

Ditto Java. It's why we've kept the API jars as free of dependencies as possible.

 

On Tuesday, January 28, 2014 4:39:36 PM UTC-5, David Burns wrote:

I know that the movement on Selenium 3 has been rather slow but this is a good thing. I know that a number of people would like to get a few API changes in, either signature changes or full changes.

Now is the time to send those emails in to the list so that we can discuss them in case there are some breaking changes. Selenium 3 is a good time for breaking backwards compatibility!

David Burns

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-develo...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/e39fd9a2-1e8a-4359-a90f-4b82c963946e%40googlegroups.com.

[David Burns]

As long as Selenium 4 isnt too far away. There is divergence, agreed at various W3C meetings, between the spec and the OSS project and when Marionette hits 1.0 it will be compatible with the spec not the OSS project.

David

David Burns
Email: david...@theautomatedtester.co.uk
URL: http://www.theautomatedtester.co.uk/

To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAOrAhYF7WBupk7wwrJG%3DEnrJakev9qfCdviEXyWy7bg8zsmfHQ%40mail.gmail.com.

[Simon Stewart]

3.0 should be spec compliant too, but that's not an invitation for random disruption of the existing APIs. Most of the changes required for the spec aren't user facing.

Simon

To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAPmg_cvXfTVfPjtjUSKEbxr6FEbkEpaXo2G-vMXfqymatYJWJg%40mail.gmail.com.

[Jim Evans]

Also inline.

• RemoteWebDriver should directly implement getScreenshot() and throw appropriate exception if browser doesn't support it.

Any particular reason for this? 

I think the Augmenter pattern is incredibly confusing to most people, and as far as I know it's pretty much only used to get screenshots in the remote case. That seems a little like overkill to me, but I'm not wedded to this. .NET has no easily implemented analogue to the Augmenter, leading to kludgy solutions like "you need to subclass RemoteWebDriver to make this work."

• [.NET only] Timeouts method on IOptions interface should be a property.

.Net properties are The Daddy. Are you suggesting that the IOptions expose the timeouts that are currently being used by the browser?

No, not exactly what I meant, though I think that would solve a user request. In reality, though, I just meant that the Timeouts member of the IOptions interface in the .NET bindings is currently a method, but should be a property (as it takes no arguments and returns a value). That would make it consistent with the other members of that interface (the Cookies property and the Window property, which are driver.manage().cookies() and driver.manage().window() in the Java bindings).

--Jim

On Wednesday, January 29, 2014 3:27:20 PM UTC-5, Simon Stewart wrote:

Inline.

On Wed, Jan 29, 2014 at 8:09 PM, Jim Evans <james.h....@gmail.com> wrote:

I know some of this has been discussed in IRC, but I want to bring it out here. Most of these are pretty trivial.

• Remove redundant profile options for Firefox in favor of capabilities (native events, accept untrusted certificates, etc.).

OK

 

• Refactor all browser-specific constructors to use type-safe Options classes instead of raw capabilities maps (in .NET and Java).

We should definitely add Options as a concept. Wondering how this is going to avoid being a complete mess, but maybe I'm just an unnecessarily paranoid soul. 

• TargetLocator interface's DefaultContent() method should be renamed to reflect switching to top-level frame (.topFrame()? rootFrame()?).

Not thought about that before. We could do that.  

• [.NET only] Should consider providing an "interfaces-only" assembly distribution for dependent projects.

Ditto Java. It's why we've kept the API jars as free of dependencies as possible.

 

On Tuesday, January 28, 2014 4:39:36 PM UTC-5, David Burns wrote:

I know that the movement on Selenium 3 has been rather slow but this is a good thing. I know that a number of people would like to get a few API changes in, either signature changes or full changes.

Now is the time to send those emails in to the list so that we can discuss them in case there are some breaking changes. Selenium 3 is a good time for breaking backwards compatibility!

David Burns

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsub...@googlegroups.com.

[Nick Schonning]

Split the project into language specific projects :P

1GB clone sucks for a new contributor.

On Tuesday, January 28, 2014 4:39:36 PM UTC-5, David Burns wrote:

[Jason Leyba]

Should've done this in a Google doc, easier to track all these comment threads :)

On Wed Jan 29 2014 at 11:58:57 AM, Simon Stewart <simon.m...@gmail.com> wrote:

Inline

On Wed, Jan 29, 2014 at 6:23 PM, Jason Leyba <jml...@gmail.com> wrote:

In no particular order...

1) Rename package: org.openqa.selenium -> org.seleniumhq

Not this time.

 

2) Attempting to use a WebDriver instance after calling quit() should be a fast error

We already agreed that it would be a fast no-op.

Was just stating it for the record :)

 

 

3) Clean-up and improve explicit wait API

Concrete suggestion?

Nit picky things:

WebDriverWait is redundant with FluentWait.

ExpectedCondition is redundant with Function<WebDriver, T>

ExpectedConditions' growth has been too organic and needs a good review. Everything is also tied to ExpectedCondition limiting the use.

 

I'd much rather clean out the less used or carefully designed parts of the support library (event-firing webdriver and the LiFT APIs being the two obvious contenders)

I've never used the LiFT APIs, so can't comment there.  I do cringe every time I step into the event-firing webdriver when debugging, especially with the server where everything gets wrapped.

 

4) Remove implicit waits - this feature causes more trouble than it's worth (and doesn't offer enough over explicit waits)

I politely disagree. Yes, it's causing trouble, but the feedback I hear is that it's something that provides some people with a lot of value.

Fair enough.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAOrAhYGGy4qGnV_ZBaYqaR0%2Bh74jBWAEbNxc2ZJGPxfiOHfaAw%40mail.gmail.com.

[Jason Leyba]

On Wed Jan 29 2014 at 1:49:37 PM, Jim Evans <james.h....@gmail.com> wrote:

Also inline.

• RemoteWebDriver should directly implement getScreenshot() and throw appropriate exception if browser doesn't support it.

Any particular reason for this? 

I think the Augmenter pattern is incredibly confusing to most people, and as far as I know it's pretty much only used to get screenshots in the remote case. That seems a little like overkill to me, but I'm not wedded to this. .NET has no easily implemented analogue to the Augmenter, leading to kludgy solutions like "you need to subclass RemoteWebDriver to make this work."

I'm also not a fan of the Augmenter pattern as its not discoverable - at all.  Maybe the RemoteWebDriver should just augment itself by default?  That still doesn't address the fact that interfaces are added auto-magically and not easily discovered in the code.  I wouldn't object to having RemoteWebDriver implement everything and just throw UnsupportedOperationException when the underlying session can't do something.

To unsubscribe from this group and stop receiving emails from it, send an email to selenium-develo...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/28b7a52f-6c2e-4294-a753-da5d05a76fd9%40googlegroups.com.

[Andreas Tolfsen]

simon.m...@gmail.com writes:

> 3.0 should be spec compliant too, but that's not an invitation for
> random disruption of the existing APIs. Most of the changes required
> for the spec aren't user facing.

This is a good opportunity to clean up some of the oddities of the SPI,
which I think was what dburns was refering to (correct me if I'm
wrong!). I'd like to mention:

- getCurrentWindowHandle(s) → getWindowHandle(s)
- findElements/findChildElements
- Form submit
- Double click vs. multi click
- getCurrentUrl → getUrl?
- getElementAttribute → getAttribute?

[Simon Stewart]

Inline-o-matic[1]

On Wed, Jan 29, 2014 at 9:49 PM, Jim Evans <james.h....@gmail.com> wrote:

Also inline.

• RemoteWebDriver should directly implement getScreenshot() and throw appropriate exception if browser doesn't support it.

Any particular reason for this? 

I think the Augmenter pattern is incredibly confusing to most people, and as far as I know it's pretty much only used to get screenshots in the remote case. That seems a little like overkill to me, but I'm not wedded to this. .NET has no easily implemented analogue to the Augmenter, leading to kludgy solutions like "you need to subclass RemoteWebDriver to make this work."

Screenshots is sufficiently common, I could go along with this. The thought of having an API that lies to users and throws an UnsupportedOperationException (or equivalent) is extremely distasteful, but I can't think of a widely-used driver other than the htmlunit one that can't take screenshots. 

• [.NET only] Timeouts method on IOptions interface should be a property.

.Net properties are The Daddy. Are you suggesting that the IOptions expose the timeouts that are currently being used by the browser?

No, not exactly what I meant, though I think that would solve a user request. In reality, though, I just meant that the Timeouts member of the IOptions interface in the .NET bindings is currently a method, but should be a property (as it takes no arguments and returns a value). That would make it consistent with the other members of that interface (the Cookies property and the Window property, which are driver.manage().cookies() and driver.manage().window() in the Java bindings).

Right. I understand now. Sounds like a nice bit of tidying up. Is it possible to have a property and a method with the same name on a .Net class?

Simon 

 

[1] I remember the good ol' days when inline replies were the norm. 

[Simon Stewart]

On Wed, Jan 29, 2014 at 10:50 PM, Jason Leyba <jml...@gmail.com> wrote:

Should've done this in a Google doc, easier to track all these comment threads :)

I miss Wave too.

 

On Wed Jan 29 2014 at 11:58:57 AM, Simon Stewart <simon.m...@gmail.com> wrote:

Inline

On Wed, Jan 29, 2014 at 6:23 PM, Jason Leyba <jml...@gmail.com> wrote:

In no particular order...

1) Rename package: org.openqa.selenium -> org.seleniumhq

Not this time.

 

2) Attempting to use a WebDriver instance after calling quit() should be a fast error

We already agreed that it would be a fast no-op.

Was just stating it for the record :)

:)

 

 

3) Clean-up and improve explicit wait API

Concrete suggestion?

Nit picky things:

WebDriverWait is redundant with FluentWait.

ExpectedCondition is redundant with Function<WebDriver, T>

I think that these two depend on your users. The driving force behind ExpectedCondition was to make code using the waits a little less heavy on the generics. The main thing that WebDriverWait does beyond FluentWait is to automatically ignore NotFoundExceptions. I'm not tied particularly strongly to either one, but the overhead of keeping them isn't high, especially if we tidy up WebDriverWait's constructors.

As an aside, I've have found myself wanting a version of FluentWait that supported being Void (so, passing a null value into the constructor would be legal in that case only)

 

ExpectedConditions' growth has been too organic and needs a good review. Everything is also tied to ExpectedCondition limiting the use.

Agreed. Volunteering? We could probably do that as part of the 2.x releases.

 

I'd much rather clean out the less used or carefully designed parts of the support library (event-firing webdriver and the LiFT APIs being the two obvious contenders)

I've never used the LiFT APIs, so can't comment there.  I do cringe every time I step into the event-firing webdriver when debugging, especially with the server where everything gets wrapped.

Me too. It could have been so much better.

 

4) Remove implicit waits - this feature causes more trouble than it's worth (and doesn't offer enough over explicit waits)

I politely disagree. Yes, it's causing trouble, but the feedback I hear is that it's something that provides some people with a lot of value.

Fair enough.

Thanks! :)

Simon

[Simon Stewart]

I'm loathe to put a factory on the RemoteWebDriver, which would be the only way in Java to get the RemoteWebDriver instance to augment itself, since subclasses probably wouldn't need it. Having an API that lies to users by pretending to support things it doesn't seems like hostile design to me, so I'd really rather not throw UnsupportedOperationExceptions.

I've yet to find a nice way of balancing between exposing functionality incrementally and making everything discoverable. Perhaps we could modify the "toString" method to provide a clue to users?

Simon

To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/-4537056263467173689%40gmail297201516.

[Simon Stewart]

 You mean tidy up the command names used for the wire protocol? We should probably add the synonyms to the server side first, right?

Simon

[Marc Fisher]

Perhaps we can locate frame like we do web elements and work with them that way.

frame = driver.findFrame(By.css("frame#richtext"))

Too redundant:

WebElement el = driver.findElement(By.css("frame#richtext"));

driver.switchTo().frame(el);

I think you are missing the interesting part of this suggestion which is the introduction of a Frame abstraction rather than the current model based on a global current frame.

Marc 

[Marc Fisher]

• [.NET only] Timeouts method on IOptions interface should be a property.

.Net properties are The Daddy. Are you suggesting that the IOptions expose the timeouts that are currently being used by the browser?

Don't know if that is what Jim is suggesting, but having access to the current values for the timeouts would be useful for certain types of frameworks (allow temporarily setting them for a framework internal action, then reset them back to the original value that the surrounding code may have set).

Marc

[David Burns]

This type of state info for a framework should be in the framework, not in WebDriver in my opinion, people should know what they have set their timeouts too and if a framework messes with it then it's their fault.

David

[Simon Stewart]

If we were to make this sort of change, it would be adding an API that no-one has used before (by definition) and not removing one that is already relied upon. That makes me think this feature is not germane to this particular discussion.

Simon

[Jason Leyba]

No, I just glossed over it. This would require changing how we encode WebElements in the wire protocol so we could identify which frame they belonged to.  This also opens up whether to support using an element in a window that is not currently focused.

Marc 

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-develo...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAEqLoMg1in1-U0-vCj_a7XuGca2nikHmzaKbS9FdmDXdH3wzWQ%40mail.gmail.com.

[Simon Stewart]

On Fri, Jan 31, 2014 at 4:07 AM, Jason Leyba <jml...@gmail.com> wrote:

On Thu Jan 30 2014 at 11:12:15 AM, Marc Fisher <fish...@google.com> wrote:

Perhaps we can locate frame like we do web elements and work with them that way.

frame = driver.findFrame(By.css("frame#richtext"))

Too redundant:

WebElement el = driver.findElement(By.css("frame#richtext"));

driver.switchTo().frame(el);

I think you are missing the interesting part of this suggestion which is the introduction of a Frame abstraction rather than the current model based on a global current frame.

No, I just glossed over it. This would require changing how we encode WebElements in the wire protocol so we could identify which frame they belonged to.  This also opens up whether to support using an element in a window that is not currently focused.

The promise for 3.0 is that it's basically a rationalisation release: we're removing old, deprecated APIs and bringing the undeprecated APIs into line with the spec. Ideally, users who are using selenium webdriver will just drop 3.0 into their tree and Things Just Work. Anything that endangers that is basically off the table for now.

Simon

[Simon Stewart]

We could just flip back to subversion: in most cases there's no need to have the entire history of the project. Less flippantly, it looks like the mercurial developers are aware that this is an issue and are working on "shallow clones". I guess the next thing we'd need to make this really nice to use would be subversion (and p4's) sparse checkouts. With the combination of those two, we'd finally be able to check out just the code we want.

Simon

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-develo...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/f75bab01-0463-4324-a04d-f69720c5df6b%40googlegroups.com.

[Michael Tamm]

Hi all,

what do you think about getting rid of the Augmenter?

Simon recently committed a change, that the RemoteWebDriver implements the interface TakesScreenshot.

As he mentioned in the commit message: the Augmenter isn't very dicoverable and I must agree.

A lot of people just don't get it, because it is a very uncommon pattern.

Let's stick to the standard Java pattern to give the interface WebDriver all possible methods
and if a certain WebDriver implementation does not support a method it should throw an
UnsupportedOperationException.

Michael

2014-01-28 David Burns <david...@theautomatedtester.co.uk>:

I know that the movement on Selenium 3 has been rather slow but this is a good thing. I know that a number of people would like to get a few API changes in, either signature changes or full changes.

Now is the time to send those emails in to the list so that we can discuss them in case there are some breaking changes. Selenium 3 is a good time for breaking backwards compatibility!

David Burns

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-develo...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAPmg_ctt8FJ05bsbiA8%2Bw%2B2YxiQn45fVWRYARdmT5ntnVH77eQ%40mail.gmail.com.

[Simon Stewart]

I'm actually using the Augmenter a lot right now, as I'm dynamically extending selenium at run time. It's not very discoverable, but I'm hiding things in a factory so my users don't need to care about it.

I happen to think that the standard Java pattern is utterly unhelpful to users. Successfully casting to an interface is an implicit promise that the methods will work. Yes, I agree that the discoverability of role-based interfaces isn't great, but it's a darn sight better than actively misleading users.

Simon

To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAHuosh2NmiBi5yrjhc6o%3D%2BOGO18QvEKNT0dP_jD_efH5pad-%2Bg%40mail.gmail.com.

[Daniel Wagner-Hall]

On 7 February 2014 09:19, Simon Stewart <simon.m...@gmail.com> wrote:

I'm actually using the Augmenter a lot right now, as I'm dynamically extending selenium at run time. It's not very discoverable, but I'm hiding things in a factory so my users don't need to care about it.

I happen to think that the standard Java pattern is utterly unhelpful to users. Successfully casting to an interface is an implicit promise that the methods will work. Yes, I agree that the discoverability of role-based interfaces isn't great, but it's a darn sight better than actively misleading users.

I don't think it's worth being honest with our users if they never actually find that honesty.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAOrAhYExWgByNK%2BTX5JQQje63E4ZGtHgvCo-%2BZ_arYDTTtPFvA%40mail.gmail.com.

[Simon Stewart]

On Sat, Feb 8, 2014 at 6:16 AM, Daniel Wagner-Hall <dawa...@gmail.com> wrote:

On 7 February 2014 09:19, Simon Stewart <simon.m...@gmail.com> wrote:

I'm actually using the Augmenter a lot right now, as I'm dynamically extending selenium at run time. It's not very discoverable, but I'm hiding things in a factory so my users don't need to care about it.

I happen to think that the standard Java pattern is utterly unhelpful to users. Successfully casting to an interface is an implicit promise that the methods will work. Yes, I agree that the discoverability of role-based interfaces isn't great, but it's a darn sight better than actively misleading users.

I don't think it's worth being honest with our users if they never actually find that honesty.

I don't think it's worth lying to our users if they find out about it every time.

Simon