Opened 13 years ago
Closed 12 years ago
#6121 closed bug (fixed)
data function no longer works with OBJECT elements
Reported by: | stephenp | Owned by: | |
---|---|---|---|
Priority: | undecided | Milestone: | 1.4.3 |
Component: | data | Version: | 1.4.2 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
In 1.4, setting data on an OBJECT tag (like a Flash element), doesn't do a thing due to the addition of a "noData" object in the library. It worked fine in 1.3.x.
This is a breaking change and I'm not sure why it's necessary. This busted two of my plugins.
Attachments (2)
Change History (7)
comment:1 Changed 13 years ago by
Component: | unfiled → data |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
Changed 13 years ago by
Attachment: | 6121patch.js added |
---|
comment:2 Changed 13 years ago by
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
I have created a simple patch that restores data() support for Flash objects, while forbidding support for other applets. It also offers more flexibility than the current noData approach, which would allow someone to easily add data() support for, say, Silverlight outside of the framework.
Flash object tags always have the same classid attribute. So it's reasonably safe to hard code it. However, if this is something the team isn't cool with, I recommend keeping my patch and just changing noDataElems to
noDataElems: {
"embed": true, "object": true, "applet": true
}
Then plugins can simply override that value and add custom functions to give data() support for their desired elements.
comment:3 Changed 13 years ago by
My proposed noData function can be further compacted into:
noData: function(elem) {
var isBanned = jQuery.noDataElems[elem.nodeName.toLowerCase()]; return !isBanned ? false : (jQuery.isFunction(isBanned) ? isBanned(elem) : true);
}
It's your call on that one.
comment:4 Changed 13 years ago by
Also, should we perhaps throw an error by default for this case? If the patch was adopted the developer could override the throw and go back to silent fail.
comment:5 Changed 12 years ago by
Milestone: | 1.4.2 → 1.4.3 |
---|---|
Priority: | → undecided |
Resolution: | → fixed |
Status: | reopened → closed |
Version: | 1.4.1 → 1.4.2 |
Yep, that's intentional. We can't reliably bind data to object elements without the potential for un-catchable exceptions from occurring. The problem is that when we attach our expando to the object element it's going directly in to the internal plugin - frequently (as is the case with java applets) an uncatchable exception will be thrown that we can't work around. It is a huge bummer but having applications crash was a bigger bummer.