jQuery Callbacks disable() Method

Beginner
⏱️ 9 min read
📚 Updated: Jul 2026
🎯 5 Examples
🚀 5 Try-it labs
List control

What You’ll Learn

The disable() method permanently shuts down a jQuery Callbacks list so fire() no longer runs handlers. This tutorial covers syntax, five worked examples, how disable() differs from lock(), and when to use it during plugin teardown.

01

Syntax

callbacks.disable()

02

Permanent

No re-enable

03

fire()

Becomes no-op

04

vs lock()

Different role

05

disabled()

Status check

06

Teardown

Plugin destroy

Introduction

A jQuery Callbacks list collects functions you trigger with fire(). Sometimes that list should stop forever — when a widget is destroyed, a page unloads, or a one-time workflow must never repeat. The disable() method is jQuery’s built-in “off switch” for the entire list.

After disable(), calling fire() does nothing: no handlers run, no errors throw. The change is permanent — jQuery does not ship an enable() method. Plan accordingly.

Understanding the disable() Method

callbacks.disable() takes no arguments and returns the same Callbacks object for chaining. Internally, jQuery marks the list as disabled and tears down the internal queue so future fire() calls exit immediately.

Do not confuse disable() with a pause button. It is teardown, not suspension. For a reversible pause, track your own boolean flag and skip fire() in application code, or simply stop calling fire().

💡
Beginner Tip

Use disabled() to test whether a list is already off before calling fire() in shared utility code — especially after plugin destroy hooks.

📝 Syntax

General form of callbacks.disable:

jQuery
callbacks.disable()

Parameters

  • None.

Return value

  • Returns the Callbacks object (chainable), though further operations on a disabled list have no effect.

Basic pattern

jQuery
const callbacks = $.Callbacks();



callbacks.add(function () {

  console.log("Callback 1");

});



callbacks.add(function () {

  console.log("Callback 2");

});



callbacks.disable();



callbacks.fire(); // no output — list is disabled

⚡ Quick Reference

GoalCode
Shut down a listcallbacks.disable()
Check if disabledcallbacks.disabled()true
Fire while activecallbacks.fire()
Freeze list, still firecallbacks.lock()
Clear handlerscallbacks.empty()

📋 disable() vs lock()

Both control Callbacks lists, but they solve different problems.

disable()
no fire()

Permanent shutdown — handlers never run again

lock()
no add()

Freezes queue — fire() still works

disabled()
boolean

Read-only status after disable()

Reversible?
neither

No enable()/unlock() in jQuery

Examples Gallery

Each example shows a different aspect of disable(). Use the Try-it links to run them in the browser.

📚 Getting Started

Disable before firing — handlers never execute.

Example 1 — Disable Before fire()

Register handlers, call disable(), then try to fire — nothing runs.

jQuery
const callbacks = $.Callbacks();



callbacks.add(function () {

  console.log("Callback 1");

});



callbacks.add(function () {

  console.log("Callback 2");

});



callbacks.disable();

callbacks.fire(); // no output
Try It Yourself

How It Works

Handlers were registered, but disable() ran before fire(), so the invocation queue is dead.

Example 2 — Disable After a Successful fire()

The first fire() runs normally; after disable(), later fires are ignored.

jQuery
const callbacks = $.Callbacks();



callbacks.add(function () {

  console.log("Runs once");

});



callbacks.fire();

// → Runs once



callbacks.disable();

callbacks.fire(); // ignored
Try It Yourself

How It Works

Useful when a widget fires a final “destroyed” event, then disables its internal bus so stray calls cannot trigger handlers again.

📈 Practical Patterns

Status checks, comparisons, and real teardown flows.

Example 3 — Guard With disabled()

Check status before firing in shared helper code.

jQuery
const callbacks = $.Callbacks();



function safeFire(list, args) {

  if (list.disabled()) {

    console.log("Skipped — list disabled");

    return;

  }

  list.fire.apply(list, args);

}



callbacks.add(function () {

  console.log("Handler");

});



callbacks.disable();

safeFire(callbacks, []);

// → Skipped — list disabled
Try It Yourself

How It Works

fire() on a disabled list is already safe (no-op), but an explicit guard produces clearer logs and avoids pointless calls in hot paths.

Example 4 — disable() vs lock() Side by Side

lock() still fires; disable() does not.

jQuery
const locked = $.Callbacks();

locked.add(function () { console.log("locked: fired"); });

locked.lock();

locked.fire(); // → locked: fired



const disabled = $.Callbacks();

disabled.add(function () { console.log("disabled: fired"); });

disabled.disable();

disabled.fire(); // no output
Try It Yourself

How It Works

Choose lock() when the handler set is final but you still need to fire. Choose disable() when firing must stop entirely.

Example 5 — Plugin Teardown

Disable the onDestroy hook list when a jQuery plugin is removed from the DOM.

jQuery
const Widget = (function () {

  const onDestroy = $.Callbacks();



  function destroy() {

    onDestroy.fire("destroying");

    onDestroy.disable();

    console.log("Widget torn down, hooks disabled");

  }



  return { onDestroy: onDestroy, destroy: destroy };

})();



