jQuery Callbacks disabled() Method

Beginner
⏱️ 8 min read
📚 Updated: Jul 2026
🎯 5 Examples
🚀 5 Try-it labs
Status check

What You’ll Learn

The disabled() method asks a simple question: has this Callbacks list been shut down with disable()? It returns true or false and does not change anything. This tutorial covers syntax, five examples, and how it pairs with disable(), locked(), and safe-fire patterns.

01

Syntax

callbacks.disabled()

02

Boolean

true / false

03

Read-only

No side effects

04

vs disable()

Check vs action

05

Guards

Before fire()

06

Plugins

Teardown checks

Introduction

jQuery Callbacks lists can be permanently shut down with disable(). After teardown, you often need to know whether firing is still allowed — especially in shared utilities, plugin APIs, or code that runs long after initialization.

That is what disabled() is for. It is a status query, not an action. Calling it never disables or enables the list; it only reports the current state.

Understanding the disabled() Method

callbacks.disabled() returns true if disable() has been called on that list, and false otherwise. On a brand-new $.Callbacks() object, it always starts as false.

The old misconception — treating disabled() as the way to turn callbacks off — is incorrect. The action method is disable(); disabled() only reads the result.

💡
Beginner Tip

Memory trick: disable() does the job; disabled() ends in “d” like “done?” or “decided?” — it answers whether shutdown already happened.

📝 Syntax

General form of callbacks.disabled:

jQuery
callbacks.disabled()

Parameters

  • None.

Return value

  • true if the list has been disabled; false if it is still active (never had disable() called).

Correct usage pattern

jQuery
const callbacks = $.Callbacks();



console.log(callbacks.disabled()); // false



callbacks.disable();



console.log(callbacks.disabled()); // true

⚡ Quick Reference

GoalCode
Check if list is offif (callbacks.disabled()) { ... }
Shut down a listcallbacks.disable()
Active list statusdisabled()false
After disable()disabled()true
Check if locked (different)callbacks.locked()

📋 disable() vs disabled()

Action method versus read-only status — do not swap them.

disable()
action

Permanently shuts down the list

disabled()
boolean

Returns whether shutdown happened

Side effect
yes / no

disable yes; disabled no

Reversible
no

Once true, stays true

Examples Gallery

Each example shows a different way to use the boolean returned by disabled().

📚 Getting Started

Default state on a new Callbacks object.

Example 1 — New List Returns false

A freshly created list is active until you call disable().

jQuery
const callbacks = $.Callbacks();



console.log("Disabled?", callbacks.disabled()); // false



callbacks.add(function () {

  console.log("Handler runs");

});



callbacks.fire(); // → Handler runs
Try It Yourself

How It Works

Until disable() runs, disabled() stays false and fire() works normally.

Example 2 — After disable() Returns true

Call disable() first, then check status — not the other way around.

jQuery
const callbacks = $.Callbacks();



callbacks.add(function () {

  console.log("Callback 1 executed");

});



callbacks.add(function () {

  console.log("Callback 2 executed");

});



callbacks.fire();

// → Callback 1 executed

// → Callback 2 executed



callbacks.disable();

console.log("Disabled?", callbacks.disabled()); // true



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

How It Works

This corrects the old reference mistake: disabled() does not disable anything — disable() does, and then disabled() reports true.

📈 Practical Patterns

Guards, plugin checks, and comparisons with other status methods.

Example 3 — Guard Before fire()

Skip firing and log clearly when the list is already shut down.

jQuery
function safeFire(callbacks, args) {

  if (callbacks.disabled()) {

    console.warn("Callbacks list is disabled — skipping fire");

    return;

  }

  callbacks.fire.apply(callbacks, args);

}



const hooks = $.Callbacks();

hooks.add(function (msg) { console.log("Hook:", msg); });

hooks.disable();



safeFire(hooks, ["late call"]);

// → Callbacks list is disabled — skipping fire
Try It Yourself

How It Works

fire() on a disabled list is harmless but silent. An explicit guard improves debuggability in shared code paths.

Example 4 — Plugin Exposes Status

Let consumers ask whether hooks are still live before subscribing.

jQuery
const AppBus = (function () {

  const events = $.Callbacks();



  return {

    on: function (fn) {

      if (events.disabled()) {

        console.log("Cannot subscribe — bus disabled");

        return;

      }

      events.add(fn);

    },

    emit: function (data) { events.fire(data); },

    shutdown: function () { events.disable(); }

  };

})();



