Supporting the onMessage Event in MooTools

By  on  

Yesterday I threw some window.postMessage knowledge right in your face.  The cross frame/window/domain technology that is window.postMessage is really interesting and as IE6 and IE7 fade away, window.postMessage will gain more momentum.  In looking to listen to onMessage events with MooTools, I noticed that message events aren't  handled properly.  The event type is seen as message but the event.data, event.source, and event.origin aren't added to the main-level object -- they're relegated to event.event.  It's time to fix that using MooTools custom events.

The MooTools JavaScript

Element.NativeEvents.message = 2;
Element.Events.message = {
	base: 'message',
	condition: function(event) {
		//if(event.type == 'message') {
		if(!event.$message_extended) {
			event.data = event.event.data;
			event.source = event.event.source;
			event.origin = event.event.origin;
			event.$message_extended = true;
		}
		return true;
	}
};

Regardless of whether or not the event type is within the Element.NativeEvents.message object, its value always matches what's provided by the browser, minus the "on" prefix.  With that in mind, creating a "custom" message event with "message" as the base is the way to go.  The condition portion of the custom event is met by the type being "message," so the only check is that the event hasn't been handled already.  If the condition is met, I move references to the data, origin, and source to the event object's first level to mimic the tradition message event. As an added bonus, if existing properties are undefined, I set their value to false.

The power of custom MooTools events is awesome.  window.onMessage is rarely used due to IE6 and IE7's crap and the lack of use case so onMessage may not be worth adding the code to Core.  If you do, however, need this functionality...here you go!

Recent Features

  • By
    JavaScript Promise API

    While synchronous code is easier to follow and debug, async is generally better for performance and flexibility. Why "hold up the show" when you can trigger numerous requests at once and then handle them when each is ready?  Promises are becoming a big part of the JavaScript world...

  • By
    Page Visibility API

    One event that's always been lacking within the document is a signal for when the user is looking at a given tab, or another tab. When does the user switch off our site to look at something else? When do they come back?

Incredible Demos

  • By
    MooTools dwCheckboxes Plugin

    Update / Fix: The checkboxes will no longer toggle when the "mouseup" event doesn't occur on a checkbox. Every morning I wake up to a bunch of emails in my Gmail inbox that I delete without reading. I end up clicking so many damn checkboxes...

  • By
    MooTools Accordion: Mouseover Style

    Everyone loves the MooTools Accordion plugin but I get a lot of requests from readers asking me how to make each accordion item open when the user hovers over the item instead of making the user click. You have two options: hack the original plugin...

Discussion

  1. I was entirely confused why window.addEvent( 'message', function(event) { ... }) was not working.
    This plugin is exactly what I needed, and now I know about Element.Events. Thanks!

    I am confused by the code comment //if(event.type == 'message') { and your post The condition portion of the custom event is met by the type being “message,” so the only check is that the event hasn’t been handled already..

    Is it necessary to check the type of the event when using MooTools custom events?
    Or, on the other hand, can I just remove that comment?

  2. What is the purpose of setting undefined values to false?

    for(key in event) {
        if(event[key] == undefined) {
            event[key] = false;
    }
    

    This modifies, for example, the alt, client, page, relatedTarget properties of the event object.

Wrap your code in <pre class="{language}"></pre> tags, link to a GitHub gist, JSFiddle fiddle, or CodePen pen to embed!