I'll re-read your response again later, but at first glance it looks like a long-winded way of saying "no"... :) Yes there might be a better/more complete possibility, and someone might do it in the future, but this patch looks better than what we have, and exists now. That seems like a good thing.
Or perhaps the "experimental" event simulations can be included, but in a separate file. But either way, if the experimental code isn't good enough, perhaps it should be removed then? I think I'd rather see an incremental fix now; AND wait for someone to write an even better version later. Nic On 2/4/08, Tobie Langel <[EMAIL PROTECTED]> wrote: > > > Hi Nic, > > I'd love to see this included directly in Prototype to allow for > Event.fire and Element#fire to trigger DOM events (and not only custom > ones). > > This would imply researching on how to trigger keyboard events (I know > YUI has a working implementation, for example), and providing a simple > wrapper around events like blur, focus and submit. > > Any thoughts or proposed implementation on this is welcomed. > > Best, > > Tobie > > > On Feb 4, 7:51 am, Dr Nic <[EMAIL PROTECTED]> wrote: > > Since the existing Event.simulateMouse code is labelled experimental, > > then this code with its suite of tests must be an improvement worth > > patching in? Even if it retains its "experimental" label, it will be > > an enhancement/bug fix patch for existing code. > > > > Whilst the ticket is categorised "script.aculo.us", it could be > > repatch against the prototype versions of unittest.js and the patch > > resubmitted if it will be accepted. > > > > Nic > > > > On Feb 4, 4:48 pm, Dr Nic <[EMAIL PROTECTED]> wrote: > > > > > [posted by kangax in Nov 07 with no responses at the time] > > > > > Hello team, > > > > > I recently needed a cross-browser simulateMouse support for some of > > > our tests in Prototype UI and stumbled upon certain limitations in > > > current implementation. Event.simulateMouse is marked as "Firefox-only > > > and experimental". Turning it into a somewhat robust solution will > > > definitely benefit other modules' test suits (notable autocompleter > > > and IPE which rely on mouse events quite heavily). > > > > > Thomas mentioned that any patches and tests are very appreciated, > > > considering that as of now there are NO specific unit tests for this > > > wonderful method. > > > > > Here's a fresh patchhttp://dev.rubyonrails.org/ticket/10170andunit > > > > testshttp://dev.rubyonrails.org/attachment/ticket/10170/simulatemouse_test... > > > (FF2+, IE6+, Opera 9+, Safari 3 all pass happily). Would be nice to > > > know about Safari 2 as well. The coverage is not as complete as I > > > would want it to be, but it's a good start and is better than nothing. > > > > > My question is: > > > What are the chances of applying it to the current version or would it > > > rather make sense to bake it into a 2.0? > > > > > best, > > > kangax > > > -- Dr Nic Williams http://drnicacademy.com - Ruby/Rails training/dev around the world http://drnicwilliams.com - Ruby/Rails/Javascript/Web2.0 (skype) nicwilliams (p) +61 412 002 126 / +61 7 3113 3033 (mail) PO Box 583 Ashgrove 4060 QLD Aus --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~----------~----~----~----~------~----~------~--~---
