Bug Tracker

Ticket #8485 (closed bug: plugin)

Opened 4 years ago

Last modified 4 years ago

Problem with bind() and some events in IE 9

Reported by: bit@… Owned by: bit@…
Priority: high Milestone: 1.next
Component: event Version: 1.5.1
Keywords: Cc:
Blocking: Blocked by:

Description

Example at  http://jsfiddle.net/38szJ/ When ran in IE 9 standards mode will alert "false" (wrong). When ran in IE 9 Compat view or IE 8 will alert "true" (right). Other browsers do now support this event so only IE is affected.

The bind() method uses feature detection to decide how to attach an event to an element. First it checks for "addEventListener" (DOM Events) and then "attachEvent" (IE specific implementation). IE 9 supports both "addEventListener" and "attachEvent" but IE 8 and bellow only support attachEvent.

The problem is that some IE specific events in IE 9 (e.g. onpropertychange -  http://msdn.microsoft.com/en-us/library/ms536956(v=vs.85).aspx ) must be added using "attachEvent" and NOT "addEventListener". Since the code in first checks for "addEventListener" and IE 9 supports that as well, IE specific events will not be registered correctly using bind().

Change History

comment:1 Changed 4 years ago by rwaldron

  • Keywords needsreview added
  • Owner set to bit@…
  • Status changed from new to pending
  • Component changed from unfiled to event
  • Priority changed from undecided to blocker

comment:2 Changed 4 years ago by rwaldron

  • Status changed from pending to open

comment:3 Changed 4 years ago by dmethvin

  • Priority changed from blocker to high
  • Status changed from open to pending

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.

comment:4 Changed 4 years ago by bit@…

  • Status changed from pending to new

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.

comment:5 Changed 4 years ago by bugventure@…

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.

comment:6 follow-up: ↓ 7 Changed 4 years ago by 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

comment:7 in reply to: ↑ 6 Changed 4 years ago by Bundyo

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

Replying to 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

comment:8 Changed 4 years ago by dmethvin

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.

comment:9 Changed 4 years ago by cowboy

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).

comment:10 Changed 4 years ago by dmethvin

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.

comment:11 Changed 4 years ago by dmethvin

  • Keywords needsreview removed
  • Status changed from new to closed
  • Resolution set to plugin

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.

Note: See TracTickets for help on using tickets.