This is my first post of a type: "question", so bare with me...

I need to obtain a list of supported events on an encountered browser version programmatically, ie, via script.
Since Explorer exposes its events on document object I can do something as simple as this:

;for(x in document)if(/^on/.test(x))alert(x);

(!warning: long list ahead..., you can use the console.log(x) instead)
..and simply store them on some appropriate object for latter use in my program flow.

Is there a sort of hack or "a hidden corner" or whatever, that would enable us to build a list of events available on Firefox in a similar fashion?

Any idea will be greatly appreciated.

Thanks.

Dani AI

Generated

Short summary tied to the thread: wanted a way to enumerate the events supported by the current browser; pointed out event-detection helpers. Browsers differ in how (and where) they expose event-handler properties, so the practical solution is to probe element prototypes where possible and fall back to per-event tests when prototype enumeration is unavailable.

A reliable two-step approach:

  1. Walk the prototype chain of a representative element (default div), collect property names that start with on, strip the on prefix and deduplicate. This gives a compact, programmatic list without shipping a large hardcoded array.
  2. For cases where prototype inspection is blocked or incomplete, fall back to feature tests per name using the in operator and a safe attribute check on an element of the appropriate tag.

Example implementation (prototype scan + fallback):

function listSupportedEvents(tagName) {
  var el = document.createElement(tagName || 'div');
  var seen = Object.create(null);
  var proto = Object.getPrototypeOf(el);
  while (proto) {
    try {
      Object.getOwnPropertyNames(proto).forEach(function(n) {
        if (n.indexOf('on') === 0) seen[n.slice(2)] = true;
      });
    } catch (e) {
      break;
    }
    proto = Object.getPrototypeOf(proto);
  }
  Object.keys(seen).sort();
  return Object.keys(seen);
}

Fallback single-event test:

function isEventSupported(name, tag) {
  var el = document.createElement(tag || 'div');
  var prop = 'on' + name;
  if (prop in el) return true;
  el.setAttribute(prop, '');
  return typeof el[prop] === 'function';
}

Caveats and best practice: some events are tag-specific (test submit on a form, change on input), prototype inspection may be restricted in some environments, and creating an Event instance does not prove handler support. Cache results and prefer a small, explicit whitelist for production-critical behavior rather than relying solely on runtime enumeration.

Recommended Answers

All 3 Replies

Troy,

Have you found this:

allowing tests of the type isEventSupported("eventname") ?

isEventSupported won't, in itself, produce a list of events but might offer a way ahead.

Airshow

Thanks Airshow,
Yes I've ben looking at it... but couldn't deduce more than my already established fear that If I'm going to support other browsers as well, I'll be forced to hardcode the list by hand and use up an extra 1KB on a platform targeting a max 4KB.
Or leave it to the back end coder.

If the coder wants to have, say only the click event rewired and available for scripting with an "atevent" syntax on my "Discrete Event Model", let them choose to declare only those events they'll actually use on their current projects.

But again, having them programmatically available and by default is a better coder experience. Yet having a ~1KB long hardcoded list containing only event name declarations is just a little bit to much.

Your suggestion is good and pointing towards my aim but in inverse order.
The isEventSupported would be a nice tool if only I knew what event to check for. Unfortunately and comparatively simple, in Explorer, even this kind of task - when knowing what and where to look for - seems like a little piece of cake.
example:

isEventSupported =
	function(tag, event){
		return document.createElement(tag)[event]===null;
		};

usage:

alert( isEventSupported(“DIV”, “onclick”) ); //TRUE

Best Regards

UPDATE
THE GOOD NEWS IS: Firefox has finally taken (a beautiful) and a remarkable step forward in exposing a list of (event) properties on all DOM elements, which in turn makes firebug auto-complete feature very helpful and handy.

The BAD NEWS IS: latest Chrome release has restricted us from enumerating and seeing these properties on all but window object.

Anyway, now-on it is possible to use both given methods [exemplified above] in a cross-browser environment. (With noted restriction in mind, not to forget that this affects the most recent Safari too) therefore the checklist must be stripped at least from two main objects: document and window.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.