Clearing timeouts upon destroy

[streamside]

trafficstars

An error is thrown if using a delay to open the drop but the the drop has been destroyed at the point in time when it us supposed to be opened/closed.

Example: The user hovers an icon, a setTimeout(open, 300) is created, something else happens which destroys the drop (calling destroy()), the 300 ms has passed and the drop now tries to open but it no longer exist and an error is displayed.

[wjt]

(I'm not a Drop developer, just a user who is seeing the same bug.)

This fix works for me: ace! Here's a minimal-ish test case which raises an exception without this fix and not with. Judging by other PRs and CONTRIBUTING.md you'll be asked to commit the result of running npm run build (so your changes are in dist/) and gulp version:patch to bump the patch version number.

[fromthemills]

Can we get this moving? Having trouble with same bug.

[ghost]

Bump, having a similar issue that this pull request would fix.

[Akryum]

Same here, waiting for this to be merged!

[zmdavis]

@streamside Any interest in bringing this up to date with the latest version?

Also, it would be nice to get some feedback from the maintainers on what's preventing this from being merged. As I mentioned in #169 a low-impact (but less precise) alternative would be to return early from the open (or close) function if this.drop is null.