Update to jQuery UI 1.9

I too want this, as I've been testing my drupal site in IE9 and the jquery does not even load on the older version!

We need to update Drupal 8 first. If that this is something we can backport from D8 to D7 we can address it after its in Drupal 8. If you want 1.5.1 in Drupal 7 I would start with the jquery_update module (7.x-2.x-dev).

The attached patch updates core to jQuery 1.5.1 and jQuery UI 1.8.11.

Some things still need to be updated (jQuery Form for instance) and some things need to be fixed (autocomplete).

On the IE9 front, jQuery 1.4 and 1.5.1 work in IE9. jQuery 1.5 is the version with an issue in IE9.

Updating jQuery Form fixed the autocomplete problem. Seems all of these should be updated together. Testing welcome.

This patch...

• Hits system_library() with the new version numbers
• Updates jQuery Cookie as well as it's shipped with jQuery UI (100644 is the git commit number)

I tested the Overlay popup, Toolbar sticking, and autocomplete. It's looking pretty good.

Is there a testing plan somewhere? Or how should we test this as this version, has a totally different ajax system...

I believe mfer's checklist at JavaScript Tests still applies. Is there anything in the 1.5's new AJAX system that we could take advantage of?

subscribing

Thanx for linking to that list of js tests Rob ;)

Do you happen to know if they are included in the simpletest set or if there's an issue filed somewhere for that? This would help so they can be auto-run against every new version of core instead of the need of us doing it manually each time. Then we wouldn't have to set the patches here to 'ignored'. Right?

@klonos simpletest cannot currently test dynamic functionality within a page. These need to be tested by hand.

Didn't know that Matt. Thanx for taking the time to explain.

subscribing. I could help to do test on real machines. really hope that we could port jQuery new version back to D7.

@droplet: It will most likely just be supported in Drupal 7 via http://drupal.org/project/jquery_update . But testing with that doesn't hurt either! :-)

@Rob,

Thanks. Yes. I'm already using it at almost same time of D7 is released.(jQuery 1.5.x was released a few day after D7 if my memory is not wrong.)

if it never port back to D7, I will postpone myself to help to do test because jQuery 1.6 is coming. they move forward very quickly. :)

Seeing if posting a comment will cause review.

subscribing

Subscribe.

1.5.2 released.

jQuery 1.6 Beta 1

...btw, instead of chasing jQuery as new releases come out perhaps we should simply get Libraries in core and let it handle updates. I mean this way a site could simply upgrade to newer versions of jQuery and test if things work as before. If something breaks in a new version, they simply file an issue and revert to the previous working version till the issue is resolved.

Was there an issue for that (either in core's or in the module's issue queue)?

Libraries module is far from being able to handle library updates automatically, in the fashion of the Drupal 7 Update manager, for example. There are a billion things to flesh out, still.

And even while that would be an awesome addition for core, we should still try to ship with the latest possible release, to give people the most current library stack out of the box.

Libraries module is far from being able to handle library updates automatically... There are a billion things to flesh out, still.

I agree Tobias, but D8 is far from being released. So I guess we have time to implement libraries auto-updates -if needed- plus sort those billion issues you mention in the meantime too ;)

...Actually I was not referring to automatic updates at all. I was thinking that perhaps we can give the option to people to be able to *easily* upgrade jQuery versions manually, by simply downloading directly from jquery.com, (re)placing files in their setup and testing things out -without having to wait for the next stable version of Drupal core that includes the updated jQuery version or to keep up with a contrib module-. If not working or things break after the upgrade, then they could revert to either the default version that came with their version of core, or to any jQuery version they have previously upgraded to and worked for them. I was talking about having the ../sites/all/libraries/ directory pre-created with core (the same way ../sites/all/modules/ & ../sites/all/themes/ are there out-of-the-box) + make core aware of that 'central libraries repository'. Eventually, move all core external libraries under that directory (or a 'libraries' directory straight under root, where core themes and modules reside too).

I am aware of the fact that the version of jQuery that ships with core is not 'vanilla' and needs some minor customization in order to play nicely with drupal, but I am confident that we'll figure out a solution and we will somehow overcome this, eventually.

... And even while that would be an awesome addition for core, we should still try to ship with the latest possible release, to give people the most current library stack out of the box.

I agree here too. I wasn't thinking of replacing or removing core functionality or features that ship out-of-the-box already. I rather suggest to supplement it by allowing the shipped-with-core libraries to be *easily* overridden by custom versions. That would reduce the need to ship a new version of Drupal each time there is a new (minor) version of jQuery.

Bottom line is that since we -as a community- seem to basically agree that:

- projects like CCK and Views are used in say 99% (percentage might be exaggerated in order to make my point) of the setups and belong in core,
- projects like media, WYSIWYG and jQuery libraries (that is based in Libraries btw) should be the way to handle respective features in order to avoid duplicate/similar projects havoc + concentrate efforts/power in one place,

...then, I think that Libraries should be in core and should be the basis of eventually solving this issue here too.

...Actually I was not referring to automatic updates at all. I was thinking that perhaps we can give the option to people to be able to *easily* upgrade jQuery versions manually, by simply downloading directly from jquery.com, (re)placing files in their setup and testing things out -without having to wait for the next stable version of Drupal core that includes the updated jQuery version or to keep up with a contrib module-.

What about using CDNs for javascript library ? Auto-update becomes ridiculously easy then...

