Closed
Bug 1829
Opened 26 years ago
Closed 25 years ago
[PP][NATIVE-WIDGET] JAVASCRIPT FORMS \n written to form elements wrong on Windows
Categories
(Core :: DOM: Core & HTML, defect, P1)
Tracking
()
VERIFIED
WONTFIX
M15
People
(Reporter: mle, Assigned: kmcclusk)
References
()
Details
(Whiteboard: Diff to fix this bug attached)
When a string with an embedded new line is written
to a Form field like a TextArea it comes across as a
decimal value of 10 instead of the correct Windows
sequence CR-LF. In the TextArea instead of new line
there is a "undisplayable character" symbol. The
following HTML form and embedded javascript show the
problem.
<html>
<head><title>Windows Line Feed Bug Test</title></head>
<body>
<form name="Magiaa">
<input type="button" value="See Bug" onClick="something()">
<textarea name="history" rows="4" cols="10"></textarea>
</form>
</body>
<script>
function something() {
document.Magiaa.history.value = "One\nTwo";
}
</script>
</html>
|
||
Comment 1•26 years ago
|
||
This one's for you, Chris (or Eric Pollman).
|
|
||
Comment 2•26 years ago
|
||
This one's for you, Chris (or Eric Pollman).
|
||
Updated•26 years ago
|
Assignee: karnaze → pollmann
|
||
Updated•26 years ago
|
|
|
||
Comment 4•26 years ago
|
||
This also happens when the initial content of TEXTAREAs contain just linefeeds.
For example, with this page:
http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/wraptextarea.html
if you scroll horizontally, you'll see little squares instead of the line
wrapping.
|
||
Comment 5•26 years ago
|
||
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
This failure is blocking QA from running the tools for testing Event Model on
Win32. Priority raised to P1.
|
||
Updated•26 years ago
|
Whiteboard: Diff to fix this bug attached
|
|
||
Comment 8•26 years ago
|
||
Here's a quick fix to unblock people. I've still got to do regression testing
and I may add a check to make sure there are no \r's in the string already (or
mText.mStripChars("\r"), wouldn't that be a riot) before I check this in:
Index: nsTextHelper.cpp
===================================================================
RCS file: /cvsroot/mozilla/widget/src/windows/nsTextHelper.cpp,v
retrieving revision 3.13
diff -r3.13 nsTextHelper.cpp
61c61,66
< NS_ALLOC_STR_BUF(buf, aText, 512);
---
> PRInt32 i = 0;
> while ((i = mText.Find('\n', i)) != -1) {
> mText.Insert('\r', i);
> i+=2;
> }
> NS_ALLOC_STR_BUF(buf, mText, 512);
64c69
< aActualSize = aText.Length();
---
> aActualSize = mText.Length();
|
|
||
Comment 9•26 years ago
|
||
Marking M5
|
|
||
Updated•25 years ago
|
Target Milestone: M5 → M6
|
|
||
Updated•25 years ago
|
Target Milestone: M6 → M9
|
|
||
Comment 10•25 years ago
|
||
Reassigning Windows native-widget bugs to Kevin.
This is a hack/fix - so I've not checked it in, but it should give you a good
idea of what the problem is:
===================================================================
RCS file: /cvsroot/mozilla/widget/src/windows/nsTextHelper.cpp,v
retrieving revision 3.13
diff -r3.13 nsTextHelper.cpp
61c61,69
< NS_ALLOC_STR_BUF(buf, aText, 512);
---
> PRInt32 i = 0;
> while ((i = mText.Find('\n', i)) != -1) {
> if ('\r' != mText[i-1]) {
> mText.Insert('\r', i);
> i++;
> }
> i++;
> }
> NS_ALLOC_STR_BUF(buf, mText, 512);
64c72
< aActualSize = aText.Length();
---
> aActualSize = mText.Length();
Assignee: pollmann → kmcclusk
Status: ASSIGNED → NEW
|
Assignee | |
Updated•25 years ago
|
Status: NEW → ASSIGNED
|
|
Assignee | |
Updated•25 years ago
|
Target Milestone: M9 → M8
|
|
Assignee | |
Updated•25 years ago
|
Summary: JAVASCRIPT FORMS \n written to form elements wrong on Windows → [PP][NATIVE-WIDGET] JAVASCRIPT FORMS \n written to form elements wrong on Windows
Target Milestone: M8 → M15
|
|
Assignee | |
Comment 11•25 years ago
|
||
I tried it with a gfx textarea and it works fine. This is an issue only when
using native WIN32 textarea widgets. Since we are going to be switching to
gfx-rendered widgets during M8. I am moving this bug to M15.
|
||
Comment 12•25 years ago
|
||
When is this supposed to happen? I'm on a necko build, and it's still
dysfunctional. I also found when I was testing it that html markup was
interacting with the contents of a text area.. The linefeeds worked when they
were within a (html) comment..
ie:
<!--
whatever text there is, a linefeed,
whatever else.
-->
|
|
Assignee | |
Comment 13•25 years ago
|
||
We will be turning on ender-based text fields and text area at the beginning of
M10.
|
|
Assignee | |
Comment 14•25 years ago
|
||
gfx rendered text fields and text area are enabled as of Aug 19, 1999 4:00 PM.
This bug should be fixed. However, I'm not marking it as fixed, since it is not
fixed for native text fields.
|
|
Assignee | |
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WONTFIX
|
|
Assignee | |
Comment 15•25 years ago
|
||
Ender-based text widgets are enabled. This problem exists only for native text
widgets.
Marking as WONTFIX.
|
||
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
|
|
||
Comment 16•25 years ago
|
||
Marking verified
|
||
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•