--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.
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.
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")
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/-2327880990960143952%40gmail297201516.
--
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.
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.
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 view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/-6180014678882456665%40gmail297201516.To unsubscribe from this group and stop receiving emails from it, send an email to selenium-develo...@googlegroups.com.
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.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAOrAhYF7WBupk7wwrJG%3DEnrJakev9qfCdviEXyWy7bg8zsmfHQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAPmg_cvXfTVfPjtjUSKEbxr6FEbkEpaXo2G-vMXfqymatYJWJg%40mail.gmail.com.
- RemoteWebDriver should directly implement getScreenshot() and throw appropriate exception if browser doesn't support it.
Any particular reason for this?
.Net properties are The Daddy. Are you suggesting that the IOptions expose the timeouts that are currently being used by the browser?
- [.NET only] Timeouts method on IOptions interface should be a property.
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.
InlineOn 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.seleniumhqNot this time.
2) Attempting to use a WebDriver instance after calling quit() should be a fast errorWe already agreed that it would be a fast no-op.
3) Clean-up and improve explicit wait APIConcrete 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.
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAOrAhYGGy4qGnV_ZBaYqaR0%2Bh74jBWAEbNxc2ZJGPxfiOHfaAw%40mail.gmail.com.
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."
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.
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."
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)..Net properties are The Daddy. Are you suggesting that the IOptions expose the timeouts that are currently being used by the browser?
- [.NET only] Timeouts method on IOptions interface should be a property.
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:InlineOn 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.seleniumhqNot this time.2) Attempting to use a WebDriver instance after calling quit() should be a fast errorWe already agreed that it would be a fast no-op.Was just stating it for the record :)
3) Clean-up and improve explicit wait APIConcrete 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/-4537056263467173689%40gmail297201516.
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);
- [.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?
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.
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.
--
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.
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.
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.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAOrAhYExWgByNK%2BTX5JQQje63E4ZGtHgvCo-%2BZ_arYDTTtPFvA%40mail.gmail.com.
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.