Can you provide some context as to why you want to handle this event in jQuery, since it only applies to IE? Are you writing an IE-specific web page?

I'm inclined to close the ticket wontfix since you can wire up a fix yourself using attachEvent and it's not a standard event.

I am writing a component that needs to act when a certain invisible element is shown (e.g. style.display="block"). To do this for IE/FF I attach to "propertychange" and "DOMAttrModified" respectively and check if the style/class was changed. Since this is a 3rd party component, there is no way to handle the element visibility change from other code. Naturally, all was OK before IE 9.

Simply looked from a jQuery point of view, you used to be able to attach to proprietary events (like "onpropertychanged") in IE using .bind() and now you won't in IE9. That fact alone justifies a fix in .bind() that will take IE9's behavior into consideration.

ondragstart is one of the events that do not work in IE9 with bind(). Reversing the check (and adding check for Opera) fixes it.

Check the note in MSDN, seems ondragstart creates different event objects depending on the way you add it:

http://msdn.microsoft.com/en-us/library/ms536928%28VS.85%29.aspx

''Scratch that, this is not really a problem with bind(), more so with event checking after.''

Replying to [comment:6 Bundyo]:

ondragstart is one of the events that do not work in IE9 with bind(). Reversing the check (and adding check for Opera) fixes it. Check the note in MSDN, seems ondragstart creates different event objects depending on the way you add it: http://msdn.microsoft.com/en-us/library/ms536928%28VS.85%29.aspx

Simply looked from a jQuery point of view, you used to be able to attach to proprietary events (like "onpropertychanged") in IE using .bind() and now you won't in IE9. That fact alone justifies a fix in .bind() that will take IE9's behavior into consideration.

Well it seems that's because IE9 didn't want to carry over their non-standard onpropertychange event. That was probably the right move, although it sure would have been nice if they implemented DOMAttrModified on addEventListener at the same time.

To outline what I think it would take to completely support onpropertychange we'd need to:

• Figure out a feature detect for this problem, since it only affects IE9.
• Add code to detect "propertychange" as the event name and take a different path using attachEvent if the feature detect says we should.
• For propertychange events on IE9 ONLY, re-instate the IE workaround for the problem where attachEvent copies events when elements are cloned. When events of other types are attached to the same element, we would need to sort that out ... somehow.
• Special-case propertychange event removal as well.

Given how rarely this is used, I still think the plugins/code that need it should pay the tax rather than bake a huge bunch of special-case code into jQuery core.

Using the jQuery special events API you can create a custom "DOMAttrModified" event that uses DOMAttrModified under the hood if the event exists, otherwise falls back to the propertychange event (or anything else you need it to).

I agree with ben/cowboy that it might be best to fake DOMAttrModified on IE using a special event, it sounds like that is what the original reporter was trying to do. Not sure about how well the two correspond though.

Per the discussion above, this would be best addressed by a special event handler. It's not a common enough case for us to include in core.