FYI: This was previously reported in http://jira.openqa.org/browse/SIDE-309

I believe full stops are also not output using typeKeys in Selenium IDE.

One workaround is to use Selenium RC or Selenium 2 instead of Selenium IDE to run your

tests.

We've got this working nicely in Se2, and we're working on extracting shared JS for

things like this.

I have updated my selenium remote control lib to 2.0a4. but this issue still exists.
my code like this:
selenium.typeKeys("id=username", "lyDam");
then only got "lam" in the textfield.
Can anybody tell me which file should be updated to fix this bug?

Do you use the WebDriverBackedSelenium class to instanciate your "selenium" object ?

I do not use WebDriverBackedSelenium now.
Does this issue only be fixed in WebDriverBackedSelenium? and doesn't fixed in 
client-server mode?

This issue is fixed when you use the WebDriverBackedSelenium class because you use 
WebDriver as a backend instead of Selenium Core. The merge with WebDriver for the Sel-
IDE side is in progress. But I'll see what happens in your case but it's probably in

Selenium Core where the problem occurs and not in Selenium IDE. The file concerned
is 
htmlutils.js (function triggerKeyEvent).

Not a perfect fix, but definitely an improvement from the current situation.

For more details see http://reallysimplethings.wordpress.com/2010/08/27/the-selenium-files-misbehaving-typekeys/

Marking as started as there is a patch attached.

This should really be solved by making use of the keys atom.

So I'm updating the atoms to make sure that we cover some of the common use cases that
people are using with sendKeys (such as using '\13' for return and so on)

Issue 1283 has been merged into this issue.

Issue 1469 has been merged into this issue.

I've had a fix for this ready for some time, but haven't committed for two reasons:

1) Too many users expect the current (broken) behaviour
2) The focus of development is on Selenium 2 and the WebDriver APIs.

The former is the strongest reason why this going to be marked as WontFix.

Issue 3454 has been merged into this issue.

Simon: What could make you reconsider applying your fix? It seems pretty broken to me
that users can't type certain characters via Selenium IDE.

My fix relied on the atoms, which do a far better job of simulating user input than
type or typekeys. Fixing this issue using those would break an awful lot of tests that
expect RC's current awful implementation.

A better solution would be to move the IDE tests to use webdriver by default.

And that move to make IDE use webdriver will be easier now that webdriver js is up to
date and works nicely.

I see. This particular issue is regarding not being able to type 'y' in IDE, and I'm
pretty sure that RC is not affected by this. I suspect you're saying that your atoms
fix will affect both products in a major way. With that, is there any way we can limit
a fix to IDE without going the whole WebDriver route just yet? I would love to see
a short-term fix if possible, but I'm also very keen to discuss the integration of
IDE and WebDriver.

IDE uses the same Selenium Core as RC does, which is why RC is affected too (it also
has trouble with brackets). Changing things so IDE works also changes things so that
RC's behaviour changes.