Opened 6 years ago

Closed 4 years ago

#17249 closed defect (fixed)

Cannot call method 'apply' of null thrown on runner.run from fx.js

Reported by: lukevenn Owned by:
Priority: undecided Milestone: 1.8.11
Component: fx Version: 1.9.0
Keywords: Cc:
Blocked By: Blocking:

Description

If, in the onHide method, of a widget you destroy the widget then an error is thrown. If a delay of 1ms is added then no error is thrown. I've tracked it down to a change in fs.js where line 339 has been changed from a connect call to an aspect one. I've observed this in dojox.widget.Standby but not tested elsewhere.

Attachments (1)

bugtest.html (884 bytes) - added by lukevenn 6 years ago.
demonstration of bug using dojox Standby widget

Download all attachments as: .zip

Change History (7)

comment:1 Changed 6 years ago by bill

Owner: set to lukevenn
Status: newpending

Your description is rather vague as you didn't say which widget you are talking about, and I don't know what you mean by "runner.run".

Please attach a test case using the "attach file" button. It should be as small as possible to still reproduce the problem, almost always a single HTML file that we can load in the browser (i.e. not PHP, JSP, etc.).

Then, give exact instructions on how to reproduce the problem using your attached test file, including the browser and version to use.

The test case is necessary both to confirm that there's a bug, and for us to be able to debug the problem.

Alternately, you can give instructions on how to reproduce the problem with an existing test case (in the tests/ directory).

Thanks!

comment:2 Changed 6 years ago by lukevenn

Status: pendingnew

Attachment (bugtest.html) added by ticket reporter.

comment:3 Changed 6 years ago by lukevenn

To test, run the html test page in Chrome, FF or IE. After the timeout the Standby will hide and an error displayed in console.

Changed 6 years ago by lukevenn

Attachment: bugtest.html added

demonstration of bug using dojox Standby widget

comment:4 Changed 6 years ago by bill

Owner: lukevenn deleted
Status: newassigned

Thanks. Sorry, I didn't notice that you had mentioned dojox.widget.Standby in your original description. I looked at this for a while but the solution is not obvious to me. But here's what I found, FYI:

Since a473d97, dojo/_base/fx has a complex design where there's only one timer running. The timer periodically calls runner.run, ane each Animation latches on to runner.run via aspect.after(). I think Standby has multiple animations because of the combined animation between fading the underlay and the spinner.)

On one of those aspect.after() callbacks, Animation calls onHide(), which calls Standby.destroy(), which calls Standby.uninitialize(). Standby.uninitialize() calls this._anim.stop(), which calls Animation._stopTimer().

Animation._stopTimer() doesn't cancel the timer because it thinks that other animations are running. However, it does call this._timer.remove(), which should cancel the aspect.after(runner, "run", ...). But that remove() call isn't working correctly because the next time that runner.run() executes, there's an exception.

Maybe it's an issue with canceling some advice while in the handler for that advice,

var handle = aspect.after(foo, "bar", function(){ handle.remove(); });

Except, I tried a standalone test for that, and it worked:

var foo = { bar: function(){ console.log("bar"); } };
var aspect = require("dojo/aspect");
aspect.after(foo, "bar", function(){ console.log("first listener"); });
var handle = aspect.after(foo, "bar", function(){ console.log("second listener"); handle.remove(); });
aspect.after(foo, "bar", function(){ console.log("third listener"); });

// fire three listeners, remove the second listener
foo.bar();

// should work, only calling the first and third listener
foo.bar();

PS: A similar problem was fixed for dijit/Dialog in #12436, but perhaps that's a red herring.

Last edited 6 years ago by bill (previous) (diff)

comment:5 Changed 5 years ago by jmaner@…

We are seeing this error as well using Standbys. Is there any status on this bug? We would really like to see a fix for this included in a fixpack soon.

comment:6 Changed 4 years ago by bill

Milestone: tbd1.8.11
Resolution: fixed
Status: assignedclosed

Good news, this was fixed by 89034c5a611a061d456557bd84c08aed4e111674 (see #18637), and backported to 1.8.11.

Unfortunately #17253 remains broken.

Note: See TracTickets for help on using tickets.