Closed Bug 29188 Opened 25 years ago Closed 25 years ago

textarea doesn't update the scrolling when value changed

Categories

(Core :: Layout: Form Controls, defect, P3)

Product:
Core
Component:
Layout: Form Controls
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: graf, Assigned: eric)

References

(
URL
)

Details

(Keywords: testcase, Whiteboard: [nsbeta2-][nsbeta3-][TESTCASE] both scrollbars removed bug)

This might apply more to DOM, than JS, but whichever it is: If the textarea contained a lengthy value and has been manually scrolled down and then changed via JavaScript to a shorter value, the textarea doesn't "rescroll" to accommodate for this change. To see what I mean, check http://www.mricon.com/bugzilla/js.html
I'm voting that it IS more DOM than JS engine, so off it goes.
Assignee: rogerl → vidur
Component: Javascript Engine → DOM Level 1
QA Contact: rginda → gerardok
Not even DOM related. The textarea doesn't rescroll back to top when the text is removed using a mouse. Component changed to HTML Form Controls. Steps to reproduce: 1. Open the URL at http://www.mricon.com/bugzilla/js.html 2. Click on the left button to fill in the textarea 3. Select with the mouse the text from the third line to the end of the textarea and press the Del key Actual Result: Blank textarea Expected Result: Textarea to display the remaining two lines from the top
Status: UNCONFIRMED → NEW
Component: DOM Level 1 → HTML Form Controls
Ever confirmed: true
QA Contact: gerardok → ckritzer
The problem is there on WinNT4 SP6a build 2000022808 as well - changing OS to All. Verifying the bug report as valid and definitive & adding testcase keyword.
Keywords: testcase
OS: Linux → All
Whiteboard: [TESTCASE] textarea should scroll back up when extra text is removed
Moving this to pollmann, since it is forms related. My guess is that he will forward to someone in the editor group since they own the textarea widget.
Assignee: vidur → pollmann
This is fixed in today's build. Awesome!
Status: NEW → RESOLVED
Closed: 25 years ago
Hardware: PC → All
Resolution: --- → WORKSFORME
Works great on Win98 build 2000-04-09-08. Will verify Mac & Linux soon.
Checked with Linux build 2000041008 -- bug still there.
I am also able to verify this now on Linux.
Status: RESOLVED → REOPENED
OS: All → Linux
Hardware: All → PC
Resolution: WORKSFORME → ---
Status: REOPENED → ASSIGNED
I was also able to verify this for Windows. I tried this test case in viewer with Gfx scrollbars turned on, then again with Gfx scrollbars turned off (for both Linux and Windows). In all cases, when Gfx scrollbars were turned off, this bug was not present. When Gfx scrollbars were turned on, this bug *was* present. Forwarding this on to Eric Vaughan to look at and CC'ing Steve as he surely understands the text widget better than I do :)
Assignee: pollmann → evaughan
Status: ASSIGNED → NEW
OS: Linux → All
targeting
Status: NEW → ASSIGNED
Target Milestone: --- → M16
I see this bug on Mac, too (build 2000-04-24-09) - changing Platform to All.
Hardware: PC → All
nominating for nsbeta2. This could be seen as a security problem, since you could submit text when the field appears blank.
Keywords: nsbeta2
[nsbeta2-]
Whiteboard: [TESTCASE] textarea should scroll back up when extra text is removed → [nsbeta2-][TESTCASE] textarea should scroll back up when extra text is removed
Mass-moving nsbeta2- bugs to M20
Target Milestone: M16 → M20
Whiteboard: [nsbeta2-][TESTCASE] textarea should scroll back up when extra text is removed → [nsbeta2-][TESTCASE] both scrollbars removed bug
This is still reproducible. nominating nsbeta3
Keywords: nsbeta3
nsbeta3-, no time for this.
Whiteboard: [nsbeta2-][TESTCASE] both scrollbars removed bug → [nsbeta2-][nsbeta3-][TESTCASE] both scrollbars removed bug
Target Milestone: M20 → Future
Updating QA contact.
QA Contact: ckritzer → bsharma
Seems fixed on Linux M18.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
verified on build 2001-08-13-trunk os:win98,winNT
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.