It's not just shipping the latest version of jQuery that's the issue, but also making sure the JavaScript code that Drupal core uses takes advantage of all of its fancy new features, and making sure we update existing code and keep it up to date with jQuery. This is why Drupal core ships with a stable version of jQuery, and then the jQuery Update module updates to a later version of jQuery along with replacing any outstanding Drupal core JavaScript files. This is still stuff that Libraries module has to figure out in contrib before it can be considered core-worthy. Bottom line, there is more to just updating jquery.js.

We also have to make sure to ship with jQuery with Drupal core as Drupal is sometimes used on intranets where Internet connectivity is not available. jQuery Update can handle changing to a CDNed version of jQuery (thanks mfer).

...funny thing the mention of CDN support and the argument that this might not be best practice when internet connectivity is not available. Just a few hours ago fatcrobat mentioned/announced in a post in the jQuery Update module's queue that he is working on CDN support with local fallback (I guess he was referring to his dQuery sandbox project). I suggested he joined forces with Daniel in jQuery libraries instead of creating another jQuery related project: #1131920: Co-maintainer(s) for the jQuery libraries module

Subscribing.

Rob Loach: BTW, 100644 is the file mode. You pretty much ignore the leading 100. In that case, ea128ac was the commit. The format in the patches is 1stcommit..2ndcommit 100filemode. I know the patch is old, just to point it out.

@klonos jQuery Update 7.x-2.x provides a local fallback for the CDN. It provides both the Google and MS CDNs. It's not just a matter of the case where the CDN goes down. Some places, and even who countries, have been known to block these CDNs.

Rob Loach is entirely right about compatibility issues. If Drupal launches with jQuery X and all the JS is written around that. Then contrib modules write their code around version X. When you drop jQuery version Y into a page instead things tend to break in both core and contrib. jQuery is known for not keeping up with backwards compatibility. For example, jQuery 1.6 bring in a props() method that should be used in cases where attr() was previously used. This will cause thing to change and all the dependent code on jQuery needs to be setup for that.

@mfer you of course right, but often jQuery changes are not big API changes and can be handle very quickly, at least for drupal core.

The big blocker is for contributed modules, which are not maintained at the same speed. Changing for Drupal is not a big deal, but it will introduce fragmentation among modules.

Drupal 7.0 uses jQuery 1.4.2
Drupal 7.1 uses jQuery 1.5.0
Drupal 7.2 uses jQuery 1.6.1

Then depending on the drupal version javascript modules will provides an API complient for 7.0, for 7.1 and for 7.2.

As the community and number of such modules is maybe not representative of the whole contributors community this is a big blocker.

But if we agree that drupal must support the latest version of jQuery then its module maintainer contract to keep their modules compatible with the last drupal release. Here we need a system to make modules declare their dependencies based on version and not only on project.

Instead of looking at the project name for a dependency, it will also look at the version tag. Views and some modules are doing it, but it would be nice to unify this by providing in the .info file such an information.

$Id$
name = Example Project
description = This example project requires at least drupal 7.1 with its companion library jQuery 1.5.0
core = >7.0
version = VERSION

