Upgrade to jQuery 1.4

Just tried installing D7 with jQuery 1.4 and got the following error.

An error occurred.
Path: http://localhost/d7/install.php?profile=default&locale=en&id=1&op=do
Message: {"status":true,"percentage":"15","message":"Completed 4 of 27.\x3cbr \/\x3eInstalled \x3cem\x3eText\x3c\/em\x3e module."}

So set status to needs work.

Hm. I do think we need Drupal 7 to ship with jQuery 1.4. Otherwise, it'd be the equivalent of bundling a brand new version of some operating system with Drupal 5. When the new version comes out, community support wanes, and new plugins only come out for the new version. It's also supposed to be faster, and since D7 ships with more JS than any release to-date, it'd be good for performance.

Tagging as something I'd like us to get into Alpha 1. Though obviously, to do that we need folks to help debug these issues ASAP to make the transition as easy as possible on the 15th. This also gives us a chance to be good open source citizens and test jQuery for bugs before they ship.

Hmmm. Exceeeept... What will this to do jQuery UI? It looks like they're still shipping with 1.3.2 compatibility....

#3

jquery.js

  httpData: function( xhr, type, s ) {
...
      // Get the JavaScript object, if JSON is used.
      if ( type === "json" ) {
        if ( typeof JSON === "object" && JSON.parse ) {
          data = JSON.parse( data );
        } else {
          data = (new Function("return " + data))();
        }
      }

Native JSON parser gives a syntax error.

I don't think we are encoding the JSON properly, in includes/common.inc/drupal_json_encode()
ie

  return str_replace(array('<', '>', '&'), array('\x3c', '\x3e', '\x26'), json_encode($var));

should be

  return str_replace(array('<', '>', '&'), array('\u003c', '\u003e', '\u0026'), json_encode($var));

There's a open issue on this, #479368: D7: Create RFC compliant HTML safe JSON. I've just rerolled the patch for it.

With that patch applied, the install is able to complete

Patch as #2 with a small change to tabledrag.js to get the table row dragging working again (possibly the result of a jQuery bug...)

@webchick

I believe jquery ui 1.7.2 and the 1.8 series will support both jquery 1.3.2 and the 1.4 series, so I'm guessing there's no problem there. We just have to chose with version to go with, IMHO it should be the 1.8 series, since the upgrade from 1.7.2 to 1.8 should be easy.

Info gathered from this mailing list: http://www.mail-archive.com/jquery-ui@googlegroups.com/msg11933.html

Don't forget CHANGELOG.txt and system_library :-) .

The new jQuery API site has launched with details on what signatures have changed in 1.4.

Thanks for looking into the jQuery UI issue, Jolidog.

IMO we should make a sister issue then ASAP about jQuery 1.8 and start working through issues. I don't suppose that'll be out the 14th, too? ;)

Opened #679036: Upgrade to jQuery UI 1.8.

[comment edited by webchick to point to older issue; new one was marked duplicate.]

For the record: the bug in tabledrag.js is our own. It appears only in jQuery 1.4 because jQuery now supports before / after / replaceWith on disconnected nodes.

subscribing

We should use the min version..

http://code.jquery.com/jquery-1.4.min.js

Commit now and ask questions later?

Re-rolled #11 against current head, incorporating #12, and with jQuery 1.4 as linked by Matt in #18 (EDIT: or rather, using the min version linked in #19 actually). Easy re-roll, not wanting to take credit for other's work but here's the patch to keep things moving... :)

last line

- 'version' => '1.3.2',
+ 'version' => '1.4a2',

I think that has to be 1.4

