Update Drupal 6 to jQuery 1.1.3.1 =)

Please update your patch to include the latest _stable_ jQuery release which is 1.1.2. Then I'll take a time to test it.

We can eventually upgrade it to 1.1.3 if the release occur before the code freeze. But for now it is safer to stick with the stable release.

i'm subscribing here... aside do you know any way to prohibit the annoying error popups created by jQuery (Drupal 5.1) if i'm using IE5.01? I know jQuery does not support IE 5.01, but i simply like to prevent the annoying alert popup... with IE 5.5 there is now error popup.

i'm not enough of a jQuery expert to meaningfully review the jQuery changes themselves. however, i'm happy to report that this patch fixes http://drupal.org/node/134307, which has been bothering me for a while. so, big +1 from me. if i knew more jQuery, i'd closely review and RTBC this...

I gave it a whirl on FF 2 and IE7, here is my report:

[Firefox 2]
Works: autocomplete, cleanurls-settings, collapse, datetime-settings, progress, tableheader, tableselect, textarea, upload
Broken: teaser

[IE7]
Works: autocomplete, cleanurls-settings, collapse, datetime-settings, picture-settings, tableselect
Broken: tableheader, teaser, textarea, progress/upload

here's a safari report:

Works: autocomplete, cleanurls-settings [1], collapse, datetime-settings, progress, tableheader, tableselect, textarea, upload

Broken: teaser

so, looks like teaser is just universally broken...

[1] note: cleanurls-settings works on the admin settings page, but not directly inside the installer. however, that's true before applying this patch, so i think it's just a bug in the installer, not anything specific to jQuery.

subscribing.. will review later this weekend.

subscribe

subscribe

subscribe

@Gurpartap: Your latest patch does only change jQuery to be updated to 1.1.3a,. You forgot to include all the other *.js files which you changed to work. Impossible to test this way...

Please update the issue with a patch that does include both the jquery update and the additional .js files.

When we are at rewriting/updating the jQuery js-scripts, we could also update the way the current collapsible fieldsets are done. Have a look at admin/user/settings after updating your drupal install with this patch.
When you click any collapsible fieldset which has a textarea inside it with a vertical scrollbar, the scrollbar appears before the fieldset is expanded and hides after the fieldset is collapsed.

Maybe we can let the fieldset first expand to the right height, and then show the content? Perhaps that would fix the problem, not sure though.

Needs review.

Last patch file is empty.

Perhaps John resign could also have look at the weird behaviour we are having with the flickering fieldsets, and when we have a fieldset with a vertical scrollbar inside it?

Seems to work right in Safari 2 and FF on Mac..
I'm tempted to set this RTBC, but let's wait for another review...

@Gurpartap Singh: only as a small hint. The copyright notice will be removed by the "JS aggregate and compress" function... :-)

On some further looking, it looks like "admin/build/themes/settings/garland" does apply the choosen color profile to the preview, but not on the global used theme itself.
I am not sure if this is due to this patch or some of the FAPI 3 changes..

Furthermore everything works as expected without any problems! :-)

Patch looks simple and straightforward. One nitpick though:

- "// Scroll the fieldset into view" has one extra space in it's indention then it should be :)

Feel free to RTBC, once it seems that everything still works nicely.

New patch attached, addressed Goba's notice and did a re-roll because 1 hunk failed when applying.

This is ready to go in now...

OK, applied the patch to a local test copy and tested the usual things: table headers, upload, filedets, textare resize, teaser split, date time settings, table row selection, and all seemed to work. Nice job, committed to Drupal 6.x-dev.

drat. oddly, an earlier version of this patch fixed http://drupal.org/node/134307 but i just updated my local test site to today's HEAD, cleared my browser cache, made sure the new JS compressor stuff was disabled, etc, etc, and #134307 is still with us. :( the difference is that the earlier version of the patch also modified tableheader.js, whereas the committed version didn't. is there some reason those changes to the files other than jquery.js were removed from later iterations of the patch?

ok, i'll leave this issue alone. see my latest patch at http://drupal.org/node/134307#comment-254735 to solve that problem. it just takes the uncommitted changes to tableheader.js from the original patch in here, resolves conflicts so it applies cleanly again, and that solves the problem. please review/test. thanks.