Notice here the >7.0, meaning that module will be compatible for drupal version 7.1 and beyond, but not compatible with the initial release. (very similar to dependency version: http://drupal.org/node/542202#dependencies)

Thanx for the info Matt. I wasn't aware of the country "censorship" use case scenario (I guess I still live in a -relatively- free country and perhaps take things like that for granted).

As for the compatibility issues that Rob mentions, I am aware of them and I never proposed to ignore them. Allowing users to drop version Y though and then test things would reveal issues earlier and we could deal with them in time. We'd have more "I dropped version Y and noticed this issue, so I now reverted to X and all is good again" kinda feedback.

Making core take advantage of new jQuery features is a whole other thing. I guess perhaps core jQuery code should be made as abstract/generalized as possible in order to be able to keep up with as less effort as possible. I wouldn't know though and even mentioning the words "core code" leaves me at awe.

@Sylvain Lecoy Let's look at a case where you're proposed jQuery updating method fails. What about a module written for Drupal 7.0 and jQuery 1.4.4. Say the sites goes to update from Drupal 7.0 to Drupal 7.2 (with jQuery 1.6.1). But, the contrib modules JS doesn't work on jQuery 1.6.1 and hasn't been updated for Drupal 7.2 yet. Say Drupal 7.2 was a security release. The site can either update for a security release and break the JS functionality. Or, it can keep the JS functionality working and be insecure.

While I have yet to test out jQuery 1.6 I can see a possible problem because of the change with the attr method and the new props method.

Core has a number of competing issues that need to be balanced. I would love to find a way for core to keep up with jQuery in a way that doesn't hurt websites that are using elements in the contrib space. But, with the competing issues is that realistic? Is that possible? And for Drupal 8 is there a way to make that better?

Then it obliges module maintainers to upgrade the security issue due to massive request from people.

I think this is not a bad thing.

Im agreed to update jQuery. Especially other JS. eg jQuery.cookes / jQuery.form. I don't see any big effect if they upgrade to new version, even it could more better. because we can't upgrade jQuery.form and then write a new function to fix the bug is really stupid i think.

I haven't a real stats but I do not see a large mass of jQuery plugins update during jQuery version upgrade. jQuery seems to be nicely backward compatible.

while we have jQuery Update, we can also have jQuery downgrade or whatever to handle backward compatible.

@droplet I think you right about backwards compatibility.

On their git, they provide compat plugins only when jQuery is not backward compatible:

• https://github.com/jquery/jquery-compat-1.3
• https://github.com/jquery/jquery-compat-1.1
• https://github.com/jquery/jquery-compat-1.0

This need to be validated of course, but we can then think that 1.6 is backward compatible with 1.5 which is backward compatible with 1.4.

@Sylvain Lecoy Many contrib modules don't update in a timely manner. Often not based on a dev Drupal version. If Drupal releases a point version that starts breaking sites there is a big problem. You can't try to force or obligate contrib module owners to update in a timely manner. It just won't happen.

This ticket is for handling Drupal 8. jQuery 1.5 is not perfectly compatible with jQuery 1.4.4. For example, jquery.form.js needed to be updated for jQuery 1.5. When I first dropped jQuery 1.5 into a Drupal 7 install some JavaScript elements broke. Not all plugins work with jQuery 1.5 that were written for jQuery 1.4.

With Drupal we need to keep a product that works for the masses. It's a CMS that needs to work for business critical situations through a sane update cycle. For those of us who want to stay on the edge of jQuery releases, are willing to work through and fix/troubleshoot when JS breaks, or don't care if stuff breaks we can use modules like jQuery Update (or someday the jQuery module) to do so. We can't force everyone/the masses to use a cycle that only works for some of us.

• jQuery 1.6 RC1
• jQuery UI 1.8.12
• jQuery Form 2.72
• jQuery Cookie changed to the version that's shipped with jQuery UI for versioning consistency

jQuery Cookie and jQuery Form were minified with Google Closure Compiler.

Updated to jQuery 1.6. Looks like the States system broke in the process though (tested at admin/config/people/accounts).

There we go... Checked states now use prop() instead of attr().

For states I was wondering if we should use something like the following:

  return this.is(':checked');

We could backport it to D7 as it works on jQuery 1.4 through 1.6. I wonder which is faster?

Both this.is(':checked'); and this.prop('checked'); work, but I have bets on prop() being faster as it goes directly to the DOM element's property. You're right about .is() being backwards compatible though, and having the same JavaScript states.js in D7 is kind of handy. I'm voting on using .is().

jQuery 1.6.1 is coming out soon, and it documents that we should actually be using .prop() here instead. is() works, but prop() is most definitely faster and the "right" way to do it.

• jQuery 1.6.1
• jQuery UI 1.8.12
• jQuery Form 2.72
• jQuery Cookie 1.8.12 (shipped with jQuery UI)
• Switched states system back to prop, as recommended on the jQuery 1.6.1 announcement

Thanks!

Just a quick question so I can clarify a thing: I understand that this goes against D8 with the intention to be backported to D7, but can we (all of us working on D7) be testing against D7 -even if it means that we might have to be applying the patches here manually- and reporting issues? Will these tests and reports be taken under consideration or will we be ignored since this is against D8?

@klonos - The intention of this is to apply it to Drupal 8. jQuery 1.6.1 breaks APIs from previous versions so don't ever expect to see it in Drupal 7 core. Updating core to jQuery 1.6.1 would cause contrib modules to break, cause sites to break, and cause a lot of problems. The jQuery Update module will provide the update for Drupal 7 so you can have it and deal with the places where it breaks contrib modules.

Got it Matt. Thanx for taking the time to explain.

1.6.2 RC1

latest git patch.. ive tested it and works fine

This is

1) not critical...
2) We should use the minified version

sadly, it's never to be ported..

latest patch, as per requested, minified version by
Google Closure Compiler
that jquery uses.

Should we also update jQuery UI and the rest in this patch, or push those to a separate issue? Also, don't forget to update the entry in system_library() ;-) .

1.6.2 was just released.
http://blog.jquery.com/2011/06/30/jquery-162-released/

dont worry, my patch is version jQuery JavaScript Library v1.6.3pre

i filed a new issue about jquery ui, still the admin closed it and marked it as duplicate in this issue, so i guess i will post a patch in jquery ui library as well. and the jquery ui css too here.. and the core too here if possible.

I know this is constant work in progress, but I'd like to take a minute to thank you for your time and hard work on this Lauro. Keep it up!

wow, many thanks.. :)

Waiting for this issue to be solved and have a new release so the Drupal 6 branch of Jquery Reel Formatter can depend on it.

edit: thought this was the jquery update issue, sorry guys