Absolutely (#22). Missed that.

Regarding the json error, I don't know if it's relevant but I noticed a problem with it in D6.. It escaped single quotes when it shouldn't have. The only work around I found was to use PHP 5.2's native json encoding..,

see: http://drupal.org/node/443090#comment-2245630

@mfer:

We should take advantage of jQuery native methods/features where possible in this update as well. Changes are available at http://api.jquery.com/category/version/1.4/

jQuery's .live() now supports all JavaScript events, as well as custom events. So we could essentially replace the bulk of the behaviour system with it to increase JavaScript performance.

Hm, not entirely. Didn't look at the source code, but I guess there is still no special event for "attach" (load) and "detach" (move/serialize/unload). Many of our behaviors act on the sole insertion/injection of DOM elements, and if the selector is found, the DOM get modified. I'd love to replace our attaching/detaching behaviors system entirely with .live() and .die(), but it seems that we need to talk to jQuery developers, so they .trigger() certain, custom events for our case.

Anyway, we absolutely want to get jQuery 1.4 into D7.

I've added Chrome to the jQuery 1.4 tests and went through some of them. I think the best way to proceed with this issue is to make sure all the tests work, get jQuery 1.4 committed, and then look at some places where the jQuery 1.4 API could help us clean up some of the code in individual issues.

I'm not real excited to go on a big code-refactoring treasure hunt after this. If there are a couple of obvious patterns we can apply, or a particular place or two where we get really nice performance benefits, then great, but we need to focus on getting D7 out the door.

I'm running the jQuery 1.4 tests in IE 8. I'll update this post with any notes.

Notes:
- node/add/article: Vertical tabs are fine, but checking "Provide a menu link" does not reveal the menu options.
- admin/config/search/clean-urls: Not sure what I'm looking for here.

I agree with webchick. It's far too late to do any further changes. All we want to do is to get 1.4 in - so D7 stays cutting edge, and contrib can leverage it. (contrib can replace JavaScripts with better ones, if required)

This is alrdy broken #684602: IE BUG 1: menu options don't show up automatically, without the upgrade...

Wow. Check out those performance improvements in 1.4: http://jquery14.com/day-01/jquery-14

Yes, confirmed. This is not going to go into alpha1 at this point. That doesn't mean you should stop testing, though. :) There's always the next one. ;)

Please dont forget about Update to latest jQuery Form Plugin which brings a lot of troubles with #434394: 'HTTP error 0 occurred' on image upload and #240777: Attach: An HTTP Error 0 occurred (on file upload)

#609622: Keep jQuery Form up to date

subscribe

While testing everything in jQuery 1.4 is a great idea, I don't feel that it's quite ready for production use, due to a bug I've encountered with namespacing custom events (like the hashchange event that BBQ uses). That being said, the jQuery team is working on getting 1.4.1 out within a week or so, with 1.4.2 within a month or so, so hopefully the list of 1.4 bugs will be fixed in short order.

Either way, jQuery BBQ (which was just updated to v1.1) has been designed to support jQuery 1.4 from the very beginning, and has been fully unit tested in both 1.3.2 and 1.4a2.

Good reference article here, including a short list of upgrade gotchas: http://www.sitepoint.com/blogs/2010/01/18/jquery-14-released/

Here is the jQuery team's list of backward incompatible changes:
http://jquery14.com/day-01#backwards

Sub.

jQuery UI is broken in 1.4 at the moment. I wandered over to #jquery and the room directed to me http://paulirish.com for answers. Here's what I found out:
1. http://blog.jqueryui.com/2009/12/jquery-ui-18a2/ is the best place for us to go for the moment if we want to upgrade 1.4 and want to minimize jquery UI's brokenness
2. they are sympathetic about our needs, and will use *various measures* to expedite the release of of 1.8 beta. I mention alpha 3, and they corrected: beta 1.
3. the final release of 1.8 is nothing that anyone will go on record about estimating (obviously), but there's good reason to believe that it would happen within our alpha stage. Moreover we use a fairly limited number of their many features -- and they are the rather commonly used ones. So I have no worries.

Regardless, our upgrade to 1.4 will depend on an upgrade of jquery UI. That is without question

