Topic awaiting preservation: limits in input type hidden?

I'm working with an admin page that uses a combo of php, javascript and an iframe (supposed to be IE only)

As I generate the page from php for edit, I first place the main-text coming from the db into a hidden field on the page, then I transfer this text by onload="javascript:setDataInEditor();" of the iframe, to the iframe that holds a wysiwyg tool, thus making it ready for editing.

This works fine using this principle:

function setDataInEditor(){

    data = document.forms["updatePageForm"].temp.value;

    window.frames['editor'].document.getElementById("tbContentElement").DocumentHTML = data;

    }

Then, as I submit the form on tha mainpage I call onclick="javascript:getDataFromEditor();" this looks like this:

function getDataFromEditor(){

    document.forms["updatePageForm"].content.value ="";

    editorText = window.frames['editor'].document.getElementById("tbContentElement").DocumentHTML;

    alert("variable editorText: "+ editorText);

    document.forms["updatePageForm"].content.value = editorText;

    document.forms["updatePageForm"].submit();

    alert("submitted");

    }

This works, BUT it sometimes breaks if the content is too long (mostly somewhere around 650 chars clean text, less if it's HTML in there) giving me a syntax error pointing to this line: document.forms["updatePageForm"].content.value = editorText;

The text that is handled here can contain html and/or \n , this I take care of in php as I load it into the editor and as I recieve it from the editor, making sure I have \n for the editor and <br /> in the database for presentation I also take care of " ' \ / ; and so on.

I havn't been able to figure out if it's the HTML, the \n, or the actual length, or something else that creates the error, I can't find a pattern...

I could probably fix it by generating the wysiwyg on the mainpage without using an iframe, but I'd like the flexibility that the iframe offers for later upgrades.

Does anyone have any tips on this?
/Dan



{cell 260}
-{ a vibration is a movement that doesn't know which way to go }-

Well, I don't know if you're posting the form or getting it, but if you use post it doesn't seem likely to be a php-error. Now should it be a html-error, a dirty trick like this might come in handy:

<form>
<textarea rows=40 cols=40 style="visibility:hidden">
Bladibla
</textarea>
</form>

First, you need to understand the difference between an event handler and a Javascript URL.

A Javascript URL is used when a regular URL is expected. For instance, the href property of a link:

<a href="http://blah"></a>
can also be
<a href="javascript:dosomething();"></a>

An event handler, however, does not expect a URL. It expects Javascript code. onclick, onmousedown, onload, etc, are all event handlers, and they expect Javascript - *not* Javascript URLs. So in those types of html attributes, you should not use the prefix "javascript:". That is only used where a URL is expected. For instance:

<a href="javscript:void(0);" onclick="dosomething();"></a>

If the onload and onclick events are working with the javascript: prefix, then it's just because your browser (probably IE) is being nice to you.

I'm not really sure what's causing the problem you mention. It doesn't make much sense that you'd get a syntax error only in certain cases but not in others. Try running on a different browser and see what *it* tells you.

Nevel; the textarea trick did not work, same error...

Slime; Thanx for the tip, I usually remember this, don't know why I missed that this time...
didn't change anything though.

Mozilla refused to load it into the form in the iframe at all
/Dan

{cell 260}
-{ a vibration is a movement that doesn't know which way to go }-

I bet it may have to do with the included content. I'm running into this with an application I'm writing. Are there any funky characters in the included content? especially quotes, single (apostrophe) or double quotes the included content will throw an error.

It's a pain in the ass to deal with.



.:[ Never resist a perfect moment ]:.

Bitdamaged, that was my thought as well.
The thing is that it f**ks up even when it gets one long line with clean text, no html or \n or anything, it only takes more chars before it breaks.

As for funky chars... As I get text from the editor for storage, I run it through this php-function:

function formatData($string){

    $string = trim($string);

    $string = str_replace("\n","<br />",$string);

    $string = addslashes($string);

    $string = str_replace('"',"'",$string);

    return $string;

}

Then as I pick it up for the editor, I do this in php:

function unFormatData($string){

    $string = stripslashes($string);

    $string = str_replace("<br />","\n",$string);

    return $string;

}

This will cause the output that is stored in the value of the hidden field to have \ ' " NUL in it which might cause the error, but if I don't remove those it won't produce correct output to the editor then creating total havoc of the code when edited and resaved... sigh.

Still doesn't explain why it breaks on long single line clean text though...
/Dan

{cell 260}
-{ a vibration is a movement that doesn't know which way to go }-

as far as i have experienced, the hidden fields when posted back and forth from and to php no limits errors appear.

i even javascript.escape() some of the data which contains unicode characters (thus tripling the space needed to store the data)...