AppBus.on(function (d) { console.log("Got:", d); });

AppBus.emit("hello");     // → Got: hello

AppBus.shutdown();

AppBus.on(function () {}); // → Cannot subscribe — bus disabled
Try It Yourself

How It Works

Wrapping disabled() inside your public API gives callers a clear signal instead of silently ignoring add() after teardown.

Example 5 — disabled() vs locked()

These status methods answer different questions about the same list.

jQuery
const locked = $.Callbacks();

locked.lock();

console.log("locked:", locked.locked());     // true

console.log("disabled:", locked.disabled()); // false



const disabled = $.Callbacks();

disabled.disable();

console.log("locked:", disabled.locked());     // false

console.log("disabled:", disabled.disabled()); // true
Try It Yourself

How It Works

locked() means the handler queue is frozen. disabled() means firing is permanently off. They are independent states.

🚀 Use Cases

  • Defensive fire helpers — skip or warn when a list is already disabled.
  • Plugin public API — expose isDestroyed() backed by disabled().
  • Unit tests — assert teardown called disable() by expecting disabled() to be true.
  • Conditional UI — hide “Subscribe” buttons when the event bus is off.
  • Debugging — log list state when mysterious silent no-ops occur.

🧠 How disabled() Fits the Lifecycle

1

Create list

$.Callbacks()disabled() is false.

Active
2

disable()

Shutdown action runs — firing stops permanently.

Action
3

disabled()

Status check returns true; no state change.

Query
=

Informed code paths

Callers know the bus is dead before they subscribe or fire.

📝 Notes

  • disabled() is read-only — it never disables or enables the list.
  • Use disable() for the shutdown action; use disabled() to test the result.
  • Once disabled() returns true, it stays true for that object.
  • Do not confuse with locked(), which tracks lock() instead.
  • fire() on a disabled list is safe but silent — guards are optional but helpful.

Browser Support

callbacks.disabled() is part of jQuery’s Callbacks API since jQuery 1.7. It is available wherever jQuery runs.

jQuery 1.7+

jQuery Callbacks.disabled()

Supported in jQuery 1.x, 2.x, and 3.x. Returns a boolean consistently across browsers.

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.disabled() Universal

Bottom line: Safe in jQuery projects. Pair with disable() — action first, status check second.

🎉 Conclusion

The callbacks.disabled() method answers one question: has this list been shut down? It returns a boolean and never changes state. Use disable() to turn firing off, then disabled() to verify teardown or guard shared fire helpers.

Next, explore empty() to clear handlers while keeping the list active, or review lock() / locked() for a different kind of freeze.

💡 Best Practices

✅ Do

  • Call disable() for shutdown, disabled() to check
  • Guard shared fire() helpers with disabled()
  • Expose status in plugin destroy APIs
  • Assert disabled() in teardown tests
  • Distinguish from locked() in docs

❌ Don’t

  • Use disabled() expecting it to disable the list
  • Assume disabled() toggles or re-enables
  • Confuse it with disable() in examples
  • Expect true after lock() alone
  • Skip disable() and only check status

Key Takeaways

Knowledge Unlocked

Five things to remember about disabled()

Read-only status for Callbacks lists.

5
Core concepts
T/F 02

Boolean

true / false

Return
🚫 03

disable()

Sets true

Action
🔒 04

locked()

Different flag

Compare
🛡 05

Guard

Before fire

Pattern

❓ Frequently Asked Questions

disabled() is a read-only status check. It returns true if disable() was called on the list, otherwise false. It does not disable anything itself — use disable() for the action.
disable() is the verb — it permanently shuts down the list. disabled() is the question — "is this list shut down?" It returns a boolean and leaves the list unchanged.
On a freshly created $.Callbacks() list, and on any list that has never had disable() called. Active lists that still accept fire() return false.
No. disabled() only reads state. jQuery provides no enable() method. Once disable() runs, disabled() stays true forever for that list object.
fire() on a disabled list is already a safe no-op, but checking disabled() first can avoid pointless calls and produce clearer logs in shared utilities or plugin code.
disabled() reflects whether disable() was called. locked() reflects whether lock() was called — a different state. A list can be locked but not disabled, or disabled (which also clears internal state).
Did you know?

jQuery names the pair consistently: disable() / disabled(), lock() / locked(), and fire() / fired() — action method plus past-tense status check.

Continue to empty()

Learn how to remove all handlers while keeping the list fireable.

empty() 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