Why are we packing jquery (etc) ourselves (#50)? Why are we not using pristine (minified) sources, and use Drupal to combine jquery / ui / form if required?

lets leave the jquery binaries to the maintainers of the library themselves..

#58 because drupal cannot automatically do that. someone has to do it.

I'm confused, whats wrong with http://code.jquery.com/jquery-1.6.2.min.js ?

Exactly

but no one as of now is updating the jquery version in the 8.x-dev so I created a patch so admins can update it.

No problem with a patch being created - we were questioning the origins of jquery.js in #50.

its the latest git version: jQuery JavaScript Library v1.6.3pre Live From Git,

this is 8.x-dev people and we are talking bleeding edge. still it wont break, ive tested it.

and i assure you, its much faster, much more bug fixes than the released one.

We only actually use released versions of jquery.......

fine:
jQuery JavaScript Library v1.6.2

added too the released version of jquery ui

can it set a milestone ? e.g. get jQuery 1.7 into D8.x CORE first, so we can use new feature of jQuery and other library..

anyone know when Dires & D8 maintainer will take care of this issue ? 2 years later, nearly D8 release ?

for crying out loud, my first patch is the bleeding edge fresh from the git of jquery and ui, but they ignored it and said that they want the released versions, so they asked for it, i came out with a patch.

i want to become a maintainer for this one, hopefully use the git versions of jquery and ui if majority agrees and use the cool new features the bleeding edge has to offer.

released versions cannot offer the latest bug fixes and new features bleeding edge has to offer.

look its html5 era now.. and drupal bleeding edge uses the old versions of the core framework of which the html5 relies.. how ironic.

...since this is for D8, I seriously think that Libraries API is the way to go. We need to figure a way to stop "babysitting" on jQuery and the UI and wasting precious time chasing after future updates. As new versions come out, one should be able to simply drop the external libraries in a directory and that'd be it! If it breaks things, they'd simply revert to a previous version (again, by simply dropping files in place instead of having to patch/unpatch each time) that works for them and report the non working version so we can figure out what's wrong with it.

In a previous discussion/issue I was told that "vanilla" jQuery doesn't work as is with core. I realize that this might still be true, but there surely must be something that can be done either on our side or on jQuery's. I wouldn't know though(?).

@keichee: hey Lauro, even if your work does not find its way in core (or simply takes too long to), still don't think that it goes unnoticed. I must be one of many people out here greatly appreciating your hard work and time spent on this. Keep it up and thanx for the bleeding edge 1.6.3pre patches -that's what I use-.

PS: related issue: #1167496: Libraries API in core

@klonos thank you very much.

still i will like to urge the community to vote for this thread to implement a native version of bleeding edge libraries to the core,
to have new features and bugfixes that the bleeding jquery and ui can give.

i preferred to use drupal installation without other modules installed because im creating my own module and i dont want to depend it to other modules, only drupal core.

IMHO Drupal should not use "bleeding edge" (as in git versions) of any library in core. The actual releases aren't far behind, and are much more stable/tested. Core currently expects a particular version of jquery - upgrading jquery.js introduces non backward-compatible changes, which breaks Drupal. This is to be expected - and is why a patch should include both the (released) versions of libraries, and patches to Drupal to accomodate changes in the underlying JS libraries.

It's quite reasonably to make a case for Drupal updating to the latest release of jquery, of course - and I support that.

FYI, the version of jquery in D7/D8-head is identical to the official jquery-1.4.4 release, apart from a blank line at the start (for some reason).

@keichee, I think if this issue was titled differently you might have got more positive responses.

There are two things going on here:

1. 8.x should at a minimum always have the latest stable version of jQuery and jQuery UI to the extent that we can keep up and fix bugs - there is nothing controversial about that at all and that's how this issue started out.

2. You're proposing that we run jQuery bleeding edge so that we can find bugs much faster and contribute back reports to the jQuery project.

(also some people are talking about updating jQuery libraries in D7 core but this is a known problem that has solutions in contrib, and good reasons not to do it with core).

We have always done #1 to some extent, although often lag a bit behind with development release and it tends to happen towards the end.

We have never done #2 but IMO it'd be worth trying. There are two caveats: if we track jQuery unstable very closely, we could end up at the end of the cycle having to downgrade in core, that's probably unlikely since they have much faster release cycles than us, and we could decide when to start relying on stables again (i.e. at beta/rc stage). Also, that there is no automated testing of JavaScript in core at all, so traditionally every jQuery update has to be accompanied by both cross-browser manual testing and accompanied by fixes to JavaScript that got broken.

So to get this done, I'd suggest we split this into two issues:

1. Upgrade to the latest stable release of jQuery in this issue - since that is pretty straightforward and any bc issues will have to be fixed as part of it (or in followups if they get missed).

2. Open a new issue recommending that 8.x tracks bleeding edge jQuery for the duration of the release, making it clear you're prepared to do a lot of the work to make that possible (like refreshing the library and fixing issues as they come up). lyricnz is right that this would be quite a big shift for us, it deserves a discussion in its own right.

Sure, sounds reasonable. As it happens, jquery releases pretty often, so tracking only actual releases wouldn't slow us down appreciably (especially since we'll need to make the final/official D8 release on one of these)

1.6.2 June 30th, 2011
1.6.1 May 12th, 2011
1.6 May 3rd, 2011
1.5.2 March 31st, 2011
1.5.1 Feb 24th, 2011
1.5 Jan 31st, 2011

i can dedicate myself to create a patch every time there's a new update, that's really easy for me to do.
(I love to contribute to drupal fwiw)

ive created a new issue before, but for some reason, some admin makes it a duplicate to this post:
(so i keep on posting on this post again and again because my last post is said to be duplicated to this issue)
Update jQuery to the latest git version available

so everythings clear now? ive created a released patch here, commit it to the core now.. still theres two issues, which of those two issues will be committed to core in 8.x-dev the released or the bleeding edge?

sure i will check those issues that broke the core in jquery. there are simple tests that google has for javascript testing that can be run using php when ported i guess.

@lyricnz, @catch: hey guys, you both make points that actually make sense, but you are missing one fact: we are not after latest jQuery & UI because we aim to find bugs and contribute feedback to the project. It's not like we see drupal as a "testing ground" for jQuery o something. Discovering & reporting bugs is simply a side effect or more like a thing we do along the way. What we are after is latest features and bug fixes. That's what it's all about.

OTOH though, that might just be me (and Lauro perhaps I guess) and that's proven by the way I chose to work with drupal and its contrib projects as well: I always use dev builds where available (unless they have known serious issues that break things instead of fixing them). The reason why I decided to go that path though is mostly because of the (frustratingly slow may I add) release cycle of drupal and the fact that most patches & fixes I would otherwise have to maintain and re-apply after each upgrade are included in latest dev builds. So, using dev is a real time saver.

Anyways, bottom line is... sure, I understand your points, but I strongly feel that web developing with drupal should not differ from the way jQuery is used in non-CMS setups: simply try the latest version and if it doesn't work, then revert so you can be back in business (and report the issue so it can eventually be fixed of course).

