Pre-loading browser clipboard for testing pasting into fields with watir-webdriver

Our web application has some event code to "format" an开发者_开发问答y text with pasted into a field so that any HTML styles do not break our data.

What would be a good way to pre-load the browser clipboard so that I can test pasting into the input field?

Is there any way to do it programmatic-ally or would I have the test script visit "a source page" and copy text before moving onto our application?

Any ideas or code snippets would be welcome.

---

Working with the clipboard will depend on your platform. E.g. on OS X, you can use pbcopy and Command-V:

open('|pbcopy', 'w') { |io| io << 'some text' }
browser.text_field(:name => 'q').send_keys([:command, 'v'])

I know there are equivalents on Linux (xclip?). Not sure about Windows.

---

I would consider using the .value= method to set the value. If it's been implemented the same as in watir, then it causes no events to be fired and sets the value directly, and then follow that up by sending an appropriate event (depending on what if any events are being monitored) such as onKeypress. I tried to figure out from the Watir-webdriver rdoc for textfield, if this distinction between .set and .value= has been maintained, but the way the doc describes them (at least there) makes them seem interchangable.. (Jarib can you clarify???)

Potentially you might need to first fire something like onFocus depending on the controls you are using. For example, as described in this SO case Setting a text field that has a JQuery mask on it for a jquery mask, they had to end up firing an unmask event to be able to even set the field.

This is a good case for utilizing the techniques described here How to find out which JavaScript events fired? and in the SO item linked in the comments for that question, to figure out just what events are fired when you manually paste something into a field. (note I would slueth it with both using the mouse, but also using something like tab to move between fields and set the focus, events common to those two methods are the ones most likely to be implemented by the controls.

I presume you have some kind of client side javascript that needs to check what was pasted into the field, and thus the reason for this test. If you are using standard HTML fields, with no javascript stuff, then I would consider this particular test case to be effectively the same as 'testing the browser' since supporting cut and paste in input fields is a standard browser function. In that case, you are sort of 'off the reservation' and I'd not bother with such a test case.