This applies to ajaksu's test setup.

What steps will reproduce the problem? 1. Create a survey 2. Click on link_id field 3. Try to read tooltip before it fades

What is the expected output? What do you see instead?

The link_id tooltips contain the wikipedia ASCII link. In a tooltip, this is not clickable, shown in raw HTML and actually reduces the readability of the tip.

On what URL are you testing (e.g. http://socghop.appspot.com)? http://melange-ajaksu.appspot.com, 2009-06-23, 06:00 UTC

This is a copy of the github tracker bug 37, after the devs decided this would be the better place to file bugs.

Here is a quick fix to show the links instead of HTML code. Link doesn't work in my box though.

What do you mean by link doesn't work in my box?

With the patch, the link is correctly displayed in the purr tooltip, but, if I click on it, it doesn't redirect me to the linked page. Don't know if this is an issue derived from |escapejs django filter. I was looking for a way to escape only double quotes to try again but didn't find any (nor a replace filter). The patch can be pushed, at least to solve the readability issue. That should be the path to resolve the issue completely, however.

Maybe the |safe filter wll do the trick?

Ok, so, it's not a problem of Django filter. Patch is ok for readability, but however the link won't work, because we attach an event handler to show/hide the tooltip on every input field on focus and on blur. There is no easy crossbrowser way (AFAIK) to know which element has gained focus, so I've tried to attach an "on focus" event handler to the tooltip to set a variable, but then it happens that the onblur event fires always before any onfocus event, so the variable is never set. We may try to use event capturing (which also has its crossbrowser hassles), otherwise if there's agreement on fixing this rather than not using links at all and we don't find another simple solution, I think we need to change the overall logic of the purr tooltips.

Maybe we shouldn't use links in tooltips then and only abuse the example column to the right of the input for this?

yes that is a good idea. The links were used previously because they were in separate column but since we are using tooltips now I agree with Lennie.

Could you elaborate I don't get your comment :(.

I agree that we should put the links to the example column only.

I agree too, also since the link to the ASCII table can be assumed as "an example" :) However if we ever want something in the purr tooltip to be clickable then we need to change the logic. Patch still can be useful to escape characters that potentially can cause Javascript errors and to display HTML inside the tooltips.

Commited the fix in r2751a2462b.

Conclusion for now is don't use links in tooltips :).

Issue 670 has been merged into this issue.