PS: perhaps #1203506: Update jQuery & UI to the latest git versions available (currently 1.6.3pre & 1.9pre respectively) should re-open. Stable releases here, pre-builds there(?) seems reasonable to me.

...kinda off-topic, but a bit of googling around terms 'jquery', 'automated' & 'test' brings a few interesting results. Does anyone know of any effort I might not be aware of to incorporate jQuery auto tests in core/simpletest?

...aaand asking the question in a more appropriate place: #1221442: Add support for jQuery/JavaScript automated tests.

Tagging issues not yet using summary template.

+

The attr/prop changes in jQuery 1.6+ causes issue with D7 core and contrib JavaScript as discussed in #1156860: Offer latest jQuery 1.6.x as an option (currently 1.6.4). (starting at #13).

this is 8.x-dev, if D7 javascript needs updating code then it can be done..

Indeed, this issue is for D8. But it currently shares a lot of (JavaScript) code with D7. Therefor, I assumed that by pointing that jQuery 1.6+ causes issues with JavaScript in D7 core, it would be obvious that in order to upgrade D8 to jQuery 1.6+ these issues should be fixed (in D8). I should have been more clear.

Also, since contrib modules and themes may need to be updated for the attr() behavior change in jQuery 1.6+,, the upgrade guide fro developer should mention it and provides links/explanation on the issue.

Since the current patch in in #68 doesn't address these issues, I think the status of this issue should be needs work.

• jQuery 1.6.2
• jQuery UI 1.8.16
• jQuery Form 2.84
• jQuery Cookie 1.8.16 (shipped with jQuery UI)
• jQuery Metadata 1.8.16 (shipped with jQuery UI)
• Compressed external libraries with Google Closure Compiler
• Prop fix for checkboxes in the Drupal States system
• Updated the jQuery UI dependency tree accordingly in system_library()
• Updated the version information in the System module
• Made update note in CHANGELOG.txt

Things that are broken in Drupal 7 should be fixed in jQuery Update or in the Drupal 7 issue queue. This is Drupal 8. Let's keep on topic, but you're right about documentation needed about the update so let's add the documentation tag. Other than that, I think this is pretty good to go!

Missing jquery.metadata.js.

There we go.

Problem/Motivation

Drupal core's version of jQuery is extremely out of date and restricts developers from using newer and updated JavaScript libraries to help enhance the end user experience.

Proposed resolution

• Update to jQuery 1.6.2, jQuery UI 1.8.16, jQuery Form 2.84 and jQuery Cookie 1.8.16 (shipped with jQuery UI)
• Add jQuery Metadata 1.8.16 (shipped with jQuery UI)
• Compress external libraries with Google Closure Compiler
• Prop fix for checkboxes in the Drupal States system
• Update the jQuery UI dependency tree accordingly in system_library()
• Update the version information in the System module
• Make an update note in CHANGELOG.txt

Remaining tasks

1. The solution is provided in the attached patch. This patch needs a review, the issue needs to be set to RTBC
2. Someone needs to commit it.
3. We must update the JavaScript update documentation to mention the new use of attr()/prop().

User interface changes

None.

API changes

jQuery 1.6.1+ contains some fixes to .attr() which affects our States system. It forks some of it to the new .prop() function, which is now used in our States system. We should note this in our API upgrade changes documentation.

Original report by momendo

With the release of IE9 imminent, and jQuery 1.5.1 release was made to fix all bugs related to IE9, does it make sense to put this release into D7? Their changelog suggests many IE related bugs were fixed.

"jQuery now supports Internet Explorer 9 as a top level browser. All known bugs have been fixed and/or been reported to the IE team for resolution in the final release."

Hey Rob, thanx. This summary should actually go to the issue's summary section. It simply doesn't belong in a comment - especially #88. Want me to move it there, or perhaps you posted it here intentionally?

I pasted Rob's summary up top in the summary field.

Moving summary from #88 into summary field.

...link to the actual patch and point to the post containing it.

...and I updated mention of the patch that needs review to point to the actual file and respective post.

Here's a patch that updates it to jQuery 1.6.3 RC1.

@klonos @xjm: Thanks! I'll update it for this 1.6.3 one.

...stupid forth-slash - slip of finger.

A reminder - this issues is about tracking the latest released versions of jquery (etc), not pre-release or git versions. Happy to have the patch, and test it, but it shouldn't be RTBC until the patch contains released versions.

Updated to jQuery 1.6.3.

Updated to the 1.6.3 patch.

What may need to check & I've checked

Prepare:

• New installation of Drupal-dev-head & Apply patches
• Enable all modules

Basic UI:

• able to open a overlay
• able to add / remove shortcut
• able to use contextual links

Dashboard (being remove from Core):

#overlay=admin/dashboard

• able to add / remove blocks
• able to configure

Creating node:

#overlay=admin/content

• able to use auto complete of tags
• able to add Edit / Hide Summary
• able to change text format
• able to upload more than 2 images
• able to sort the weights of the images
• able to remove image
• verticle tabs (able to swich & add menu)

Content Types:

#overlay=admin/structure/types/manage/article/display

• able to config fields display

Block:

#overlay=admin/structure/block

• able to add block
• able to drag & drop to change weight

Color module:

#overlay=admin/appearance/settings/bartik

• able to change color

User:

#overlay=admin/people/create

• Password strength is working

(I've tested under Firefox 6.0.1)

I've tried the patch from #94 on a Drupal 7 install and the Field UI widget selection boxes don't get enabled after selecting a Field Type. I assume this would be the same issue in Drupal 8.

Lines 87 - 89:

    });

    $(this).html(html).attr('disabled', disabled ? 'disabled' : '');
  });

