Item9739: upgrade to jquery-1.4.3

For now foswiki-1.1.0 will most probably default to jquery-1.3.2. However, this is showing its age with more 3rd party plugins requiring at least jquery-1.4.2. So it would be good to fix all remaining points. Please make a list of problems you've found switching JQueryPlugin to jquery-1.4.2. Watch out for any JSON related.

Status

• chili-2.2 ... been patched as part of Item8666
• livequery ... reported to fail, test case plus patch available here, latest version fixes it.
• validate ... reported to fail, needs upgrade to at least v1.7 which fixes compatibility
• blockui ... reported to fail, needs upgrade
• form ... needs testing
• ...

-- MichaelDaum - 22 Sep 2010

This sounds familiar. Last time I was digging around using 1.4.2, it seemed that $.live() is an almost-replacement for $.bind() which works on DOM elements that haven't been created yet. Which I suppose does pretty much most of what livequery does, it's just now a standard part of jquery api.

It might explain why there's lack of 1.4.x fixes for livequery?

Now I guess we need a LIVEQUERY.pm which will load a different jquery.livequery.js depending on whether 1.3.x or 1.4.x is configured. If 1.4.x, probably load some js that wraps $.livequery to $.live somehow - not sure if this is trivial or even possible.

-- PaulHarvey - 22 Sep 2010

live() is not a replacement for livequery(). While the former depends on an event to fire, the latter is a live query. So while live() matches on bind(), livequery() matches on each().

This exactly the way we use livequery() for and that is not supported by live(). This is a critical requirement for jQuery in foswiki.

-- MichaelDaum - 23 Sep 2010

Testcase for the livequery problem:

<literal>
<script>
function turnPink(element) {
  jQuery(element).attr('style','background:pink;')
}

jQuery(function($) {

  $('.pretty_bird').livequery(function() {
    turnPink(this);
  });

  $('.whos_pretty').load('%SCRIPTURLPATH{"view"}%/%WEB%/%TOPIC%?section=mo_pretty;skin=text');
});

</script>
</literal>

<div class='pretty_bird'>
   I should be pretty
</div>
<div class='whos_pretty'>
  %ICON{"processing"}%
</div>

<verbatim class="foswikiHidden">
%STARTSECTION{"mo_pretty"}%
<div class='pretty_bird'>
  I should be pretty
</div>
<div class='pretty_bird'>
  I should be pretty
</div>
%ENDSECTION{"mo_pretty"}%
</verbatim>

-- MichaelDaum - 23 Sep 2010

In general jquery-1.4.2 is more restrictive in what it consideres valid JSON. So a JSON objects of the form

   {‘name’:'jQuery’}

   {interest:’Programming’}

   {‘balance’:443.25}

aren't considered valid anymore. Double quotation marks are now a must for both keys and string values. Boolean, array, numerics etc are still okay unquoted. So switching from jQuery-1.3.2 to jQuery.1.4.2 might break custom code independent of what is shipped in foswiki-1.1.0

-- MichaelDaum - 23 Sep 2010

I cannot see why this is an urgent release blocker. And it has been open for a month.

As long as the JQuery we ship works with the version of jQuery we use it cannot block a release.

Lowering to Normal.

-- KennethLavrsen - 24 Oct 2010

/me working on updating jquery modules, including jquery-ui.

This means that we will have to abandone jquery-1.3.2 as the latest modules are rather incompatible with the old jquery-1.3.2.

The latest jquery-1.4.x release is jquery-1.4.4. This release changed some semantics the way width() and height() work causing trouble for at least JQGridPlugin. jqgrid is just fine using a jquery-1.4.3, but not with 1.4.4. We will have to wait until the jqgrid people get that fixed.

So it makes sense to default to jquery-1.4.3 ... which is decent enough, but not pushing the envelope for the other modules too far ahead.

-- MichaelDaum - 30 Nov 2010

Paul, please leave this task in wainting-for-release until foswiki-1.1.3 is released. Only after will this be switched to closed.

-- MichaelDaum - 31 Jan 2011

Commenting is disabled while not logged in