PDA

View Full Version : IE bug with textarea element (max 1568 chars)



Ruslan Zenin
02-07-2007, 07:18 PM
Came across this bug with textarea HTML element in IE6...

When textarea has more that 1568 characters the HTML form stops responding to SUBMIT event 9e.g. submit does not work anymore!!!


- Here is the sample HTML page that demonstrates the problem:


<HTML>
<BODY>
<FORM name="F" action="http://google.ca">
<TEXTAREA name="somename" cols="50" rows="20">Try to enter here text that is bigger that 1568 chars (Just copy/paste this text 12 times).
The form will never submit!!! This works fine in FireFox.
Looks like it is IE bug.
If the property "name" of the textarea is removed it starts working!

</TEXTAREA>
<br/>
<INPUT type="submit" value="SUBMIT BUTTON SHOULD REDIRECT TO GOOGLE"><br/>
<INPUT type="button" value="Script Submit" onClick="document.F.submit();">
</FORM>
</BODY>
</HTML>



- Remedy for the problem:
To fix this wild behavior textarea should NOT have "name" attribute...
After it is removed, the example above works fine...

NOTE: This problem found so far in IE6 series of the browsers (FireFox as expected works just fine)

MESSAGE TO MICROSOFT: Please fix your browser! Also, please do support SVG image format "out of the box" (no plugins please!)

djr33
02-07-2007, 07:30 PM
Hmm... I seriously doubt this.
I'd have to play with it to figure it out.

There's no script involved in this?

Just that generally anything over that many characters causes a problem?

Ruslan Zenin
02-07-2007, 11:43 PM
Here is the situation with web development:
http://img347.imageshack.us/img347/2254/cssgraph0oo.png

:)

jscheuer1
02-08-2007, 06:27 AM
I'd think that is a limit on the number of characters allowed in the address bar. If the form's method were post, this might also 'fix' it.


<FORM name="F" action="http://google.ca" method="post">

Ruslan Zenin
02-08-2007, 02:34 PM
Thanks for the extra work around idea...

OK, but why IE6 fails to even submit. Try in my example JavaScript button - <INPUT type="button" value="Script Submit" onClick="document.F.submit();">
IE generates error!!!
This is clearly a bug.

thetestingsite
02-08-2007, 03:10 PM
Why not just make it a submit button?

Ruslan Zenin
02-08-2007, 04:20 PM
Why not just make it a submit button?

Perhaps you did not read/understand my original post - there is a BUG in IE6.... I have provided sample HTML that demonstrates the problem
It has 2 butoons:
1. Regular SUBMIT button - does not work
2. Button with JS form submit - also does not work

jscheuer1
02-08-2007, 04:24 PM
Thanks for the extra work around idea...

OK, but why IE6 fails to even submit. Try in my example JavaScript button - <INPUT type="button" value="Script Submit" onClick="document.F.submit();">
IE generates error!!!
This is clearly a bug.


Why not just make it a submit button?

I don't think that was the point, thetestingsite. Read over the thread. This latest observation by Ruslan Zenin was to make the point, not as a solution or as a problem.

Anyways though, there was a time when all browsers had limitations on the length of the address in the address bar. At that time, 1568 characters was a big improvement. So, I really wouldn't call it a bug. I would say that it is outdated. Generating an error is simply the browser's way of informing the designer that his/her code needs revision.

Also, if you think about it, it isn't such a hot idea to pass so much data in the query string. If the textarea is editable, the user could keep increasing the length until it either became truncated or caused an error and/or crashed in any browser.

Twey
02-08-2007, 04:27 PM
Here is the situation with web development:
http://img347.imageshack.us/img347/2254/cssgraph0oo.pngHeh :)

Does it work using method="post"? If not, that's definitely a bug.

jscheuer1
02-08-2007, 04:37 PM
Heh :)

Does it work using method="post"? If not, that's definitely a bug.

Good point. I already mentioned using post and I thought, from Ruslan Zenin's response*, that took care of it. But, I see upon rereading it that I may have jumped to that conclusion.


*

Thanks for the extra work around idea...

Ruslan Zenin
02-08-2007, 06:03 PM
Good point. I already mentioned using post and I thought, from Ruslan Zenin's response*, that took care of it. But, I see upon rereading it that I may have jumped to that conclusion.
*

Confirming...Just checked when I add method="post" it works (both regular SUBMIT and JS submit) ... - which is a work around... :eek:

The problem is that TEXTAREA is sensitive to the enclosing form in IE6.

If textarea happen to have "name" attribute it magically stops working (both regular submit and JS submit)... :confused: BUT once "name" attribute removed it works fine!

So, I think it is a bug - I cannot imagine this feature being specially planned by MS. ;)

jscheuer1
02-08-2007, 06:15 PM
The thing about the name attribute for an element in a form is that onsubmit of that form, if the element has a name, that name and that element's value are appended to the address in the get. That is why either removing the name or changing the get to a post fixes it. As I said, it all comes down to however many characters are allowed in the address bar. Sorry, lack of foresight, perhaps but, no bug.

Twey
02-08-2007, 06:30 PM
John is right.

I disagree about the lack of foresight -- GET was never intended to transmit large amounts of data. A lot of webservers refuse to handle query strings over a certain length.

Ruslan Zenin
02-08-2007, 06:30 PM
The thing about the name attribute for an element in a form is that onsubmit of that form, if the element has a name, that name and that element's value are appended to the address in the get. That is why either removing the name or changing the get to a post fixes it. As I said, it all comes down to however many characters are allowed in the address bar. Sorry, lack of foresight, perhaps but, no bug.

I've got your point... but how come it does not happen in FireFox? How come they can handle this "magical maximum characters are allowed in the address bar" problem? Is there any standard on the GET parameter size at all?

thetestingsite
02-08-2007, 06:33 PM
I believe the get method only handles up to 256 characters (then again, that might just be the max allowed in the address bar). I'm pretty sure that either John or Twey will clear this up though.

Ruslan Zenin
02-08-2007, 06:36 PM
John is right.

I disagree about the lack of foresight -- GET was never intended to transmit large amounts of data. A lot of webservers refuse to handle query strings over a certain length.

Don't you think, IE should be more intelligent in such case? Perhaps do some meaningful message instead of breaking with error:
Error: Invalid Syntax
Code: 0

Twey
02-08-2007, 06:40 PM
I think IE should give more intelligent error messages in all cases. All I've ever got out of it is "Object Expected," "Invalid Syntax," and "Unknown Error," and of course it always specifies completely the wrong line.

Ruslan Zenin
02-08-2007, 06:45 PM
Can anyone try to test my HTML example on other versions of the IE? (ver 5 and 7)?

I wonder if that "bug or problem or feature" is present there as well...



<HTML>
<BODY>
<FORM name="F" action="http://google.ca">
<TEXTAREA name="somename" cols="50" rows="20">Try to enter here text that is bigger that 1568 chars (Just copy/paste this text 12 times).
The form will never submit!!! This works fine in FireFox.
Looks like it is IE bug.
If the property "name" of the textarea is removed it starts working!

</TEXTAREA>
<br/>
<INPUT type="submit" value="SUBMIT BUTTON SHOULD REDIRECT TO GOOGLE"><br/>
<INPUT type="button" value="Script Submit" onClick="document.F.submit();">
</FORM>
</BODY>
</HTML>

jscheuer1
02-08-2007, 06:52 PM
I think IE should give more intelligent error messages in all cases. All I've ever got out of it is "Object Expected," "Invalid Syntax," and "Unknown Error," and of course it always specifies completely the wrong line.

IE actually gives better error than FF in certain cases. Just recently, with a body onload for an undefined function, FF gave line 1 or 0 while IE correctly identified the line number of the body tag. Where IE really gets misleading is with external script files. There, the line number is usually correct but, the filename given is the page to which the script is linked. For debugging purposes, the script can be placed on the page, if need be.

Neither browser fairs too well in locating the line when the error is in an interval or timeout.

As for the error messages, FF has all those (except perhaps Unknown) and many others as does IE.

I usually prefer FF's error console to IE's pop up error report but, sometimes IE's interface is more useful.

Twey
02-08-2007, 06:57 PM
There, the line number is usually correct but, the filename given is the page to which the script is linked.It's more complex than that. IE takes all the external scripts linked, concatenates them all, then gives the line number from that conglomeration, all the while, as you said, pretending that this enormous script is actually part of the HTML page.
Neither browser fairs too well in locating the line when the error is in an interval or timeout.Understandably; anonymous functions are compiled (if that is the correct word for an interpreted language) dynamically.
As for the error messages, FF has all those (except perhaps Unknown) and many others as does IE.Certainly it does. The difference is that Fx actually gives me them, whereas, as I said before, those are the only three errors I've ever managed to coax out of IE.
I usually prefer FF's error console to IE's pop up error report but, sometimes IE's interface is more useful.When? I find it completely useless, and usually resort to alert() to debug scripts in IE (and both Invalid Syntax and Unknown Error are rare; in the majority of cases I find that it specifies "Object Expected" no matter what goes wrong).