would need to be (since disabled is a boolean variable)

    });

    $(this).html(html).prop('disabled', disabled);
  });

And lines 240 - 242

      // Disabled elements do not appear in POST ajax data, so we mark the
      // elements disabled only after firing the request.
      $(ajaxElements).attr('disabled', true);
    }

should be

      // Disabled elements do not appear in POST ajax data, so we mark the
      // elements disabled only after firing the request.
      $(ajaxElements).prop('disabled', true);
    }

Updated to jQuery 1.6.4 and added in minorOffense's changes. Thanks a lot! Looks pretty good.

Moved to 1.6.3.

Thank you people for keeping this up to date!! I really appreciate it.

#97: 1085590-jquery163-97.patch queued for re-testing.

Removing tag that is not being used any more. When this is committed, it will need a change notice node created, but we don't use that tag anyway.

jQuery 1.7 RC1... We're falling far behind here.

This patch tries to do too much and makes reviewing very difficult. Let's re-work the scope of this issue to just update jQuery UI and split out #1328900: Update to jQuery 1.7.

Since jquery 1.7 is in core now, Here's and update.

This is not an easy patch to review. Also I did a commit and did a git format-patch to catch all binary changes if any.

I expect any other library change to be in a different issue this is only for Jquery UI.

The permissions are actually all screwed up on this patch, re-uploading now.

Ok, hopefully this one is easier to review.

I left out the images as they didn't change, I add the css files, but they were identically so they don't show up on the diff.

This one should be pretty good.

Don't know if this is jquery ui's fault or not but just thought I should report it:

git apply 1085590-105.patch
1085590-105.patch:833: trailing whitespace.
.ui-dialog .ui-dialog-title { float: left; margin: .1em 16px .1em 0; } 
warning: 1 line adds whitespace errors.

I'm going to test this patch manually

...

Couldn't find any errors. Would like someone else to test in their environment as well.

Bumping to critical since keeping up with jQuery is non-optional.

Submitted a pull request to them about the whitespace:
https://github.com/jquery/jquery-ui/pull/537

Made it so that managing the version numbers will be a bit easier in the future:

    'version' => $libraries['ui']['version'],

Let's push updating jQuery Form, jQuery Cookie and adding jQuery Metadata (shipped with jQuery UI) to separate issues.

Updated issue summary.

What are we using jQuery UI for in core? Just the dashboard? Anything else?

Are there issues open for the others yet?

What are we using jQuery UI for in core?

I did a few manual tests. I put a breakpoint on it's js and watched for things that would trip it.

Yes it appears that jQuery UI is being used for Dashboard, but it is also used for regular pages while logged in as an admin/editor. I thought that the overlay would use it but apparently it doesn't. I also thought autocompletes would use it, but that wasn't the case.

All of this sent me searching for the issue that brought jQuery UI into core: #315035: Add jQuery UI elements to core seems to be it. Looks like the intention was to refactor many of the existing interactions so they use jquery ui, but that doesn't appear to have happened.

Marking this RTBC, if no objections I'll commit it within 3-4 days.

I want to look into why we're loading it on /admin pages if there's no obvious culprit.

#108: 1085590-105.patch queued for re-testing.

Overlay's overlay-parent.js is listed as depending on jQuery UI Core in overlay.module.
Removing that dependency, or even moving the whole core/misc/ui folder, does not break anything related to it though.
Looking at overlay-parent.js, I can't find any calls to jQuery UI either.

The Dashboard uses jQuery UI Sortables for moving blocks around, which is the only thing in Core I could get to break by moving the core/misc/ui folder. It's also the only place I find which loads anything related to jQuery UI via #attached or drupal_add_library().

Autocompletions is all custom code so it does not use jQuery UI Autocomplete.

@Rob Loach, what do you think if we set up a JQUERY_UI_VERSION constant instead of doing $libraries['ui']['version']?

I much rather use the number or set up a constant.

@Rob Loach, what do you think if we set up a JQUERY_UI_VERSION constant instead of doing $libraries['ui']['version']?

JQUERY_UI_VERSION actually isn't a constant, as it can be upgraded via jQuery Update ;-) .

Yeah, a PHP constant would be wrong here.

Thanks for simplifying future updates, @Rob Loach :)

Would be nice to get this in. We can fix unexpected issues (if any) later on.

In general, I'd like to see a script that performs this update in an automated way and generates a patch that can be quickly committed. We should fast-track these updates and fix any bugs only afterwards. That not only keeps the changes focused and manageable, but also leads to a clean history. It's not the end of the world if a UI behavior is broken for a few days.

In general, I'd like to see a script that performs this update in an automated way and generates a patch that can be quickly committed. We should fast-track these updates and fix any bugs only afterwards.

I'd agree with this overall. Updating to the latest version of external libraries is not optional.

Committed/pushed to 8.x.

This needs a change notice.

Added a notice: http://drupal.org/node/1389394

Leaving major for the followup tasks.

Updated issue summary.

jQuery UI 1.9 is right around the corner. We should update to the latest in git to help the jQuery UI team out with their upcoming release, and allow us to start using some of jQuery UI 1.9 in Drupal core.

git versions of jquery and ui are much better. so even before upcoming release, the git versions are stable to drupal

The attached patch includes the following (in both diff and format-patch formats)...

1. Updates jQuery UI

This is the latest fresh checkout of http://github.com/jquery/jquery-ui and is placed into the core/vendor/jquery/jquery-ui directory, as outlined in #1400748: Proposal for unified namespace organization. Does not add the demos, the build system, or the tests.

All of the dependencies and paths are resolved in system_library_info().

