Item9492: JQueryAjaxHelper adds nops to result from user section

This example shows the problem

I raise it as an urgent bug because we use this in core functionality now such as adding users to groups

Must be viewed in trunk and it must find a user. Try and search for me.

When you ajax returns a hit select it and note that it puts a <nop> in front of the returned name and this goofs the applications that need the result without a nop

If I remove the nop from the JQueryAjaxHelper topic then the darn thing gets rendered instead with href and everything. We need the raw result

No such plugin autocomplete

It does not seem we have JQuery installed in trunk.foswiki.org so you need to copy the example locally

-- KennethLavrsen - 18 Aug 2010

Apparently ?contenttype=text/plain doesn't remove on trunk, so we have new Foswiki.pm or Render.pm bug

• trunk: ?skin=text;contenttype=text/plain
• release: ?skin=text;contenttype=text/plain
• <nop>:

-- PaulHarvey - 19 Aug 2010

Re-assigned to engine. George mentioned Item9432

-- PaulHarvey - 19 Aug 2010

For some reason foswiki does not process nop, noautolink and the like when contenttype=text/plain. The ajax helpers must be called without. Then they do fine.

-- MichaelDaum - 19 Aug 2010

The issue in trunk - not sure why not in 1.0.9, is that content-type=text/plain is handled as if it is raw as well. I believe the Foswiki::writeCompletePage now operates similar to 1.0.9 - removing <nop> and <noautolnk> for everything except content-type=text/plain. However in 1.0.9 they still get removed but I have not found where.

I suspect that text/plain should remove all html markup, and raw= processing should not be overlapped with text/plain. Not sure how/where to fix yet, but I suspect the change to call without text/plain is probably not the right fix.

-- GeorgeClark - 19 Aug 2010

Commenting is disabled while not logged in