jscheuer1
02-08-2007, 07:12 PM
It is pointless to argue too much on matters of taste. I have obviously had better and perhaps more experience with IE's error reporting. I do find it useful, even more so than FF's in certain cases but, as I did say, I prefer FF's method in most cases. As I continue to get acclimated to Opera as my primary browser, I find that it's error console often sheds illumination on a script error when neither of the other two manage to do so. It also almost always catches anything that the other two can.

Partly, one must realize too that, as a script branches - this will sometimes influence the error reporting behavior of a given browser, depending upon the type of error involved and the capabilities of each browser as exposed to the script's branching. FF gets good marks here I will admit, sometimes even picking up an IE specific error that IE misses! All in all, if I were deprived of any of these avenues for script debugging, I would feel at a disadvantage in my work here.

Twey
02-08-2007, 07:59 PM
More than trying to persuade you otherwise, I was simply curious as to what features you found useful with IE's default script debugger. Even the staunchest Microsoft advocates I know denounce it as completely useless and recommend one of the add-on debuggers instead.

jscheuer1
02-08-2007, 08:13 PM
I already mention one recent specific case. I don't keep a running total of such things but, over the years it has happened time and again. I would however strongly agree that for the most part the FF error console is far superior. I would also strongly disagree that IE is useless in this regard, in addition to its having the occasional utility when FF 'falls down', its arcane interface can be gotten used to, worked with, etc. But, it is a little like being stuck doing a certain type of electrical wiring with a knife, friction tape and pliers as opposed to having a wire gauge stripper, snap on terminals and a crimping tool. Useless is a term that someone with little patience would use to describe that situation as well.

As for those staunchest Microsoft advocates, they can keep their add-on debuggers, I have Opera and FF which bring many additional benefits besides their enhanced script debugging abilities. For me, IE is really only for testing compatibility with IE and the occasional times when it picks something up that the others miss.

Twey
02-08-2007, 08:28 PM
That's true, I apologise.
I have Opera and FF which bring many additional benefits besides their enhanced script debugging abilities. For me, IE is really only for testing compatibility with IE and the occasional times when it picks something up that the others miss.Yes, but frequently the error happens only in IE, and thus can only be debugged in IE.

jscheuer1
02-08-2007, 08:47 PM
That's true, I apologise.


I have Opera and FF which bring many additional benefits besides their enhanced script debugging abilities. For me, IE is really only for testing compatibility with IE and the occasional times when it picks something up that the others miss.

Yes, but frequently the error happens only in IE, and thus can only be debugged in IE.

Thanks. I agree here as well, for the most part. There still are times when IE 'saves the day' though, and not just with things that only bother IE. Conversely, there are times when the error only affects IE but, FF or Opera are required to debug it!

Ruslan Zenin
02-08-2007, 08:52 PM
...I have Opera and FF which bring many additional benefits besides their enhanced script debugging abilities. For me, IE is really only for testing compatibility with IE and the occasional times when it picks something up that the others miss.

Thanks for the insights John... Same for me, I use IE only as per need basis (when want to test compatibility with IE) :)

Can you please test then my HTML on Opera browser? I wonder how this case handled there...

jscheuer1
02-08-2007, 10:19 PM
It gets ugly. Characters get superimposed upon one another in the address bar. No apparent limit though. An error would be preferable.

Twey
02-08-2007, 11:52 PM
That's interesting -- Firefox handles it in roughly the same way.

Ruslan Zenin
02-09-2007, 12:03 AM
That's interesting -- Firefox handles it in roughly the same way.

Can you elaborate more on that? I think it works in FF, but not in IE

Twey
02-09-2007, 01:13 AM
As John said, after a certain number of characters, they start to overlay one another in the address bar.

jrs_jr
05-09-2007, 04:19 PM
There is a limit in IE as to how much data can be passed in a GET method. URLs can only be 2,083 characters long. You can read more about it here.

http://support.microsoft.com/default.aspx/kb/q208427/
:)