Update to jQuery 1.3.2

subscribing.

Subscribing.

We have two choices:

1. Commit this without manual testing and fix/report bugs as we find them.
2. Do at least cursory testing in all major browsers for uploading, teaser splitter, sticky tableheaders, drag and drop, color.module, fieldsets (and etc.) before we commit.

Which option is best probably depends on whether an real humans visit Drupal 7 pages other than admin/build/testing - not sure what the answer is to that.

@catch I vote for option two. God knows none of the devs use IE on an extremely regular basis for D7 dev.

In that case I refer the gallery to http://groups.drupal.org/node/5974

However, I'm not at all interested in doing this - especially since we'll have to do it all over again for each jQuery beta then RC for the next few weeks/months until a full release - and also because there's pretty much zero chance that we'll release Drupal 7 with an extremely outdated jQuery version.

So if no-one steps up, rather than holding our breaths I think we should go for option #1 - I know a couple of people are running personal/testing sites on D7 and keeping contrib modules up to date on it, so we should at least be able to cover ff/opera for that.

@catch That makes sense, and I certainly won't block efforts to include jQuery 1.3 betas in HEAD now. I was simply arguing for a one-time "check if jQuery 1.3 Beta 1 breaks anything obvious" check. After our initial inclusion of jQuery, we shouldn't see enormous numbers of changes.

As far as I know, we try to *never* commit untested code. So I vote for option #2.

Due to the time it takes to test a jQuery to the point where it will be committed I would suggest waiting until jQuery 1.3 is actually out. I did it for jQuery 1.2.6 so I know it takes time.

If someone wants to do it to provide feedback for the jQuery team go for it.

I'm rather opposed to this. Our friends at jQuery have proven many times that they know how to break functionality in minor versions, i.e. point releases. IMHO, it adds enough burden to us when we have to deal with those issues in a 1.3.1 to 1.3.2 maintenance releases. Bear in mind that our Drupal jQuery gurus can work on more interesting stuff than fixing weird compatibility issues at this point in time.

jquery 1.3 was released today FYI

From the list at http://groups.drupal.org/node/5974#javascript what still needs to be tested?

Subscribing. :)

subscribing
@Rob Loach - I got really excited when I first saw .live, but I don't think it is powerful enough to replace Drupal.behavior. It can only attach to a handful of event types, so, for example, there would be no way to attach to the scroll event in the tableheaders behavior. Maybe I am missing something though.

See also #335931: IE7 sticky table header does not work for the IE tableheader problem.

@starbow you can create your own event types and they work with .bind and .live. But, that is for another time. Once we get jQuery 1.3 in core, perhaps.

Subscribing...

subscribing

Just to keep the ball in play, here is the patch with the tiny change needed to get it to apply against head as of this moment.

I did some light testing in FF3, taking a look at the Article create page (autocomplete, teaser splitting, text area resizing, and collapsible) and the Navigation Menu page (tableheaders and table drag+drop). The Navigation menu page works fine, but the Article create page is kicking up on of those "Warning: Unresponsive Script" boxes. It seems to be stuck in line 19, which is the big old Sizzle min line. IE7 generates a similar "Stop running slow script" box.

On the node/add/[type] pages the error seems to be coming from textarea.js and the line that says:

if ($(this).is(('textarea.teaser:not(.teaser-processed)'))) {

In particular it gets stuck further down in the is method.

The problem noted in #27 is a jQuery bug that will be fixed when 1.3.1 is released. This is expected in the next week or two. The issue details are at http://dev.jquery.com/ticket/3837.

1.3.1 has fixed whatever what triggering the infinite loop on the Article creation page.
What is the state of the art for testing behaviors?

Ok, this is my first patch to go into automated testing. Can someone help me interpret "Failed: Invalid PHP syntax." (http://testing.drupal.org/pifr/file/1/350275_4.patch)? Is my patch in a bad format (it's what eclipse kicks out), or is there actually something wrong with the code, and if so, where?

Checking the patch now...

The patch applied fine for me, and I didn't get syntax errors on PHP 5.2.8. Here's a reroll-ish thing for good measure.

Note: The OpenID thing was my bad, and is being fixed as a follow-up to #287178: Use hook_form_FORM_ID_alter() where possible (pending test coverage).

subscribe

jQuery 1.3.1 regression.... $(document).ready() fires after images load in ie. Details at http://dev.jquery.com/ticket/3988 and http://stackoverflow.com/questions/477463/jquery-is-waiting-for-images-t...

@#40
A fix for the regression landed in svn.

http://dev.jquery.com/changeset/6170

Tum te tum.. :P

Note: noticing that tabledrag is not working anywhere after upgrading to 1.3.1

Sorry, this may be the wrong place for this since I'm still using D6....

Wow, that tabledrag bug is an infuriating one to debug. Here's the error that gets logged to the console in Firebug:
Node cannot be inserted at the specified point in the hierarchy" code: "3
[Break on this error] this.parentNode.insertBefore( elem, this.nextSibling );

It's something to do with finding the target row (Drupal.tableDrag.prototype.findDropTargetRow) I guess. You can drag the rows right out of the DOM, they just disappear... The positioning seems to be off, i.e. where it's calculating mouse position and element offset. So maybe it's having trouble matching that up with what the target row should be. Or something. I don't know, I'm giving up for the night...

Subscribe.

jQuery 1.3.2 is out (http://docs.jquery.com/Release:jQuery_1.3.2) and the tabledrag bug has not magically disappeared I'm afraid... :-(

I've done some more playing around with this and have established that the specific change in jQuery that is causing tabledrag to break is the domManip function. The old version of this function looked like this:

	domManip: function( args, table, reverse, callback ) {
		var clone = this.length > 1, elems;

		return this.each(function(){
			if ( !elems ) {
				elems = jQuery.clean( args, this.ownerDocument );

				if ( reverse )
					elems.reverse();
			}

			var obj = this;

			if ( table && jQuery.nodeName( this, "table" ) && jQuery.nodeName( elems[0], "tr" ) )
				obj = this.getElementsByTagName("tbody")[0] || this.appendChild( this.ownerDocument.createElement("tbody") );

			var scripts = jQuery( [] );

			jQuery.each(elems, function(){
				var elem = clone ?
					jQuery( this ).clone( true )[0] :
					this;

				// execute all scripts after the elements have been injected
				if ( jQuery.nodeName( elem, "script" ) )
					scripts = scripts.add( elem );
				else {
					// Remove any inner scripts for later evaluation
					if ( elem.nodeType == 1 )
						scripts = scripts.add( jQuery( "script", elem ).remove() );

					// Inject the elements into the document
					callback.call( obj, elem );
				}
			});

			scripts.each( evalScript );
		});
	}

And here's the new version:

	domManip: function( args, table, callback ) {
		if ( this[0] ) {
			var fragment = (this[0].ownerDocument || this[0]).createDocumentFragment(),
				scripts = jQuery.clean( args, (this[0].ownerDocument || this[0]), fragment ),
				first = fragment.firstChild;

			if ( first )
				for ( var i = 0, l = this.length; i < l; i++ )
					callback.call( root(this[i], first), this.length > 1 || i > 0 ?
							fragment.cloneNode(true) : fragment );
		
			if ( scripts )
				jQuery.each( scripts, evalScript );
		}

		return this;
		
		function root( elem, cur ) {
			return table && jQuery.nodeName(elem, "table") && jQuery.nodeName(cur, "tr") ?
				(elem.getElementsByTagName("tbody")[0] ||
				elem.appendChild(elem.ownerDocument.createElement("tbody"))) :
				elem;
		}
	}

If you rebuild jQuery swapping out only this function (and changing the four functions that call it - append, prepend, before and after - so that they pass in the correct arguments) for its older counterpart from jQuery 1.2.6, the blocks tabledrag works perfectly.

The specific place in tabledrag.js where this becomes problematic is the swap function, i.e:

Drupal.tableDrag.prototype.row.prototype.swap = function(position, row) {
  $(row)[position](this.group);
  this.changed = true;
  this.onSwap(row);
};

This code is basically calling .after() or .before() depending on the direction of the mouse movement, if I'm understanding it correctly.

I think we need quicksketch to look at this...

Actually, I just had a quick look in the jQuery bug tracker for anything related to domManip, and there's a related issue:
http://dev.jquery.com/ticket/4087
They ask "So how did you come up with this case? Is there some more complex code where you end up trying to insert a node after itself?"
If some more people could take a look at this, maybe we could plead our case to the jQuery folks that tabledrag.js in Drupal is indeed a more complex case that requires that old functionality back. Or maybe there's a change that can be made in tabledrag.js that will get around this...

Subscribing.

Thanks katbailey for finding the source of the problem. With that information I found a work-around (but not a final solution!) that makes the blocks page work just fine.

The jQuery bug noted above (http://dev.jquery.com/ticket/4087) does indeed cause the disappearing table rows. However, it's not because we actually need to insertBefore/After on the same element that is being moved. It looks like what's happening is our math must be off somewhere, and tableDrag is trying to swap a row with itself, rather than the row above/below it.

So, this patch is a "bandaid" and definitely not what I'd recommend as our final solution. It simply puts an IF statement in the swap() method and keeps tableDrag from trying to swap a row with itself. The better solution would be to fix our math (where ever that is) instead, so the row doesn't try to swap with itself to begin with.

Here's an improved version that I'd find acceptable. It looks like what I did previously actually was intentional, since we want the row to start moving even before the cursor leaves the row as it feels more responsive that way. However, we definitely do not want the row attempting to swap with itself. It seems this problem exists even in the D6 version, but it's just that jQuery was fine with attempting to swap an item with itself.

This version fixes the swapping problem. Since we're in tabledrag.js, I also converted some of our functions to use the jQuery dimensions plugin. There's no need for us to make our own calculation functions when jQuery provides (probably a much better one) for us.

Hmm, that's odd. I just noticed that exact error while reading through the jquery.form.js file. It's a hard-coded string, and apparently jQuery forms just doesn't think that buttons should be named submit, but only when uploading files. The author just recently moved the project to github so the entire SVN history is lost.

Note the problem is only when the name attribute is "submit", <input type="submit" name="submit" value="Upload" />, the value attribute should be fine.

Updated patch with version 1.3.2 with proper comment version.

I tested extensively using webchick's Javascript testing checklist (http://groups.drupal.org/node/5974) against IE6 & 7, Safari 3.2.1 Mac, Opera 9.64, and FF3.0.7.

This patch is RTBC.

For good measure, I just tested Google Chrome 1.0.154.48 in WinXP. Passed as well.

Marking RTBC unless someone says otherwise..

Tested and looks good to me as well.

Committteeeedddd!!!! YAAAAYYYY!!!

This patch brought to you by delicious Chunky Monkey. :D

This needs to be documented in the upgrade docs.

CVS $Id$ got lost in the the shuffle...

There's also an issue in Garland and FF that I'm working on. :)

Confirmed in FF3 Mac. Space gradually grows as you drag on/off. Any ideas to what's causing that extra pixel?

As he mentioned in #53, quicksketch made other changes so as to use the positioning/offset stuff that's now built into jQuery itself - this looks to me like it could be a side-effect of that.

The issue is only in FF on garland and minelli. It seems to be related to the hidden tr that displays the message when nothing is in the region. If the display:none attached to that tr is removed or the tr is deleted from the page the problem goes away.

As with other fixes in garland and minelli for FF we might need some FF specific CSS to fix this. See https://developer.mozilla.org/en/CSS_Reference/Mozilla_Extensions for more details.

I tried installing this patch in my drupal 6.10 with Gallery2 website and the patch had many errors on install. I dropped the patch into my drupal misc folder and then ran it through putty. I could have sworn that the page I got the patch from was for 6.x though I note now that this version is for the 7.x branch?

Here is a sampling of what I received through putty:
xxxxxxxx@handymanreality.com [~/public_html/misc]# patch -b < jquery_19.patch
patching file ahah.js
Hunk #1 succeeded at 181 (offset -3 lines).
patching file jquery.form.js
Hunk #1 FAILED at 2.
Hunk #2 FAILED at 10.
2 out of 2 hunks FAILED -- saving rejects to file jquery.form.js.rej
patching file jquery.js
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file jquery.js.rej
patching file tabledrag.js
Hunk #1 succeeded at 203 (offset -3 lines).
Hunk #2 FAILED at 483.
Hunk #3 succeeded at 501 (offset -2 lines).
Hunk #4 succeeded at 519 (offset -3 lines).
Hunk #5 succeeded at 533 (offset -2 lines).
1 out of 5 hunks FAILED -- saving rejects to file tabledrag.js.rej
patching file teaser.js
Hunk #1 FAILED at 8.
Hunk #2 FAILED at 85.
2 out of 2 hunks FAILED -- saving rejects to file teaser.js.rej

To get myself out of the situation I simply downloaded a fresh copy of 6.10 and replaced the misc directory with the downloaded one.

Of course I still have trouble with scripts that are slow or not responding from my browser usually on the build/modules pages as well as the permissions pages.

kewlguy, this patch is for D7 only. you're going to have zero luck getting this to work with D6.

An issue we have is that on the blocks page, when garland is your theme, and you're using firefox and you move blocks to the top of a region there is a 1px growth each time. It's rather strange.

Attached is a 'hack' (at least I think it is) which switches from CSS display to visibility for FF. With this change it works correctly. But, it doesn't fix the root of the problem... what ever that may be (I'm still not sure).

I would prefer a better fix for this problem. The 1px issue seems to surround the hidden row that holds the message when there are no blocks in the region.

One initial note: turning border-collapse off and on in Firebug kills the ghost space in FF3/Mac.

In this patch I turned off border-collapse, set the borders to 0 for the table, and added the borders from the rows to the td elements in the rows so they visually look the same.

Thoughts?

Of course, the border-spacing property is not supported by IE....

This patch fixes it. Just adjusts the borders...

Great! I confirm this gets rid of that silly border problem. However, "sometimes" I get this sort of 3/4 shading thing:

I'm really trying to remember what I did to accomplish this. I'm thinking it was something like drag a block up two spaces, then back down one, but I really don't know. :(

Could you take a look and see if you get the same thing?

[edit: now with proper input format. ner.]

I was able to duplicate the issue webchick noted in #76. I was, also, able to duplicate it in drupal 6 on a live site in both safari and FF. See http://skitch.com/mattfarina/befwj/drupal-6-blocks-sorting-visual-bug. So, that bug isn't related to this issue.

Turns out the problem was in the tabledrag.js code. The attached patch fixes the growth issue in FF as well as a issue in Safari/Chrome/Webkit Head that caused some 1px jumping. I tested in safari, chrome, webkit head, FF, IE6, and IE7.

Filed an issue for the bug webchick noted in #76 at #403028: Block page color issue

Tested on IE6/Win, IE7/Win, FF2/Mac, FF3/Mac, and Opera9.63/Mac.

Drupal 7 Garland now behaves exactly the same as Drupal 6 Garland. There are still two issues in Garland itself, which mfer is going to file issues for.

The first existing issue is where the top item in FF will always become too tall after a drag. It also exists in a bone-stock 6.10 install, so we're no worse off: http://skitch.com/00sven/bekfq/blocks-localhost .

There continues to also be a strange issue with the grippie and the top border on IE6 / 7, but again, this appears in both Drupal 6 and 7 and thus is not new: http://skitch.com/00sven/bekji/boot-camp-partition.

Rock on!

Oy. Also tested on Safari3/Mac.

Awesome, thanks!

Committed with some minor whitespace fixes and comment wrapping.

Thanks Steven. The two issues he noted are at #404298: Incorrectly sized blocks on the blocks sorting UI and #404302: Improve tabledrag grippie CSS (and fix an IE7 alignment issue)

Oh wait. Except it still needs upgrade documentation. Back to CNW.

Documentation added.

Now that I have all JavaScript freaks in one issue - eat this: #418304: AJAX/AHAH requests are hitting server twice ;)

Either we have a critical JS bug in core or jQuery 1.3 contains this critical bug.

There was a change in the ahah code for drupal. The change was:

@@ -184,12 +184,8 @@ Drupal.ahah.prototype.success = function
   }
 
   // Determine what effect use and what content will receive the effect, then
-  // show the new content. For browser compatibility, Safari is excluded from
-  // using effects on table rows.
-  if (($.browser.safari && $("tr.ahah-new-content", new_content).size() > 0)) {
-    new_content.show();
-  }
-  else if ($('.ahah-new-content', new_content).size() > 0) {
+  // show the new content.
+  if ($('.ahah-new-content', new_content).size() > 0) {
     $('.ahah-new-content', new_content).hide();
     new_content.show();
     $(".ahah-new-content", new_content)[this.showEffect](this.showSpeed);

But, I don't see this code causing ahah to call back twice. Can you provide steps to reproducing the problem?

hey can u tell me to upgrade jquery to jQuery Update 2.x (which includes jQuery 1.3.x)

i got patch files bt i dnt hv any idea where to plce this code to which file i hv to update
.which file i hv to update plz give me a detail step by step procedure to update my jquery

53: jquery_13_upgrade.patch queued for re-testing.