I'm losing the content of a textarea in MSIE. (No problem in the other browsers.) Running short of ideas. I load .js files in this order: main, build, run. "main" does some bookkeeping. "build" creates the UI. "run" contains all the event handlers. At the last line of "run" it calls main.attach_event_handlers(). ("Build" cannot attach event handlers because the event handlers don't exist until after "run" is loaded.)

I've set alerts at various places, so I see the textarea's value is correctly updated. (The textarea is visible when the alerts happen.) My last alert follows the call to main.attach_event_handlers(). The textarea is good. I click to dismiss the last alert and the textarea is truncated to the very first line written to it.

I'm quite certain that the textarea is good after my JS has run to completion. Something in MSIE is changing textarea.value to an early form. Anyone?

MSIE 8 bug.

Browser was remembering an initial value. Closing / reopening browser got the good stuff. However, this means that MSIE cannot be used to run my application. Still in need of some way to force new values into the textarea

Not sure if it is a bug. I would say it is the way IE caches web content and it is different from other standard browsers. Therefore, you may not expect the same behavior on IE if you have been familiar with other browsers already.

Not sure if it is a bug. I would say it is the way IE caches web content and it is different from other standard browsers. Therefore, you may not expect the same behavior on IE if you have been familiar with other browsers already.

"Other standard browsers"? Are you affiliated with Microsoft? MSIE is not a "standard" browser. Should we discuss opacity? Or borderRadius? Or the fact that I can't run the beta MSIE 9 because I choose Windows XP for when I'm forced to Windows?

foo = document.getElementById( 'myTextarea' );
foo.value = "xxx"

I want myTextarea to show "xxx". If it does not, and in MSIE it does not, it is a bug.

Can you post a copy of your code so we can see it?

Try textarea.innerHTML instead of textarea.value .

Both generally work though .innerHTML is more logical given that, in (X)HTML the value is set between the tags, not as a value="..." attribute.

Airshow

Just ran two tests.

Test 1

onload = function(){
	var t = document.getElementById('t');
	alert([t.value, t.innerHTML]);
	t.innerHTML = 'Text 22222';
	alert([t.value, t.innerHTML]);
}

IE6 : ORIGINAL Text,ORIGINAL Text then Text 22222,Text 22222 .
FF-latest : ORIGINAL Text,ORIGINAL Text then Text 22222,Text 22222 .
Opera-latest : ORIGINAL Text,ORIGINAL Text then Text 22222,Text 22222 .

Test 2

onload = function(){
	var t = document.getElementById('t');
	alert([t.value, t.innerHTML]);
	t.value = 'Text 22222';
	alert([t.value, t.innerHTML]);
}

IE6 : Text 22222,Text 22222 then Text 22222,Text 22222 .
FF-latest : Text 22222,ORIGINAL Text then Text 22222,Original Text .
Opera-latest : Text 22222,ORIGINAL Text then Text 22222,Original Text .

This indicates that FF/Opera have more of a problem than IE, at least IE6. (Sorry no IE8 available on this machine).

Anyway, this gives weight to my first thought - use textarea.innerHTML to read and write content. Other combinations appear reliable but this is the easiest rule to remember.

Airshow


... innerHTML ...

Airshow

I tested innerHTML (and even MSFT's innerText) with mixed results. Have concluded that it's best not to depend on innerHTML. It works fine in the simple cases, but then you decide that you need multi-line text. What separator?

Outside of textareas, it looks like: x.innerHTML = ''; should empty element x. It does so correctly in all but one of Chrome, Firefox, MSIE, Opera, Safari. Can you guess the exception?

To the person who requested code: here's a sample.

alert( x.value ) // it's OK in the alert box, OK on the screen.

/* end of file xxx_run.js */

That's the last line executed before the app begins waiting for user events. After closing the alert, the textarea on screen is now invalid.

"Other standard browsers"? Are you affiliated with Microsoft? MSIE is not a "standard" browser.

Because MSIE normally implements functionality against standard (W3C), it is likely that the browser may behave differently from other standard browsers. Yes, MSIE can be called a standard web browser, but you cannot expect it to behave the way other standard web browsers do.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.