@mfer -- i did come across some reported bugs involving modals that open/close repeatedly, but to my knowledge we're using %2 of it, agreed. Good news that this patch can go in without updating UI. Obviously, we'll absolutely have to upgrade it if we ship with 1.4. I'd put my bets on 14 days from now for the final release [wink, wink].

@mfer - 10-4 - let me know if you need a peon to help out. Failure is not an option for this patch. <----captain obvious

I just rerolled the patch to let it apply

upps :-p
.. fix comment on #55

Passes now. That last failure was somewhat strange.

Is there any plan to backport it to Drupal6 ? Or should i stick with drupal_update for now ?

Thanks for the work in this patch =)

@dasndrade No, this won't be backported to D6.

subscribing

This will apparently fix #684602: IE BUG 1: menu options don't show up automatically, marked that as postponed.

patch #65

+++ modules/system/system.module	2010-01-27 12:40:15 +0000
@@ -1061,7 +1061,7 @@ function system_library() {
   $libraries['jquery'] = array(
     'title' => 'jQuery',
     'website' => 'http://jquery.com',
-    'version' => '1.3.2',
+    'version' => '1.4',
     'js' => array(

'version' => '1.4.1',

Could someone give me a feel for how close this is to RTBC? Is it dependent on #679036: Upgrade to jQuery UI 1.8?

$.isObject defined in drupal.js isn't the same as jQuery.isPlainObject(). isPlainObject only returns true if given variable is created using "{}" or "new Object"

A jQuery set for example is no plain object. So replacing calls to $.isObject with jQuery.isPlainObject() isn't going to work everywhere (e.g. overlay-parent.js).

Besides that overlay seems to work with patches from here and #679036: Upgrade to jQuery UI 1.8

subscribe

I would love to see this in core. :)

per #71 (forgot to change status)

sub

subscribe

jQuery 1.4.2 Released jQuery 1.4.2 Min
jQuery UI 1.8RC2 Released jQuery UI 1.8RC2

With the latest D7 dev snapshot from today, I could use jQuery 1.4.2 (from #78) fine. I tested the installation, admin sections, uploaded a file, ran update.php.

However, I couldn't test jQuery UI 1.8RC2. I tried to upgrade, but the admin overlay wouldn't work anymore. Although I think it's just that I didn't upgrade it correctly. Can anyone confirm?

matt, from the D7 code sprint in Montreal.

subscribe

@bgm you probably didn't upgrade correctly as I tested overlay succesfully with jq 1.4 and jq ui 1.8 (see #71)

Maybe we should update to jQuery UI 1.8rc2 during the update to jQuery 1.4 then.... Don't forget the images.

Subscribing. I haven't been following this issue at all, so I'm not gonna set it to "needs review", but I am curious what bot thinks of #83, so I'm looking forward to it reaching "needs review" status. I'm especially interested in how this will affect #561858: [Tests added] Fix drupal_add_js() and drupal_add_css() to work for AJAX requests too by adding lazy-load to AJAX framework.

I moved the Overlay's use of isPlainObject() back to isObject(), and it's working again. Yay!

Here is a patch updating the work already done to jquery 1.4.2

@Rob Loach: IMHO we do not want to mix this with #679036: Upgrade to jQuery UI 1.8

The Overlay wasn't resizing with just isPlainObject(). Switching to the following made the Overlay work appropriately...

Index: modules/overlay/overlay-parent.js
===================================================================
RCS file: /cvs/drupal/drupal/modules/overlay/overlay-parent.js,v
retrieving revision 1.27
diff -u -r1.27 overlay-parent.js
--- modules/overlay/overlay-parent.js	20 Feb 2010 14:48:38 -0000	1.27
+++ modules/overlay/overlay-parent.js	27 Feb 2010 17:46:38 -0000
@@ -602,7 +602,7 @@
 
   var height;
   // Only set height when iframe content is loaded.
-  if ($.isObject(self.$iframeBody)) {
+  if ($.isPlainObject(self.$iframeBody) || self.$iframeBody) {
     height = self.$iframeBody.outerHeight() + 25;
 
     // Only resize when height actually is changed.

Great! no more overlay problem, thanks :-)

Something got messed with that patch... jquery.js is not complete.

+  if ($.isPlainObject(self.$iframeBody) || self.$iframeBody) {

Eh... isPlainObject() matches objects that are created using "{}" or "new Object". self.$iframeBody is a jquery set and thus not one of those.

if (self.$iframeBody) {

Would do the same.

Casey to the rescue!

Just uploaded the first Drupal 7 module to require jQuery 1.4: YoxView ;-) . Heard about it from the jQuery Podcast from yesterday and couldn't do anything until there was a Drupal module for it!

subscribe

subscribe

Guys sorry for my noobness...

i need to run accordion jquery (1.4.2) menu on my Drupal 6 (jq 1.2.6)...

but i do not understand how to obtain an upgrade of my jquery.

I understood that there is an incompatibility and that theese patches are made for correct it...

but how can i use it?

what "subscribe" means?

thank you all would help me.

@Gik000:
http://drupal.org/project/jquery_update
#685060: Get ready for 1.4
http://3281d.com/projects/improving-subscriptions

#95 worked well for me on Safari 4 and FF 3.0. I tested menu drag, blocks, overlay, and fieldsets.

I'm getting some weird issues with this patch + overlay. I'm going to look at what's going more extensively and report back.

Sorry, the error I found is related to #535066: Use CSS3 / IE filter to render toolbar shadow not this patch.

cosmicdreams: make sure you clear your browser cache after applying the patch. I had a weird issue where overlays wouldn't scroll because of that.

@grendzy: Thank for the tip. Your suggestion of clearing my browser cache made me think of trying to flush the site's cache by going to /admin/config/development/performance and clicking the clear cache button. That cleared the issue I was having, which for sake of clarity I'll upload here:

Now, I knew this wasn't a browser cache issue because I have my cache disabled on my Firefox. Also I am baffled why Drupal would intentionally force a "site administrator" (read: non-programmer) to flush the cache of a site to simply get a module to work the way it should.

My scenario:
installed with default install profile
turned overlay off
applied patch
turned overlay on
found issue

I'll go back to testing your issue now.

I keep finding issues that seem to related to this patch but actually exist before the patch is applied. It's really difficult for me to give this patch a proper testing when there are so many javascript related issues in the CVS right now.

I'm going to see if someone has created issues for things I'm seeing.

The main issue that kept me from testing this patch is this: #732524: Dynamic Menu Management is broken with overlay on

subscribing

@cosmicdreams Please stay ontopic. Those issues aren't related.

I think we should commit patch #95 and work from there.

subscribe

@casey: Can you help steer me onto the right path here?

What should be the testing procedure that properly tests this patch. What proves the patch's success or failure?

This issue is only about upgrading to jquery 1.4. The issues you mention also occur without this patch, so they aren't related.

@casey: In testing this patch I think the goal should be to prove that applying this patch does not break functionality on the site. That is a difficult task if functionality that depends on the jQuery library is already broken. True, we can wash our hands of it and say, it was broken before and its broken now, so there has been no change, but from my relatively fresh perspective of these matters it seems like we are just confounding our efforts to fix these javascript-related issues by applying this patch without knowing it's full impact.

That is why I attempted to test so many seemingly unrelated javascript-enabled behaviors on the site. I'm trying to gain a sense of jQuery 1.4's impact on the correctness of code. My frustration is caused by how frequently my tests are unable to show informative results.

Now, if everyone else thinks its really not important to know if this patch degrades, improves, breaks, or fixes jQuery functionality during an alpha development period. Then I'll drop by objection and simplly test whether or not this patch replaces the old jQuery library with the new one.

@cosmicdreams The least impact of this patch we know of is that we'll have an up-to-date jquery and can use it's new functionality and enjoy its improved performance. Any javascript/jquery issues that we already know of or will encounter any time can be solved with jquery 1.4 if it could be with jquery 1.3. I don't think we should try to resolve all those issue at once, because we simply cannot.

Drupal 7 is ready for jQuery 1.4

I agree with casey.
Once we upgraded JQuery, we can fix JQuery related issues to work with 1.4. If we would first fix the issues, we might have do that again, when we upgrade JQuery to 1.4

Because we seem not to break more, than was already broken, I'd say, we move on and upgrade JQuery.

Works for me as well, we don't have automated tests for javascript stuff, so the only way we can find regressions is by people clicking around. Many more people will do that from dev releases and alpha snapshots than this patch.

I drop my objection to this patch. Looks like there are other patches that are depending on this one. Casey and catch make good sense here. Alpha is a time for acceptable breakage of functions if that breakage leads to better, more efficient functionality, not for bulletproofing a library upgrade before it commits. Thank you for setting my mind right.

+1, would be good if we could commit to 1.4 and start fixing bugs against it.

It would probably be a good idea to commit this patch on a Thursday or Friday, so we have the usual good crowd of people + time on the subsequent weekend to quickly fix any problems caused by this upgrade. With Overlay/Toolbar/whatnot entirely relying on JS, this can render your site pretty unusable.

And wow, 1.4 looks to be a pretty important improvement:

http://jquery14.com/day-01/jquery-14
http://jquery14.com/day-12/jquery-141-released
http://blog.jquery.com/2010/02/19/jquery-142-released/

About a 3x speed improvement over jQuery 1.3.2? That's shocking given how the 1.3x series was a such a huge performance win over 1.2. If visitors to this issue are interested, checkout the specific performance improvements in the links above.

Can I get some assurances that, if I commit this, people will hammer the hell out of the inevitable issues over the next couple of weeks to get them all banged out by the 21st, when we roll alpha3/beta1?

I agree this patch is important, but not if it causes critical regressions in functionality and makes alpha3/beta1 worse off than alpha2, front-end wise. Or are these concerns unnecessary (it's hard to follow what issues have been identified and fixed already)?

Unnecessary? Yes! Just commit this one. Waiting will just delay fixing any other js issues.

In reference jQuery issues with overlay, I do intend to hunt down and help test whatever remaining issues are there.

After reading the release notes for the 1.4.x series I'm convinced that applying this patch will be a net benefit since much of 1.4 address specific issues I've found in the queue.

.data() *api change*
.html() - Faster now
json.Parse() *new*
.detach() *new *

Ok, thanks, cosmicdreams. And thanks too for the wonderful thoroughness in your testing. Hugely appreciated.

Unfortunately, this no longer applies. Can someone give a quick re-roll?

#95: 653580.patch queued for re-testing.

Current code in overlay-parent.js

// When no height is given try to get height when iframe content is loaded.
  if (!height && $.isObject(self.$iframeBody)) {
    height = self.$iframeBody.outerHeight() + 25;
  }

patch code

   var height;
   // Only set height when iframe content is loaded.
-  if ($.isObject(self.$iframeBody)) {
+  if (self.$iframeBody) {
     height = self.$iframeBody.outerHeight() + 25;
 
     // Only resize when height actually is changed.

Do we have to use $.isObject(self.$iframeBody) or self.$iframeBody

reroll

Untill bot says no

Here is my attempt to reroll. Looks like the only rejection I had was related to how the overlay re-renders when the height of the overlay changes. That issue seems to have been fixed elsewhere (and in a differrent manner than how this patch would have changed it.)

Sorry, casey, didn't see your previous post. Given that your patch and mine have different file sizes we should probably use yours.

cosmicdreams, patch #125 is better.

EDIT:

If there is a difference, you better can post the difference if you're not 100% sure.
Cause now you made a patch with a missing part, it took you some effort to make it.

This advice will make your life easier :)

Looks like I changed the status, changing back

@casey: Ah I see, you retained the spirit of how #95 would have changed the overlay-parent.js

If #125 is what's desired, it needs to be re-uploaded before status can be RTBC.

Hm?

Testbot tests all patches regardless of what order they're uploaded..?

Sorry, webchick. My mistake. I thought you needed the community accepted patch to be the last one in an issue.

Oh! Normally, yes, that's a very nice thing to do. But I'm following this one closely, so I'm good. ;)

Ok, #125 came back green. Committed to HEAD.

Let the follow-ups begin. :P

Green means go.. :D

cross-post. ;)

whoops, cross-post.

Yay(query)!

SWEET! Thanks so much for everyone's great work on this.

At least for me, there are a few obvious breakages that can be found right away. I'll create an issue to that can serve as a meta issue for post-patch fixes.

@cosmicdreams: issue is caused by patch that accidently is commited by webchick : #676008: Overlay's Loading 'spinner' graphic often not visible because it is displayed outside the viewport

Ah thanks, thought I had missed something.

looks like I'm only finding a few issues post-patch. The main issue I listed above is no longer relevant. It seems that between the time I wrote that and now that issue has been fixed by other patches.

So that the conversation we've generated here can flow into these other issues I'll list the post-patch problems I've found:
(Note it is very likely that some or all of this issues existed before the jQuery 1.4 patch)

#737614: Enabling Overlay leads to a double toolbar
#737632: tabledrag: menu children take top of left region or not at all in IE
#737600: Use of getBoxObjectFor() is deprecated. Try to use element.getBoundingClientRect() if possible. - minor
#737596: tabledrag.js: $(".indentation", testCell).get(1) is undefined

2 are duplicate, one is fixed I guess and the other isn't an issue in my opnion as we aren't using the deprecated function.

The filter UI is broken (I believe) by this: #739142: Filter UI completely broken by Jquery 1.4 commit.

This is quite annoying.

Is there any guide to show you the steps needed to take to upgrade to v. 1.4.2 (or greater)?

The patches available here do not describe on what they rely, and they sure as hell not meant for "stock" drupal, as the jquery version in the patches seems to be 1.3.2 and the stock version is 1.2.6, someone needs to tell us how to continue to actually use jquery 1.4.2 (or greater).

It's not just some "minor" fixes in the 1.4 version, but some very important ones, I'll just mention live events as one.

Think kind of issue should have been a major issue for a minor version update. and you guys shouldn't jump on me and say "well, write your own patch!", this kind of thing is messed deep within the drupal logic and innards, and although I'm working with drupal for a couple of years now, I still am not that capable to update it by myself...

--- Edit ---

As I see it, the main problem is with the JSON, which is not actually a valid JSON.
I have no idea why or who decided to create custom function to encode JSON, or why changing < to \x3c is a good idea,
but that's *not* valid JSON.

For those who look for a simple solution, for now I found that if you replace the "drupal_to_js" function (file includes/common.inc) to simple do "json_encode", this will fix most of the problems, and will let you work on jquery 1.4.2 straight from stock drupal installation (just replace the jquery.js in /misc/ directory).

Please do not hijack threads that are for another Drupal version. This thread *exclusively* refers to Drupal 7 and has nothing whatsoever to do with Drupal 6. For upgrading jQuery for Drupal 6, you can use the jquery_update.module: http://drupal.org/project/jquery_update

-- comment removed --

jQuery 1.4.3 has been released. This release carries some very impressive performance improvements and maintains backwards compatibility.

Given Drupal 7’s heavy dependence on jQuery for UI effects, I’d consider this upgrade rather important to get in before Drupal 7 is released.

I agree that updating to 1.4.3 would be a good idea, but please open a separate issue.

issue opened for 1.4.3: #944308: Update to jQuery 1.4.4