Skip to main content

Bug Tracker

Side navigation

#8485 closed bug (plugin)

Opened March 09, 2011 01:55PM UTC

Closed April 22, 2011 01:42AM UTC

Problem with bind() and some events in IE 9

Reported by: bit@gbg.bg Owned by: bit@gbg.bg
Priority: high Milestone: 1.next
Component: event Version: 1.5.1
Keywords: Cc:
Blocked by: Blocking:
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().

Attachments (0)
Change History (11)

Changed March 09, 2011 02:42PM UTC by rwaldron comment:1

component: unfiledevent
keywords: → needsreview
owner: → bit@gbg.bg
priority: undecidedblocker
status: newpending

Changed March 09, 2011 02:43PM UTC by rwaldron comment:2

status: pendingopen

Changed March 10, 2011 03:12AM UTC by dmethvin comment:3

priority: blockerhigh
status: openpending

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.

Changed March 10, 2011 07:52AM UTC by bit@gbg.bg comment:4

status: pendingnew

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.

Changed March 10, 2011 11:47AM UTC by bugventure@gmail.com comment:5

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.

Changed March 10, 2011 03:57PM UTC by Bundyo comment:6

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

Changed March 10, 2011 04:16PM UTC by Bundyo comment:7

''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

Changed March 10, 2011 09:41PM UTC by dmethvin comment:8

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.

Changed March 30, 2011 07:47PM UTC by cowboy comment:9

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

Changed April 01, 2011 03:06AM UTC by dmethvin comment:10

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.

Changed April 22, 2011 01:42AM UTC by dmethvin comment:11

keywords: needsreview
resolution: → plugin
status: newclosed

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.