Widget.onDestroy.add(function (phase) {

  console.log("Cleanup:", phase);

});



Widget.destroy();

Widget.onDestroy.fire(); // no-op — already disabled
Try It Yourself

How It Works

Fire a final cleanup event for subscribers, then disable() so late code cannot accidentally trigger destroyed-widget logic.

🚀 Use Cases

  • Plugin destroy — shut down internal Callbacks lists when a widget unmounts.
  • One-time workflows — disable after a migration or init routine completes.
  • Error containment — disable a bus after a fatal error to prevent cascading handlers.
  • Testing — verify that code respects disabled() and does not expect re-enable.
  • Memory hygiene — release callback references when a SPA route tears down.

🧠 How disable() Works

1

Active list

Handlers are registered with add() and run via fire().

Normal
2

disable()

jQuery marks the list disabled and clears internal firing state.

Shutdown
3

fire() no-op

Further fire() / fireWith() calls return immediately.

Silent
=

Safe teardown

Stray fires after destroy cannot wake dead handlers.

📝 Notes

  • disable() is permanent — there is no built-in enable().
  • Not the same as lock(), which blocks add()/remove() but still allows fire().
  • After disable, add() in jQuery 3.7+ has no effect on the cleared internal list.
  • disabled() returns true after shutdown — use it for defensive checks.
  • To wipe handlers but keep the list active, use empty() instead of disable().

Browser Support

callbacks.disable() is part of jQuery’s Callbacks API, available in jQuery 1.7+. It behaves consistently wherever jQuery runs.

jQuery 1.7+

jQuery Callbacks.disable()

Supported in jQuery 1.x, 2.x, and 3.x across all browsers that run your jQuery build.

100% With jQuery loaded
Google Chrome All versions · Desktop & Mobile
Full support
Mozilla Firefox All versions · Desktop & Mobile
Full support
Apple Safari All versions · macOS & iOS
Full support
Microsoft Edge All versions · Chromium & Legacy
Full support
Internet Explorer IE 6+ · Legacy environments
Full support
Opera All modern versions
Full support
callbacks.disable() Universal

Bottom line: Safe in jQuery-based projects. Remember: disable is one-way — plan teardown carefully.

🎉 Conclusion

The callbacks.disable() method permanently stops a Callbacks list from firing. Use it for plugin destroy hooks and final shutdown — not as a temporary pause. Pair it with disabled() when shared code needs to check list status.

Next, learn disabled() in detail, then explore lock() for the opposite concern: freezing handler registration while still allowing fires.

💡 Best Practices

✅ Do

  • Call disable() during plugin destroy methods
  • Fire a final event before disabling when subscribers need notice
  • Check disabled() in shared fire helpers
  • Document that disable is irreversible
  • Use empty() if you only need to clear handlers

❌ Don’t

  • Treat disable() as a pause/resume toggle
  • Confuse it with lock()
  • Expect add() to revive a disabled list
  • Disable lists other modules still rely on
  • Forget to test post-destroy fire() paths

Key Takeaways

Knowledge Unlocked

Five things to remember about disable()

Permanent off switch for Callbacks lists.

5
Core concepts
02

Permanent

No enable()

One-way
03

fire()

Becomes no-op

Silent
🔒 04

vs lock()

Different job

Compare
? 05

disabled()

Status check

Next

❓ Frequently Asked Questions

disable() permanently shuts down a Callbacks list. After calling it, fire() and fireWith() become no-ops — they return immediately without invoking any handlers. Use it when an event bus or plugin hook should never run again.
No. jQuery provides no enable() method. disable() is one-way. If you need to pause and resume firing, keep a boolean flag in your own code or create a fresh $.Callbacks() list instead.
lock() freezes the list contents — no more add() or remove() — but fire() still runs handlers. disable() prevents all future firing. lock() protects the queue; disable() kills it.
In jQuery 3.7+, disable() clears internal list state. Subsequent add() calls are silently ignored because there is no active list to append to. Treat disable() as final teardown.
Call disabled() — it returns true after disable() has run. That is the read-only status check; disable() is the action that turns firing off.
Common cases: plugin destroy/unmount, cancelling an event bus after app shutdown, or guarding against duplicate fires once a one-time workflow completes. Pair with disabled() in defensive code paths.
Did you know?

jQuery has no enable() counterpart to disable(). If you need a fresh start, create a new list with $.Callbacks() rather than trying to revive a disabled one.

Continue to disabled()

Learn how to test whether a Callbacks list has been shut down.

disabled() tutorial →

About the author

Mari Selvan M P
Mari Selvan M P 🔗

Developer, cloud engineer, and technical writer

  • Experience 12 years building web and cloud systems
  • Focus Full Stack Development, AWS, and Developer Education

I write practical tutorials so students and working developers can learn by doing—from databases and APIs to deployment on AWS.

6 people found this page helpful