The changes to system.css are a direct roll-back of an earlier patch:
http://cvs.drupal.org/viewcvs/drupal/drupal/modules/system/system.css?r1...
http://cvs.drupal.org/viewcvs/drupal/drupal/modules/system/system.css?r1...

Hm, this was the issue (http://drupal.org/node/100668). So it seems that

- the "display: block" removes a gap in Safari between the grippy and the textarea (from #100668)
- but it does introduce a scrollbar to collapsible fieldsets where a textarea is included (from this issue)

So there was a reason to add it and one to remove it. Is there a gap still in Safari? If so, can someone suggest a fix, which does not inhibit any of the two problems? :)

Subscribing.

Where is the "Subscribe/Unsubscribe" button?
I can't find it. I want to track this issue.

Thank you,
Eddie

jQuery 1.1.3 is out, w00000t!

http://jquery.com/blog/2007/07/01/jquery-113-800-faster-still-20kb/

Let's reroll this patch with this rockin' new version!

As you wish M3avrck.. ;-)
Here it is, works perfectly on Mac OS X Tiger (and Leopard WWDC build), in FF Safri 2 and 3b, Camino, Opera. For windows tested on Xp and Vista IE 7/6/5.5, FF, and Opera.

I'm pretty sure this could go in, but would like to see someone else test this..

Testing in FF 2.0.0.4 on Linux:
Fieldsets, attaching files, color picker, openid login block, autocomplete all work like a charm.
"
However, everything fails in Konqueror (3.5.5). Konqueror had always its problems with advanced JS, without the patch, most stuff works, though (fieldsets, autocomplete, ...). With the patch, Konqueror reports
Error: http://home/drupal/HEAD/freeze/misc/jquery.js: TypeError: Null value
Error: http://home/drupal/HEAD/freeze/misc/drupal.js: TypeError: Value undefined (result of expression $(document).ready) is not an object. Cannot be called.

so it seems jQuery doesn't even get unpacked correctly.

Wasn't Konqueror always fucked up with jQuery? i thought so..

Yes, it was kinda. With 1.1.2, the important stuff worked, though (collapisble fieldsets, autocomplete, etc.).

With this patch, Drupal is basically unusable with Konqueror, as collapsible fieldsets can't be expanded.

I'm usually using FF, so I don't care too much. We should look into somehow having all collapsed fieldsets expanded on "unsupported browsers", though, under which Konqueror falls with this patch.

We should look into somehow having all collapsed fieldsets expanded on "unsupported browsers", though, under which Konqueror falls with this patch.

I'm not sure I agree with that idea. It seems like a bit of a slipperly slope to me. How can we possibly test for *all* unsupported browsers and where they do or do not work? To me this would just add unnecessary code. After all, who uses Konquerer that doesn't have access to Firefox, IE, Safari or Opera?

The development community decided to put jquery in Drupal core and according to the jquery site, it does not list Konquerer as a compatible browser. Maybe we should just list it in the release notes as a known issue?

I'm not going to do any more work about this anymore...

Simple fix is to use the new variable:

jQuery.browser.version

We just put this in drupal.js, in the isJSEnabled check and if that evaulates to Konqueror's string, then return false and this prevents any JS from working.

That should be a workaround, but maybe better to add 1.1.4 in one month... i think D6 will be released later... looks more like a bugfix and shouldn't be a problem to commit after freeze. however 800% faster - this must be committed asap...

m3avrck , please do as I can confirm that Drupal is unusable in Konqueror 3.5.6 with this patch.

This Konqueror bug seems to be a jQuery 1.1.3 issue that is being discussed in this bug ticket: jQuery 1.1.3 fails completely in Konqueror 3.5.5 as well as here on the jQuery listserv The milestone says 1.1.4, and so disabling javascript for the Konqueror browser may be the best workaround for now.

I spoke and discussed this with JohnResig, which told me there is going to be a bug fix release today or tomorrow. Currently it seems that jQuery is messing up Konqueror completely and IE is (offcourse) doing nothing with anything that has something todo with opacity. (I did not noticed this while reviewing the former patch... Hmm...)

