Update to jQuery 1.7

Awesome issue summary. I completely agree. I'll try to get some reviewing help this Sunday during HTML5 office hours.

Can you use the minified version? All these tabs hurt my eyes

Great idea, Rob. Uncompressing jQuery for D8 slush period sounds like a great aid while we debug.

jQuery 1.7 has been released if we want to skip the RC: http://blog.jquery.com/2011/11/03/jquery-1-7-released/

Here's a patch with jQuery 1.7.

How much should we revise existing Javascript code as a result of the new version of jQuery. I'm specifically thinking about how jQuery 1.7 binds and unbinds events using the new .on / .off syntax.

Should the goal of this patch be what is necessary in order to get jQuery 1.7 working within Drupal? Or should we also include a round of optimizations and refactoring due to the new tools we have now?

Typically, it's best to keep patches focused on one thing: http://webchick.net/please-stop-eating-baby-kittens

So I think a patch here that just updates the version of jQuery and then a follow-up once that's in to integrate .on/.off (and more if there are other things that make sense to update) makes the most sense.

@webchick, cool, that makes sense.

I've made this issue to drive that follow-up. #1332066: [Meta] Update / Refactor JavaScript as a result of upgrading to jQuery 1.7

Going through all of the JavaScript while making these code revisions may also give us an opportunity to refactor/improve the code along the way. I've written in that issue the instruction to make separate issues for any code change that is intended on being a refactoring or improvement.

I think I've asked this before, but I can't recall the answer (or if I ever got one): Why can't we make it so that jQuery is a drop-in-place library (utilizing Libraries API or some other way)? I'm asking because that way we wouldn't necessarily have to patch core with each new version of jQuery that comes out.

Hm. I don't understand how that would work. You mean there could be 2+ jQuery libraries on a typical Drupal site, and a particular module would just choose which one it wanted to use? But how would that work when that module is used on a core page that also needs the older version? And how can we allow drop-in replacements when jQuery breaks backwards compatibility, which requires updates to core (and contributed module) code?

@klonos Drupal is deeply integration with jQuery. One shouldn't have the expectation that it wouldn't require a lot of testing to ensure that using an arbitrary version of jQuery would continue to allow Drupal site to function properly.

In Drupal 6, http://drupal.org/project/jquery_update was needed to properly advance the default jquery because dropping in the library was not enough to get the job done.

No, I meant this...

• Libraries API in core for D8.
• jquery.js (and other libraries for what it matters) under /core/libraries/ or /core/libraries/jquery.

This way, people would able to just place any newer version of jquery under /sites/all/libraries/ and core would use that one instead. If things still work, then ok. If things break, simply remove the custom/non-core library (so that things revert back to their old working state) and report the issue so that core can be adjusted to work with that version.

In other words, we ship Drupal with a known to work version of jQuery, but people have the option to try to use any newer version with ease. I am sure that there is a great chance that major versions of jQuery will most likely break things, but going from say 1.7 to 1.7.1 wouldn't be such a tedious task any more.

Thanx for taking the time to reply Rob. Yes, knowing that at least this plan is in the back of some people's minds was all I needed to know. I don't want to see any dead kitten either ;) I'm sure we'll get there sometime. It's just that I've been following all the "Update to jQuery 1.x" series of issues and I always kinda thought that we've already put so much work in it that we might as well go "kitten hunting" ;)

So.. Patch applied clean, console registered no weird errors or warnings as I saved content, loaded blocks and other common admin pages, and so forth. I was pointed to a page of JavaScript tests that lists many good pages to try while reviewing this patch. I found minor issues which I have filed in #1332066: [Meta] Update / Refactor JavaScript as a result of upgrading to jQuery 1.7.

For the scope of this issue, the patch in #5 is good. In the interest of being thorough I'll let someone else review before marking RTBC.

I'll test this as well, by going through as much of the list that rupl posted before I pass out.

Testing with #16
_______________________________
patch applied fine

Initial tests:
jQuery that loads is 1.7
Testing with: IE 7, 8, 9; Firefox 8, Opera 11.52, Chrome 15

