This project is archived and is in readonly mode.

#705 ✓ resolved
Neil Jenkins

No way to access native IE fireEvent method

Reported by Neil Jenkins | July 6th, 2009 @ 03:06 PM | in 1.3.0 rc2 (closed)

The fireEvent method defined in Element prevents access to the identically named native fireEvent.aspx "native fireEvent") method in Internet Explorer. Unfortunately, access to this is needed if you wish to fire events that will bubble up the DOM tree.

Possible solutions:
1. Keep access to the native method by adding code to rename any existing native methods when adding the mootools ones.
2. Rename the mootools fireEvent method to a non-conflicting name.
3. Alter the mootools fireEvent method or add a new one that simulates the bubbling of the event so access to this native method is no longer required.

Comments and changes to this ticket

  • Neil Jenkins
  • Sebastian Markbåge

    Sebastian Markbåge July 6th, 2009 @ 05:28 PM

    • State changed from “new” to “open”

    Yea, I've been drafting an alternative but it's not quite the same since events should continue to trigger even if one of them throws an error.

    http://gist.github.com/141076

  • Scott Kyle

    Scott Kyle September 4th, 2009 @ 03:38 AM

    • Assigned user set to “Sebastian Markbåge”
  • Fábio M. Costa

    Fábio M. Costa December 26th, 2009 @ 04:10 AM

    As talked on the mailing list, we could check for the name of the event to fire, if it starts with 'on' followed by a lower cased character and the element has the fireEvent method (that will be mapped for _fireEvent) it will fire the native fireEvent, something like this:

    function fireEvent(eventName, args, delay){
      if((/^on[a-z]/).test(eventName) && this._fireEvent) return this._fireEvent(eventName);
      the normal fireEvent code....
    

    I'm not sure if i understood the second parameter from the native fireEvent, so take a look at it guys, please.

    fireEvent's specification:
    http://msdn.microsoft.com/en-us/library/ms536423%28VS.85%29.aspx

  • Scott Kyle

    Scott Kyle December 26th, 2009 @ 05:31 AM

    Let's just go with option 1, storing the native method with an underscore. That line of code you have there Fabio, just wouldn't fly for Core.

  • Fábio M. Costa

    Fábio M. Costa December 26th, 2009 @ 02:50 PM

    Scott, the problem is that other scripts use fireEvent as if it was the ie's native fireEvent. Simply mapping it to _fireEvent won't solve the problem at all.

  • Neil Jenkins

    Neil Jenkins December 28th, 2009 @ 05:58 PM

    As the original reporter of this bug, I would say that simply mapping fireEvent to _fireEvent would be fine. Any page currently using an unaltered version of mootools can't be using the native IE event so you won't be breaking anything by making this change, but it allows future scripts to make use of it if necessary. I used to alter the core to do exactly this, but as a non-standard version is hard to maintain I rewrote the dependent method to simulate fireEvent rather than use the native IE version.

  • Fábio M. Costa

    Fábio M. Costa December 28th, 2009 @ 09:57 PM

    The problem is that IE8 lets you add stuff to the Element's prototype, so on IE8 the Mootools's fireEvent will overwrite the native's fireEvent (if we add stuff to Element.prototype on IE8, on 1.3). On IE6/7 simply mapping the method may work, but on IE8 it won't.

  • Sunny Hirai

    Sunny Hirai April 10th, 2010 @ 06:32 PM

    Are there any updates on this? I've written a unit tester that will allow me to do functional-like tests by simulating clicks and such. It works on all browsers except IE because I don't have access to the native fireEvent.

    Testing with simulated events seems like a good idea in general for MooTools since the tests currently require a lot of manual test running (i.e. "Is the rectangle draggable?") where it looks like most of it could be simulated easily for very fast testing on multiple browsers.

    In the meanwhile, is there a way for me to hack access to the original fireEvent in? Although I'm a little familiar with MooTools source code, I don't have the know-how to make this change myself, at least not at this moment.

    Any help would be greatly appreciated.

  • Sebastian Markbåge

    Sebastian Markbåge April 10th, 2010 @ 07:02 PM

    Here's a 1.2 commit showing a patch that can be used on custom MooTools builds to access the native fireEvent method through an underscored alias:

    http://github.com/calyptus/mootools-core/commit/4fe7821002bb80380ad...

  • Fábio M. Costa

    Fábio M. Costa April 10th, 2010 @ 07:27 PM

    You could do the same without changing mootools code like this:

    var fireEvent = Element.Prototype.fireEvent;
    delete Element.Prototype.fireEvent;
    Element.Prototype._fireEvent = fireEvent;
    

    Put this right after you include mootools on your site, and right before you start extending elements (using the $ or $$ or document.id functions).

    I havent tested it but it should work just fine.

  • Sebastian Markbåge

    Sebastian Markbåge April 10th, 2010 @ 07:45 PM

    That renames the MooTools fireEvent method to the underscore version which would break all the MooTools scripts. My example does the opposite.

  • Sunny Hirai

    Sunny Hirai April 10th, 2010 @ 11:41 PM

    Wow, thanks Sebastian and Fabio for the speedy response. I am doing a presentation on best practices for testing in my company on Monday and wanted to build the ability to unit test MooTools classes with a GUI. Feels like it will be possible now.

    Thanks again.

  • Christophe Demko

    Christophe Demko June 14th, 2010 @ 10:35 AM

    Hi Folks,

    Is this issue related to this one I found on Joomla!1.6 which uses mootools ?

    http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItem...

    I corrected this issue in ie7/ie8 by calling FireEvent with an uppercase

  • Christophe Demko

    Christophe Demko June 14th, 2010 @ 10:54 PM

    Sorry, I made a mistake in my comprehension of that issue.

  • Christoph Pojer

    Christoph Pojer September 5th, 2010 @ 02:32 AM

    • Milestone changed from 2.0 to 1.3.0 rc2
    • State changed from “open” to “resolved”
    • Assigned user changed from “Sebastian Markbåge” to “Christoph Pojer”
    • Milestone order changed from “0” to “0”

    In 1.3, if you do not include compat with 1.2, you will only get "triggerEvent". We are not going to overwrite fireEvent in future versions of MooTools.

  • ibolmo

    ibolmo November 27th, 2011 @ 05:02 PM

    • Milestone order changed from “1” to “0”

    Fixed in: https://github.com/mootools/mootools-core/pull/2138

    Should go out in 1.4.2.

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

Shared Ticket Bins

Pages