Perhaps someone wants to update this patch once jQuery 1.1.3.1 is out..

jQuery 1.1.3.1 was just released and is now posted on the frontpage of jquery.com or directly from here.

There were three major bug fixes: Konqueror crashing, IE opacity & Safari 1.3.2 crashing

An updated patch with the latest jQuery version 1.1.3.1 (revision 2243).

Note that the compressed version of jQuery now includes the GPL header and two additional revision lines.
And I manually added the Drupal version update line to the downloaded file.

Earlier versions of this patch included fixes to core's jQuery code to use the new jQuery APIs (at least as I understood them). This latest patch *just* changes the jquery.js file, and nothing else. Is this intentional, or an oversight?

If it's intentional, that'd be helpful to include in your comments when posting the new patch, so people know "yeah, turns out we don't need to even port our .js code since jQuery 1.1.3.1 is so great, it handles everything for us and is 100% backwards compatible". If that's not true, then this patch needs work.

Please advise, lest people needlessly waste time testing something that can't possibly work. ;)

Thanks,
-Derek

I've said *exactly* the same thing to Kentbye some minutes ago on IRC.
He admitted he did not tested this, just did a re-roll of the patch.

I'll test this patch today and try to update our javascript files which need some changing, though I do not suspect there are much - if any - changes needed.

I think KentBye is actually correct. Our Javascript files were updated to the jQuery 1.1. API much earlier, namely when Gabor commited the patch from #26 in #27.
As there aren't any API changes from 1.1.2 to 1.1.3 (at least AFAICS), this is definitely up for review. Stefan, your patch to 1.1.3 in #35 didn't include any changes apart from jquery.js, either.

If this patch is committed, won't the $Date: and $Rev: CVS keywords be updated to details from Drupal's repository instead of JQuery's repository specific Date and Rev? Does this matter?
I don't think $Rev is a CVS keyword (it's SVN) but $Date sure is CVS.

I think $Id$ is enough, it includes revision number and date. This should not be edited, the repository will update this automatically when the file is commited. Anyway, an equivalent to $Rev$ in CVS is $Revision$ and $Date$ is a valid CVS keyword.

@dww: Sorry, I should have expressed my own confusion more clearly, but I'll walk through history of this thread as I saw it to help you and others in case there are future bugs down the road that need to get tracked down. And maybe a new issue should have been created (and may still need to be).

Drupal's commit #69317 by Gábor Hojtsy in #27 applied Stefan Nagtegaal's jquery_17.patch from #26 -- which was a reroll of Gurpartap Singh's drupal6-task_jquery_1.1.x_upgrade_2.patch from #21

So the following four files were affected in commit #69317 which had the commit message of "#146462 by Gurpartap Singh: update jQuery to 1.1.2 and make the core JS files compatible with the new version"

* misc/collapse.js
* misc/jquery.js
* misc/color.js
* misc/system.css

In Gurpartap Singh's original drupal6-task_jquery_1.1.x_upgrade.patch, misc/tableheader.js & misc/textarea.js were changed. But then in #12, Singh said, "For the rest, .width() and .height() are still available for usage in jquery 1.1.x, and hence some files will need no changes. will submit patch as soon as 'm on the ubuntu pc." I assumed that that's why textarea.js & tableheader.js were not in the committed patch.

I saw that this patch was committed, that latest HEAD had jQuery 1.1.2, and that m3avrck had suggested rerolling a patch for jQuery 1.1.3 in #34

So Stefan Nagtegaal changed the title from "jQuery 1.1.x update" to "Update Drupal 6 to jQuery 1.1.3 =)" in #35 along with a jquery-1-1-3.patch that replaced jQuery 1.1.2 with the latest 1.1.3.

I saw that people were testing the patch, finding errors, and Stefan suggested "Perhaps someone wants to update this patch once jQuery 1.1.3.1 is out" in #45, which is what I did in #47 after I had mentally gone through the history above. I used Stafan's patch as a template.

In hindsight, I noticed that this issue was reopened after Steven had questioned the change in misc/system.css in #30

"The changes to system.css are a direct roll-back of an earlier patch" comparing system.css 1.28 to 1.29 with system 1.16 to 1.17

