jquery: Breaking change to the data module in 3.5.0

jQuery 3.5.1 has been released: https://blog.jquery.com/2020/05/04/jquery-3-5-1-released-fixing-a-regression/

21 days jquery maintainers can’t release hot fix for fixing problem with bootstrap. Leaving all bootstrap users with decision “security fix” vs “working bootstrap”.

Guys, please. Pretty please. Release the fix.

I was hoping for an ETA, but I suppose I’ll just assume “soon”-ish. (Btw, the “E” in “ETA” doesn’t stand for “Exact”, but “Estimated”.) Can’t wait to see the fix in the wild. Thanks!

@mgol This issue should not be closed with a simple “Downgrade to 3.4.1” - Many of us are being asked by our companies to perform a mandatory upgrade because of the XSS vulnerability in < 3.5. Further, downgrading doesn’t fix the problem in 3.5 - it just avoids it.

This change in 3.5.0 (and 3.5.0.1) affects numerous other libraries, including Bootstrap 4.x. Can we get some sort of ETA on an actual fix?

Bootstrap 3.4.1 which Tooltip.prototype.getOptions which has hasOwnProperty and it is failing with jquery 3.5.0

PR: #4666

I guess this is why linters say to use Object.prototype.hasOwnProperty.call(obj, 'foo')

It’s customary to close an issue on GitHub when a fix is merged, not when it’s released. The release should happen soon but I cannot provide you an exact date.

jQuery built from 3.x-data-object branch seems to fix the issue with Bootstrap Select https://github.com/snapappointments/bootstrap-select/issues/2430

@XhmikosR Not this issue, this issue we’ll fix, most likely by reverting the change to src/data/Data.js from 9d76c0b163675505d1a901e5fe5249a2c55609bc.

The PR you linked to also applies updates for the changes to jQuery.htmlPrefilter and those will not be reverted so it’s likely Bootstrap v3 code will remain incompatible with jQuery 3.5.0+ by default. The htmlPrefilter issue can be worked around by developers using Bootstrap 3 with jQuery 3.5.0+ via one of the steps outlined in https://jquery.com/upgrade-guide/3.5/ that restore jQuery.htmlPrefilter to it’s pre-3.5.0 value.

We’ll monitor the situation. If we get info about many more projects broken by this change, we’ll try to get the fix out quicker. No promises about specific timing, though: it’s Easter and we’re all volunteers.

Any chance on quick 3.5.1 release?

The jQuery team only maintains the jquery npm & Bower packages, the rest is done by the community. You need to ask the Nugget package maintainer to release the updated version.

Dependabot is sending announcements out to every public repo that uses JQuery 3.4 with an automatic pull request to upgrade to 3.5. I expect lots of people will simply accept the PR.

[image: image.png]

On Thu, Apr 30, 2020 at 1:17 PM PaulKahl notifications@github.com wrote:

This issue should not be closed with a simple “Downgrade to 3.4.1” - Many of us are being asked by our companies to perform a mandatory upgrade because of the XSS vulnerability in < 3.5. Further, downgrading doesn’t fix the problem in 3.5 - it just avoids it.

This change in 3.5.0 (and 3.5.0.1) affects numerous other libraries, including Bootstrap 4.x. Can we get some sort of ETA on an actual fix?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jquery/jquery/issues/4665#issuecomment-621988809, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEXIQJUDYU4CKW22ISKMX3RPGXCRANCNFSM4MF6QFQQ .

@boris-petrov yeah, no other code seems to be affected from the other changes AFAICT; our CI passes.

@Johann-s please have another look in case I missed something.

I was thinking about it a bit more, my conclusions:

1. I was focused on all the changes from commit 9d76c0b163675505d1a901e5fe5249a2c55609bc but the change to events should actually be fine. This is because the only way you can get ahold of it is via the private jQuery._data API which is private so if you use it, you’re on your own. I’ll note it’s fine for web browsers to use it as it’s just for use in DevTools; if it breaks, no website will be broken, the debugging experience will just be worse until the browser catches up.
2. If we changed the events internal structure from a prototype-less object with regular event type keys to a regular object with keys with a space appended, it has a potential to break more code than the change to a prototype-less object. Although, from my testing it looks like both approaches work in both Firefox & Chrome.

Because of the above, I’d only revert the data change, deferring it to jQuery 4.0.0. PR incoming.

So, basically the failures can be seen here where I updated jQuery to v3.5.0 and adapted our tests: CI errors

The code is quite old, since our v3.3.4.

Thanks for the report. I agree this is an unintended breaking change that we should fix in 3.5.1. Marking for team discussion.

Perhaps we can leave the current solution for jQuery 4.0.0 and in 3.5.1 apply original @gibson042’s suggestion of appending a space to event names before storing in the internal data storage. This solution can break code that relied on the private jQuery._data API to have real event names as event keys without any space at the end but since it’s a private API, this looks more acceptable to me.

Some possible consumer are web browsers, I think Firefox is using this API for jQuery event support in DevTools. If that’s still the case, do you know, @bzbarsky, who at Mozilla we could contact to coordinate any changes to this API?