2. Uses Composer to update jQuery UI

Composer is a package management tool for PHP. This patch includes composer.json, which just instructs Composer to download jQuery UI via git. It's currently set to download from jQuery UI's "master" branch, but we can change that to a specific tag when jQuery UI 1.9 is out. Both users and developers do not need to worry about this, as the patch adds jQuery UI sources directly in. Composer just makes updating jQuery UI in the future MUCH easier.

To update jQuery UI in follow up patches, one can run...

wget http://getcomposer.org/composer.phar
php composer.phar update

Once the Drush Composer integration project is up and running, things are a bit simpler:

drush dl composer
drush composer update

For more information on Composer, visit http://packagist.org . In a follow up patch, we can extend composer.json to download the components of Symfony that we use (ClassLoader and HttpFoundation).

Followed the Advanced patch workflow, but the testing bot doesn't like the patch. It applies fine with "git apply" though. Anyone know what's missing?

placed into the core/vendor/jquery/jquery-ui

Let's please discuss that in a separate issue.
#1400748: Proposal for unified namespace organization was specifically about PSR-0 classes, not about CSS/JS assets.
The reason we cannot just follow the standard there is because that would also change the well established standard in contrib from sites/all/libraries to sites/all/vendors. While I'm personally opposed to that, we might end up doing it still, but, again, let's discuss that elsewhere.

That said, I now actually reviewed the patch:
- I agree with using the non-minified versions of the files. We did the same for jQuery and we already have #1341792: [meta] Ship minified versions of external JavaScript libraries for not forgetting to change back to the minified versions before release.
- I agree with sticking jquery.ui in a libraries/vendor directory, but again, I'm not sure that this is the issue to decide exactly how.
- I do think it makes sense, though, to use the actual file structure of the jquery UI library, which we sort of distort currently, if I'm not mistaken.
- I support renaming the machine name of the library from 'ui' but can we please do 'jquery.ui.core' instead of 'ui.core'?!
- I do not think the Composer stuff should be part of this patch.

Hopefully the test bot likes these ones....

@tstoeckler I support renaming the machine name of the library from 'ui' but can we please do 'jquery.ui.core' instead of 'ui.core'?!

Definitely agree with this! Updated in the patch.

I do not think the Composer stuff should be part of this patch.

Agreed! That discussion should live over at #1424924: Use Composer for updating Symfony components (without removing Symfony code from repo). Removed composer.json in this patch.

As a side note and for reference later on, attached is the composer.json file I used to retrieve jQuery UI.

Updated to the latest in the master branch.

/core/vendor is the wrong place to put JavaScript code.

That directory is supposed to contain namespaced PHP classes, not arbitrary other stuff. The proposal to put jQuery in there fundamentally contradicts what others (not me) have argued very hard for in #1290658: Move all module-provided classes to PHP namespaces (PSR-0 or similar), and autoload them without the registry [policy, no patch], and that's the primary reason for why we're going to have a lib/ directory in every module (not favored by me). This is the wrong issue for proposing to intermix PHP and arbitrary asset code, please create a separate issue for that (and link to it from here).

Under the premise of keeping current paths, I fully support to commit the latest and greatest unstable jQuery + jQuery UI + jQuery * plugin code to D8 core.

Not only to help those upstream projects, but also to start leveraging latest and greatest features. For example, #1296128: Replace autocomplete with jQuery TokenInput

@catch: Do you see any chance for fast-tracking simple upstream library updates into core in the future?

With jQuery we don't have an option but to release with the latest stable version, so I'm mostly fine with front-loading the commits of new versions then fixing bugs as we find them (rather than having them sit in the queue unreviewed for months which is what usually happens at the moment). Obviously it'd be better if we had automated JavaScript testing so we're not still manually clicking around like it's 2006.

Note that effulgentsia suggested on a groups.drupal.org discussion that it might be worth looking at putting jquery_update into core (so that we can backport jQuery updates to stable Drupal releases, but still provide the older versions for bc), I'd be very interested in discussing that in an issue.

It is placed it in core/vendor/jquery/jquery-ui because core/vendor/README.txt states...

3rd party libraries provided by Drupal core should be placed in this directory.
They should not be modified from their original form at any time. They should
be changed only to keep up to date with upstream projects.

Code in this directory MAY be licensed under a GPL-compatible non-GPL license.
If so, it must be properly documented in COPYRIGHT.txt.

We already have documentation in Drupal Core telling users not to modify the code, there is absolutely no reason why we shouldn't use it. vendor is for any third-party vendor code. Whether it's PHP, JavaScript, or CSS does not matter. What does matter is that it's there and not modified from its original form.

Obviously it'd be better if we had automated JavaScript testing so we're not still manually clicking around like it's 2006.

http://drupal.org/project/qunit

Note that effulgentsia suggested on a groups.drupal.org discussion that it might be worth looking at putting jquery_update into core

I'm not sure this is where we want to go with it. jQuery Update is the implementation detail on how to update jQuery. Drupal Core should not worry about implementation details. Instead, Drupal Core should just facilitate the ability for it to happen. By that I mean, we introduced hook_js_alter, hook_library_info and hook_library_info_alter so that jQuery Update would be much easier to handle in contrib. Both contrib and jQuery move faster than Drupal Core, so jQuery Update (and the jQuery module) need to stay out of Core.

I'm all for keeping jQuery up to date in Drupal Core across all different branches, but jQuery just moves WAY faster than us.

Right. The point of adding jQuery Update to core would be that " jQuery just moves WAY faster than us." wouldn't have to be true. While the stock Drupal 7 you get would come with whatever version of jQuery 7.0 shipped with, for stability, you could enable jQuery Update as an optional thing and get all of the stuff you need right out of the box.