The earlier patch Steven was referring to is #100668, which put the "display: block" into system.css in order to fix a gap between the textarea & grippie within Safari.

It was deleted as explained #21 in order to fix teaser.js. "It was just a css property which the textarea element inherited from container assigned to textareas in textarea.js's .wrap()(which also broke the hiding of other textarea containers)."

In #31, Gábor asked, "Is there a gap still in Safari? If so, can someone suggest a fix, which does not inhibit any of the two problems? :)"

The screenshots from #100668, are no longer online so I'm not sure what the gap should look like. But I don't see any gaps in Safari 2.0.4.

QUESTIONS
Should this task upgrade to 1.1.3.1 be moved to another issue?
Or does this explain it enough to keep the upgrade and all of the people tracking it here?

jQuery 1.1.3.1 causes an error with expanding collapsible fieldsets, and I have a feeling that it's a jQuery bug since the error doesn't currently appear with version 1.1.2. I've found a workaround for Firefox, but not for Safari, and so there is a chance that it might be a Drupal bug and not a jQuery bug. But it's looking more like a jQuery bug at this point.

When I use the uncompressed 1.1.3.1 version of jQuery, I can see that it is crashing at line 2333 with an error of "jQuery.easing[options.easing] is not a function." When stepping through in FireBug, this happens when options.easing is not initialized. The options.easing variable should be either "swing" or "linear," which is a recent fix to how the default animations were handled as explained in this ticket: "Cleanup the built-in "easing" stuff"

jQuery is composed of a number of components, and so line 2333 translates to line 580 of the fx.js component. As you can see in revision 1575 of the fx.js component, there used to be logic at line 580 checking to see if options.easing was initialized.

I'm able to eliminate this error in Firefox by changing line 2333 of uncompressed jQuery.js from

z.now = jQuery.easing[options.easing](p, n, firstNum, (lastNum-firstNum), options.duration);

to

z.now = options.easing && jQuery.easing[options.easing] ? jQuery.easing[options.easing](p, n, firstNum, (lastNum-firstNum), options.duration):

However, this was not able to fix the error in Safari

To reproduce this error on FireFox & Safari:

* Install jQuery 1.1.3.1 onto Drupal6 (either from jQuery.com or applying this patch)
* Create a new page.
* Click on the menu settings once.
* It will expand with a choppy animation.
* Click on menu settings again, and it will hide with proper animation.
* Click on the menu settings again to expand it and the following errors happen:

Firefox 2.0.0.4 will give the "jQuery.easing[options.easing] is not a function" FireBug error about 15 times, but still expand w/ choppy animation.

Safari 2.0.4 will not show anything expanding from that point on.

I'll check into a bit more and file a bug report to jQuery ticket #928.

Attached is a test HTML file that includes all of the CSS and JS (including expanded version of jQuery 1.1.3.1).

I created to submit to jQuery.com if I figure out that this is a jQuery bug. But I'm including it here in case some other people want to help track down the bug described in #54.

Click on "menu settings" three times and the error will appear in Firebug for Firefox or Safari.

In the next round of AHAH updates (continuing http://drupal.org/node/154398) for Drupal core, it is absolutely critical that we use this latest version of jQuery as it makes effects behave properly on table cells and rows. More on that in an issue coming soon :)

In 1.1.3.1, the 'easing' property needs to have a value. Our custom sliding effect didn't include this, causing that nasty round of errors. Here's a patch rolling together the jQuery 1.1.3.1 update and the necessary changes to collapse.js.

Problems described in #54 by Kentbye are still present in patch #56 when viewed in Safari.

I can confirm that quicksketch's patch does eliminates the "jQuery.easing[options.easing] is not a function." error in Firefox by passing in the linear easing function.

Safari is still not expanding the contents of the collapsible fieldset on the third click after being expanded and collapsed once each.
I tried to adding back in the "display: block;" line to the system.css, but it is still didn't collapse properly.
I'm not sure how to get further debugging info for Safari -- possibly the open source Safari webkit?

The color picker works correctly.

Okay, time to give it another round of reviews! This patch now makes the collapsible fieldset work in Safari. Strangely, it's actually removing lines of code. From what I understand, jQuery is now more intelligent about restoring the initial state of items for toggle-like effects Now by removing height: auto (seemed like a hack to me anyway), the fieldset works in all browsers I have on my computer.

I've tested the patch in Safari, Firefox 2, IE6/7, and Opera 9. Let's pave the way for 800% faster jQuery selectors :)

