As demonstrated on TWiki:Codev.SomeBrowsersLoseMoreNewlines
some browsers loose either trailing newlines (Konqueror 3.4.2) or both leading and trailing newlines (Firefox 1.5) when text is passed in hidden URL parameters.
We struggled around a similar issue with the textarea TWiki:Codev.SomeBrowsersLoseInitialNewlineInTextArea
and fixed it by sending a blank before the leading newline.
We need to do something like that also when sending through hidden parameters (e.g., when going from edit to save). It can be easily verified that these newlines disappear.
I set this as "requirement" as I assume that no text should be lost. -- TW
I am putting spaces around the passed parameter, albeit there might be a better strategy. -- TW
There is no obvious systemic solution to this. Anyone can slap a hidden parameter anywhere in a topic, in a template, or in a plugin. We could certainly work around it, but wouldn't a better strategy be to drive back on the people who write the broken browsers? CC
I can't reproduce this; can you please privode a recipe for demonstrating the problem? Thx,#
Please go to TWiki:Codev.SomeBrowsersLoseMoreNewlines
and try with Konqueror 3.4.2 or Firefox 1.5. (See above.) -- TW
No, I understand the principle
, what I can't find is any specific case
of this in the TWiki code. I think we need to HTML encode hiddens. Realising this I recently added
; but I need to know where it is used to be able to apply it. And there is no simple fix for user-entered hiddens, like the ones in your example
0h, sorry. I ran into this in the plugins that are based on TWiki:Plugins.EditContrib
. You can see this behavior also when you go into preview before saving. -- TW
OK, I understand. You can deal with this behaviour as follows. Instead of using a
for a multi-line value, use:
My multiline text
As far as I can tell there is no problem in the core, so I have to discard this. Re-open it against an extension if you need to track.