This is wildly OT for this thread, however. :) The discussion catch refers to is at http://groups.drupal.org/node/210973.

As the current maintainer of jQuery Update, I'm voting no. Shipping multiple versions of jQuery with Drupal just seems silly. You can already enable jQuery Update as an optional thing, and get all you need with a simple contrib module. Do we really want to ship four or five different versions of jQuery UI throughout the life span of Drupal 8 for each release? I think not.

"latest jQuery in Core" is better than "jQuery Update in XXX" or "OLD version in CORE"

now the fact is "jQuery update never up-to-date". As a contrib module, less modules try to support it, less developers try to fix it. OLD jQuery brings bad performance and buggy to us.

jQuery Update is push latest version to global. add a jQuery Downgrade for your own old scripts that's fine, less trouble to other modules. What's the cons if latest version include in core.

Please, let's move the discussion whether or not to bring jQuery update into core in a separate issue (or keep it in the parent g.d.o discussion, where the suggestion originated from).

This issue is very straight-forward. We just need to update jQuery UI to its latest version.

Let's also move the discussion about moving the files into an own issue. It's outside of the scope for this issue, which says "update", and not "change where we put jQuery libraries, move them, and turn /core/vendor into a dumping ground of libraries, and update them while being there."

Deal: #1473066: [Meta] Move third-party assets out of core/misc folder ... Here's a quick update to the patch, hopefully I didn't miss anything.

Grrr.

Hmm?

Checked locally and it does apply well. Giving the testbot one more try before further investigation.
#146: 1085590.patch queued for re-testing.

Windows patch: Ensure the patch only contains unix-style line endings.

Rerolled without wrong line endings.

+++ b/core/modules/system/system.moduleundefined
@@ -1297,394 +1297,451 @@ function system_library_info() {
     ),
   );
   $libraries['effects.explode'] = array(
     'title' => 'jQuery UI: Effects Explode',
     'website' => 'http://jqueryui.com/demos/effect/',

Was missing a couple effect renames.

-15 days to next Drupal core point release.

#152: drupal-1085590-152.patch queued for re-testing.

Updated to master as #675446: Use jQuery UI Autocomplete needs it.

How's this?

Does not having LICENSE in there help? Wild guess?

Ensure I'm using UNIX-line endings? Psssh, please... I'm on Linux.

Hmmm....

git config --global core.autocrlf true
git config --global core.eol crlf

Here's an attempt.

Fixed the failures, as well as one other oversight.

Well done, Tim. Good find on the locale test. I'm going to RTBC this one, as it's looking pretty solid, and we need it for a few of the accessibility issues. The only place where we're using jQuery UI is the Overlay, and that is still very functional with this patch.

There are moves within this patch, so please apply it with git apply --index.

#170: drupal-1085590-170.patch queued for re-testing.

Committed and pushed to 8.x. Thanks!

Do not seems any follow up issue.
Will it add back version number at D8 release ? or a new bug ?

$.widget( "ui.autocomplete", {
	version: "@VERSION",
	defaultElement: "<input>",
	options: {

Will it add back version number at D8 release ?

I just built jQuery UI and jquery.ui.autocomplete.min.js still has that @VERSION code in there. Not sure where that @VERSION text is replaced, but we should re-visit that closer to release with #1658980: Update to the latest stable jQuery UI release.

Would also be nice to have a changelog text and change notification for this.

http://drupal.org/node/1658998

Edited summary

Turns out we missed one conversion.
I checked for other outliers with grep, nothing else shows up.

Oh, one other fix too!

@@ -1526,7 +1529,7 @@ function system_library_info() {
     'website' => 'http://jqueryui.com/demos/position/',
     'version' => $libraries['jquery.ui.core']['version'],
     'js' => array(
-      'core/misc/ui/jquery.ui.position.min.js' => array(),
+      'core/misc/ui/ui/jquery.ui.position.js' => array(),
     ),
   );
   $libraries['jquery.ui.progressbar'] = array(

Thanks Tim!.... AGAIN!

Ah, good point.

D'oh. Committed and pushed to 8.x. Thanks.

I asked about test coverage for this, since that's a pretty silly mistake, but Rob pointed out that we don't actually use jQuery UI in core anywhere so there's not really anything to test. We could probably engineer something but it seems a bit over the top for something we're unlikely to typo again.

Fixing title.

Follow-up to fix overlay #1428534: Use === and !==

@webchick views uses jquery ui dialog (that's how I found this bug) so well have tests for it then ;)

We could probably engineer something but it seems a bit over the top for something we're unlikely to typo again.

Hm... see attached patch. I'm pretty sure "typo again" already happened!

It wouldn't be too hard to write a test that goes through all the files listed in hook_library_info() and makes sure they actually exist in the filesystem. I don't have time to write that myself at the moment, but I think it would be worth doing it (especially since #1341792: [meta] Ship minified versions of external JavaScript libraries will rename these all again and introduce lots of new chances for typos to appear).

For now, the attached patch just contains the fix.

I am a terrible, terrible person.

@Rob Loach,

I just built jQuery UI and jquery.ui.autocomplete.min.js still has that @VERSION code in there. Not sure where that @VERSION text is replaced, but we should re-visit that closer to release with #1658980: Update to official jQuery UI release.

run "grunt release"

:(

Committed and pushed to 8.x, but let's open a follow-up ("normal" is fine) for automated test coverage of hook_library_info() as David describes.

Retitling in order to be more easily identified in the - existing - change record.

http://drupal.org/node/675446