Uncaught TypeError: Cannot read property 'handler' of undefined

[tpitale]

I've got a form, and when I click into a text field and type any key, I see an error coming from line 13076 of the latest download of ember.js Version: v1.0.0-pre.2-123-ga352c48.

Below is a video of the behavior. I'm not sure how to create a reduced example of this.

http://cl.ly/2w0C413I2E1H

Here is a gist of the stack trace, sorry it isn't well formatted: https://gist.github.com/4429286

The form handlebars template starts with this, in case it's relevant:

<form {{action commit target="view" on="submit"}} class="edit-problem form">

I did not see this behavior or error with Version 1.0.0-pre.2-2-g1e4bdd5

[wycats]

Are you using the new router?

[tpitale]

No.

[wycats]

If you're on master, you need to use the ember-old-router build then.

[tpitale]

I'm using the ember-latest.js from here: https://github.com/emberjs/ember.js/downloads

I have an app I've been building since before the router, and I've been trying to avoid using the router because maybe my app isn't "ambitious" enough. Do I need to bite the bullet and just figure out how make the transition?

[tpitale]

Where can I find the ember-old-router build? I'm not seeing a branch or tag with that name.

[wycats]

If you run rake dist from inside of the cloned repo, you should get an ember-old-router.js package.

That said, one of the goals of the new router branch was to make it extremely simple to use even if you don't have a particular ambitious use-case.

For example, if you don't define a router at all, Ember will just render the application template (for the conceptual / route), optionally using the App.ApplicationController and App.ApplicationView.

If you are using templates in your index.html, the unnamed <script type='text/x-handlebars'> is the application templates. So you're basically getting the simplicity of the 0.9.8 model with the ability to grow into a multi-page routable app when you need it.

[tpitale]

Okay, so yes, I'm using the new router, implicitly.

I have something like this in my html: https://gist.github.com/170650ed8dbbec21a66b So that's my Application view.

So I think my issue is still valid. Any tips on debugging it? I'm happy to do the digging.

[wycats]

@tpitale Can you gist the stack trace you're seeing? That would help me narrow it down.

[tpitale]

Here's the gist from the original issue. https://gist.github.com/4429286

Let me know if you need something more or something else entirely. Thanks @wycats!

[tpitale]

Here's a better formatted screenshot from chrome inspector: http://cl.ly/image/3l0v1P1K3T2b

[tpitale]

This backtrace appears to happen when a template changes the elements on the page at the same time it's trying to trigger handlers on it.

It was only arising from an issue in my code doing something ember does not like with changing templates. I've fixed the bug and all seems well.

[stefanpenner]

@tpitale just for reference, mind giving an example of the issue and how you resolved it?

[tpitale]

I have an index.html, for example. Inside, it switches between two views ProblemsEditView and ProblemsShowView depending on if the current problem in a controller isEditing or not.

What I want is that when submit on a form is clicked, for the form to be hidden if the instance of a problem is saved to the server, and to remain visible with errors if the problem triggers becameInvalid. This seems to be functioning fine using problem.on('didCreate', ...) and problem.on('didUpdate', ...) to trigger setting isEditing to false.

Unfortunately, the error remains, despite the form behaving as desired.

I hope that helps, @stefanpenner.

[tpitale]

Just looking at where the error is located, I think that it's looking for a click handler or something on the form's submit button, but because the submit button has been removed from the html when isEditing is set to false, it cannot find the element with jQuery.

Just an uneducated guess.

[tpitale]

I added some logging to the changes to Ember.Handlebars.ActionHelper.registeredActions[] where it's erroring and where actions are deleted. The logs look like this when it errors: http://cl.ly/image/2N3z1J3X3l3Y

Seems like when I hit "enter" to submit a form, the error occurs. But, if I click the Submit button on the same form, the error of lookup and deleting the registered action are reversed. Weird.

[stefanpenner]

Sorry, my bad, if you have also provide a jsfiddle, that would be great.

[tpitale]

I'm not sure if I can reproduce this particular application in order to demonstrate the issue in something as simple as a jsfiddle.

The core of the issue is in the registeredActions bit I described. I don't know enough about where that hooks into ember to create a simplified example. As I dig in more, maybe I'll puzzle it out.

[stefanpenner]

There is a good chance, once you decompose the problem into a fiddle that the solution will become obvious. if not, it will be a fantastic starting point for us to resolve. Either as a bug fix, or documentation update.

[tpitale]

I do understand the value of the fiddle. I think I also understand the problem and have described it as best I can. What prevents me from creating a fiddle with a snap of my fingers is a lack of complete understanding of the systems within ember at play.

In summary, I'm willing but unable to create a fiddle at this very moment. I will update when/if I take the time to dig in.

The problem is closed, and I have no expectation that anyone else will further investigate an error that isn't really causing any trouble.

[topherbullock]

We ran into the exact issue that @tpitale is describing.

It seems to be that a 'focusout' event fires on the submit button while the view is being destroyed, and thus all of Ember's actions are no longer contained in Ember.Handlebars.ActionHelper.registeredActions.

We've temporarily patched our Ember.EventDispatcher setupHandler method :

 rootElement.delegate('[data-ember-action]', event + '.ember', function(evt) {
       return Ember.handleErrors(function() {
         var actionId = Ember.$(evt.currentTarget).attr('data-ember-action'),
             action   = Ember.Handlebars.ActionHelper.registeredActions[actionId],
-            handler  = action.handler;
+            handler = null;
+    
+        if (typeof action !== "undefined" && typeof action.handler !== "undefined" && action.handler !== null) {
+          handler  = action.handler;
+        }

-        if (action.eventName === eventName) {
+        if (handler !== null && action.eventName === eventName) {
           return handler(evt);
         }
       }, this);
     });
   },

👍

https://github.com/xtreme-topher-bullock/ember.js/commit/74e0d58321bf2fa53a4a798580a63a3e1e545381

[gpoitch]

I also am encountering this problem. Like @xtreme-topher-bullock states, it is a problem with focusout attempting to be fired on a destroyed element.

I've reduced it to a simple case:

Here everything works as expected: http://jsfiddle.net/sSdHm/74/

Here the error occurs when simply adding a tabindex to the delete button: http://jsfiddle.net/sSdHm/75/

[stefanpenner]

@gdub22 awsome, thank you for the fiddle. I will try to look into this shortly.

[sandstrom]

(these two issues may be related: #1943, #1571)

[solojavier]

We are also experiencing this issue with a focus out event, @xtreme-topher-bullock proposed solution seems to work...

I could send a PR for this, but not sure how to create a test for it.

@stefanpenner Did you got a chance to look into this?

[solojavier]

Also could we reopen this bug?

[KrisHedges]

I can confirm that I get this issue when using ember-fastclick.js the easiest fix for me was to simply use an anchor tag instead of button for this particular action.