Well, here we go:
- tested ahah.js to work (upload.module);
- tested autocomplete.js to work;
- tested batch to work (with update.php and upload.module);
- tested collapse.js works with attached patch (collapsing fieldsets and such);
- tested tableheader.js to work;
- tested tableselect.js to work (select all on node admin screen);
- tested teaser.js to work (splitting teaser/body on node creation);
- tested textarea.js to work (expanding textarea's);
- tested upload.js to work (upload files using upload.module);

- tested openid's blocks.js to work;
- tested color.modules color.js, which isn't working!
- tested comment.js to work (anonymous user information cookie);
- tested system.js to work (clean url's on install/admin-settings, time-zone suggesting and hide/show things);
- tested user.js to work (password strength check, picture settings hide support);

So, only color.js is left broken right now.

The only thing i changed is the effect of the collapsing/expanding to be a little faster, so it'll be less annoying for the people who suggested that.

Now, let's try to fix color.js and try to get this in... :-)

i gave this a review and did a re-roll of the patch, including some changes:
-

KentBye reported that the color picker was fine in #58, and I confirm that it works fine for me in IE, FF, Safari, Opera. What is it that doesn't work?

Well, the color picker is working, but the generated colorized Garland theme isn't set as the default on my install.
Though, I'm not getting any errors and the images and css _is_ generated inside the files directory. Strange...
Could anyone reproduce this?

The problem with color.module not generating the theme properly is a separate issue. I've isolated the problem and posted a fix: http://drupal.org/node/158559.

Since there's nothing broken on the javascript side, I think this is good to go! The list of changes seems to have been cut off of Stefan's post, but the only change was setting the duration of the effect to 'fast' rather than 300.

Yup, sorry...

IMO this is a go! :-)

Both of the patches in #59 and #60 fix the collapse in Safari. And they both actually make the Firefox collapse function not so jumpy. It's smooth and works great. I don't see much difference between a medium collapse (#59) vs. a fast collapse (#60), so whichever the commiters prefer.

So I think either one of these patches are ready to go in with the following caveat -- that jQuery 1.1.4 is slated to be released in 2-3 weeks and that there are going to be some deprecated jQuery functions in preparation for jQuery 1.2, which is going to be released at the end of August.

So Drupal 6 will probably be released after August, and so I'd suggest taking a look at some of theses deprecated functions now to get ready for 1.1.4. So from the jQuery 1.2 Roadmap, the following functions are likely to be removed and replaced with the alternatives listed in parentheses

The following are pieces of functionality that may be removed in jQuery 1.2.
    * Selectors
          o .. selector support (in favor of using .parent())
          o / selector support (in favor of using >)
          o // selector support (in favor of using ' ')
          o [selector] selector support (in favor of using :has(selector))
          o [@attr] selector support (in favor of using [attr]) 
    * DOM
          o .clone(Boolean) (in favor of using .clone().empty() instead) 
    * Ajax
          o .loadIfModified() (in favor of using $.ajax())
          o .getIfModified() (in favor of using $.ajax()
          o .ajaxTimeout() (in favor of using $.ajaxSetup())
          o .evalScripts() (in favor of native support in append, et. al.) 
    * Misc
          o .lt(), .gt(), and .contains() (in favor of using .filter(':lt(0)'), etc.) 

Should we check now to see if we're using any of these functions that are on the chopping block, and replace them with the suggested alternatives?

I'd really prefer to get this version in and then upgrade to the next ones as they roll out. Functionality increases and the especially the bugs fixed dealing with toggle effects are necessary for operations on tables. I'm waiting on this version of jQuery to go in before we can add the live updating of tables (such as the weights and regions on the blocks page). See http://drupal.org/node/157752.

This issue is long enough already. Let's open another one for the next update.

Committed to CVS HEAD. Thanks.

Woot! Thank you Dries.

this commit broke that:
http://drupal.org/node/159097