textarea not working well with carraige returns / newlines

VERIFIED FIXED in M11

Status

()

P3
normal
VERIFIED FIXED
20 years ago
20 years ago

People

(Reporter: cpratt, Assigned: buster)

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

20 years ago
If you go the (admittedly atrocious) page at the above URL, there is a textarea
on the page which assumes the behaviour of legacy browsers: that text inside of
a textarea is treated as PRE text. It contains lots of carraige returns (I
think); using a legacy browser it 'correctly' displays the text on separate
lines. Using the April 16 build of apprunner, however, it does not break the
lines when it hits a line feed; instead, it draws the linefeed as a square
(which indicates, I think, a character the browser can't display). It should do
the same as legacy browsers - wrap the text down a line when it encounters a
linefeed/cr.

Updated

20 years ago
Status: NEW → ASSIGNED

Comment 1

20 years ago
I can't get on their site. Can you please provide an attachment showing the
problem? I suspect this isn't a compositor problem but more a widget problem.

Updated

20 years ago
Assignee: michaelp → kmcclusk
Status: ASSIGNED → NEW
(Reporter)

Comment 2

20 years ago
Downloading and/or editing the page at the site causes the text to change (the
newlines/carraige returns change into something that displays properly in
apprunner). Please advise on what to do in this case... I've put a local copy of
the page at the new URL above but it does NOT exhibit the problem as Windows
changed the characters when the page was saved.
Status: NEW → ASSIGNED
Component: Compositor → Widget Set
Target Milestone: M7
Changed component to widget set from compositor.
Target Milestone: M7 → M9
Target Milestone: M9 → M10

Comment 4

20 years ago
Moving all Widget Set bugs, past and present, to new HTML Form Controls
component per request from karnaze.  Widget Set component will be retired
shortly.
Assignee: kmcclusk → buster
Status: ASSIGNED → NEW
Steve, I'm re-assigning this to you as something to check when ender-based text
field lands.
(Assignee)

Updated

20 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

20 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → FIXED
(Assignee)

Comment 6

20 years ago
GFX text control seems to handle this page fine.  Marking fixed.

Updated

20 years ago
Status: RESOLVED → VERIFIED

Comment 7

20 years ago
With the latest build (Aug 6th), the problem that is described seems to be fixed.

Updated

20 years ago
Status: VERIFIED → REOPENED

Updated

20 years ago
Resolution: FIXED → ---

Comment 8

20 years ago
I knew there was a bug report about this already! I can see the described
failure from http://schist/nlp on 1999-09-07-09-M10 build. Reopening bug.

Comment 9

20 years ago
Client Mail/News QA is currently writing XPConnect testcases that use a textarea
requiring a carriage return. If this bug actually gets fixed it will benefit us.

Par
(Assignee)

Updated

20 years ago
Status: REOPENED → ASSIGNED
Depends on: 6262
Target Milestone: M10 → M11
(Assignee)

Comment 10

20 years ago
this bug is fixed in gfx text controls.  I marked it fixed expecting them to be
turned on by default (bug 6262), but that was delayed until today.  I'll mark
this fixed when they are turned on.
(Assignee)

Updated

20 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago20 years ago
Resolution: --- → FIXED
(Assignee)

Comment 11

20 years ago
gfx controls are on by default on linux and windows now, and can easily be set
on mac using a pref.  marking fixed again.
(Reporter)

Updated

20 years ago
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.