I noticed an older version of Watir had a bubble attribute to fire_event. Why was that removed?
Disabling bubbling in that case to make sure production code binds on the input and not via delegates, would make writing this test possible. I mean, unless somehow using the fireEvent.js directly that's in Watir's repo.
I redact my comment of Chrome not bubbling — sometimes I think debugging browser events is the greatest source of heisenbugs — but the question of bubbling removal remains. :)
I don't think it ever existed in watir-webdriver, but it shouldn't be difficult to add.
However, instead of using hacks like execute_script and fire_event I would recommend to use the available APIs to actually emulate the user - i.e., do a real paste with Command/Control-V.
@jarib I originally read the docs on your GitHub site and there fire_event has bubbling.
I agree about the hacks, but given how send_keys (seems) to work and do focus, I wanted the form to be filled without any keyups being fired and any focus being mangled (so not to fire change either). Pasting via [:command, 'v'] also triggers keyup. And that would've required filling the clipboard, too. :) And using right_click for context menu pasting would've interfered with using the computer while testing.
I didn't, however, find a way to trigger paste [silently] using the Mac Edit menu. That would've been sufficient, tho.
Why would you want the form to be filled without keyups? How would a user do that? How would you test it manually?
Your comment about testing that your jQuery code binds on the input and not via delegates makes me think you're testing this stuff at the wrong level.
Unfortunately, the thing is, if you do right click on Chrome or on an iPad and select paste, no keyups get fired.
I didn't really want to test for jQuery binds, more like try to match browser behavior conservatively.
If we browse the Quirksmode site we'll get a hang that browsers are weird and don't always bubble more esoteric events correctly. I wanted to be on the safe side and test with behavior of the lowest common (broken) denominator.
@moll Have you tried to run the same piece of code on iPad webdriver?
@p0deje I haven't. Would that make any difference? Wasn't the fire_event code custom anyways?
I'm guessing that would limit the UI tests to require a Mac as well.
@moll I just want to understand if iPad or Chrome does trigger keyup on pasting, that should probably be reported as a bug against WebDriver.
If one does Cmd+v I'd say triggering keyup is sensible as those keys were indeed pressed.
Yeah, but on iPad it doesn't make sense.
I agree. I doubt, too, that the iPad sends keyups. That's why I was looking for a way to trigger the paste event without triggering any other events or bubbling.
@moll I can't find where "bubble" was implemented for fire_event. Can you point me and so I could port to watir-webdriver?
Just older versions of Watir-WebDriver. Latest I could find now was element.rb in v0.2.3.
@jarib I'm going to get it back unless you have objections.
Perhaps with an options hash. (fire_event "paste", :bubble => false). Lone boolean values are hard to understand in code.
fire_event "paste", :bubble => false
@moll @jarib I doesn't seem that easy for me, because since watir now uses compiled Selenium atoms, I have to dig WebDriver events implementation and figure out what to do with them :) This will definitely take time.