textField method in WebBrowser trait does not allow filling in type=email input fields

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create an input of type=email (<input name="email" type="email" />)
2. Use textField("email").value = "[email protected]"

What is the expected output? What do you see instead?
I would expect that I should be able to set the value of that input. Instead, 
an exception is thrown saying that the element is not a text field.

What version of the product are you using? On what operating system?
2.0.M5b

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 11 Mar 2013 at 1:51

[GoogleCodeExporter]

Is there anything that I can do to help get this in? I'm used to a Git/Github 
style workflow where I could submit a pull request.

Original comment by [email protected] on 16 Mar 2013 at 8:46

[GoogleCodeExporter]

We tried on several occasions to migrate to github, but couldn't get it to work 
without losing history because of a legacy inconsistent directory structure 
from java.net, where ScalaTest was originally hosted. I am going to just drop 
the history at some point and just move it to github to make it easier to get 
contributions like the one you want to contribute. In the meantime, can you 
just checkout the project from Google code, make the enhancements, and submit a 
patch? Thanks.

Original comment by [email protected] on 16 Mar 2013 at 8:53

[GoogleCodeExporter]

I'll give it a try...thanks!

On Saturday, March 16, 2013, wrote:

Original comment by [email protected] on 16 Mar 2013 at 10:41

[GoogleCodeExporter]

Ok I was able to get a patch put together. Please let me know what you think.

Original comment by [email protected] on 31 Mar 2013 at 10:53

Attachments:

• addEmailFieldToSelenium.diff

[GoogleCodeExporter]

Btw, the same thing will happen with type= "number" and all other types of 
input I don't know about. The problem is that there is a different method for 
each type ( a pwdField() was just introduced). 

We need an arbitrary way of sending keys to any element, or cover every single 
type there is. 

Original comment by [email protected] on 8 May 2013 at 7:48

[GoogleCodeExporter]

I'm thinking that enumerating the valid types may be better that just
passing in a key.

On Wednesday, May 8, 2013, wrote:

Original comment by [email protected] on 8 May 2013 at 8:25