Tests from http://groups.drupal.org/node/44450 that didn't work

• Uploading files: error here actually in jquery.form.js

  Uncaught TypeError: Object function ( selector, context ) {

  // The jQuery object is actually just the init constructor 'enhanced'

  return new jQuery.fn.init( selector, context, rootjQuery );

  } has no method 'handleError'

• I couldn't figure out how to, "Open a page inside the overlay that opens a page outside the overlay."

All other tests passed on all browsers listed above.

Here's how to reproduce the uploaded error,

1. With a fresh install create an article or a page.
2. Try to upload a file.
3. Notice that the throbber continues to rotate and the upload process never completes.

Also notice the following error is logged. The error is in /core/misc/jquery.form.js?v=2.52 line 12.

Uncaught TypeError: Object function ( selector, context ) {
	// The jQuery object is actually just the init constructor 'enhanced'
	return new jQuery.fn.init( selector, context, rootjQuery );
} has no method 'handleError'

http://bugs.jquery.com/ticket/8045 might be related.

And this: https://github.com/malsup/form/issues/56

Oh, I see, we just need to update jquery form. It's at version 2.87 now. Perhaps we should make a new issue for that. I'll go do that if there isn't one already.

Created a seperate issue for the bug I found : #1338402: Update jQuery Form

If the patch in #16 is to simply get jQuery into Drupal 8 then I recommend this to be RTBC

Does anyone have any issues with promoting this issue to RTBC? We can cleanup in the other issues that are dependent on this one.

Tagging Javascript. I think we should start using this tag with every Javascript related issue. It'll be simpler to track over ajax, js, Jquery, etc.. :)

Also this looks good to me, I haven't tested so I won't RTBC yet. I'll try to give it a spin later today.

Also I like the uncompressed version of 1.7 at least while we're developing :)

Just a note that we have a component for JavaScript if you want to see all JS-related issues: http://drupal.org/project/issues/drupal?component=javascript

@webchick, yea, but sometimes the component is marked as Ajax System. So those ajax issues don't usually show up.

I just put up a post on the JavaScript group about using the JavaScript tag. Is this totally wrong? (http://groups.drupal.org/node/190359) I think the tag is more flexible and allows it to be used in pretty much any issue that touches a JS file.

This patch has been manually tested and appears to be complete. Does anyone have an qualms with promoting it to RTBC?

@cosmicdreams sometimes you just gotta pull the trigger :)

Patch is RTBC. Let's file any future issues in #1332066: [Meta] Update / Refactor JavaScript as a result of upgrading to jQuery 1.7

as per ericduran on IRC, marking this as RTBC to prepare it for inclusion into Drupal 8.

EDIT:

Ah looks like rupl beat me to it.

@klonos,

without library API, you still able to place jQuery under /sites/all/libraries/... so what's the different ? (im no library API experiences)

I created a issue about jQuery stuff, maybe your guys interested and have more great idea:
#1332752: Coding standards: add jQuery multiple version naming conventions

Thanks for all the testing folks. I've committed/pushed this to 8.x and un-postponed a couple of the follow-up issues.

Is there an issue to do the same for jQuery UI?

Also this needs a change notification.

Would be great to announce this at http://groups.drupal.org/core too!

@catch, the jQuery UI issue is over at #1085590: Update to jQuery UI 1.9, which was postpone because of this issue.

We should mention that we should use .on and .off and not .bind and .unbind like we used to (http://blog.jquery.com/2011/11/03/jquery-1-7-released/)

...yep, handled here: #1342198: Use .on and .off instead of .bind, .unbind and .delegate

...silly me. Of course you know that Bram. You filed it ;)

Change notification: http://drupal.org/node/1342842

jQuery 1.8 released http://blog.jquery.com/2012/08/09/jquery-1-8-released/

Is there a follow-up issue?

1.7 is already ancient, and jQuery 2 will likely be out by the time D8 is ready. Can we just plan to have an option between 2 and 1.9? It seems silly to fall behind on this before D8 is even close to finished.

mentioned html5