Closed Bug 36130 Opened 20 years ago Closed 20 years ago

Textarea needs to correct scroll when it's value is set

Categories

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

Product:
Core
Component:
Layout: Form Controls
Platform:
x86
Windows 98
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: sicking, Assigned: mjudge)

References

Details

(Keywords: testcase, Whiteboard: [nsbeta3+][p:3])

Attachments

(4 files)

testcase. Follow the instructions in the original report to reproduce the bug
216 bytes, text/html
Details
testcase showing when textarea scrolls correctly
225 bytes, text/html
Details
first image as sample
2.32 KB, image/gif
Details
second image as sample
1.67 KB, image/gif
Details 
When setting the value of a textarea it needs to scroll into place if the new 
value has fewer rows then old value and the textarea is scrolled down.

To reproduce:
1. Open the attaced testcase
2. Scroll down in the textarea to text "scroll to here!"
3. Click the "go" button

The textarea is still scrolled down causing the first rows not to show

4. It is possible to get to the top of the textarea by "select-scrolling" or 
navigating using the keys

The same problem occurs also if the vertical size of text changes (try 
scrolling to the far right in point 2)

The niftiest solution would be if the textarea scrolled up only as far as 
needed. So that if you have scrolled down to the last row of a very long text 
and the text shortens a bit you would still be at the bottom of the text.
Sort of how the browser behaves when you increase its size when it's scrolled 
down/right.

Tested on build 2000-02-17-08
adding testcase keyword
Keywords: testcase
reassigning
Assignee: rods → beppe
well, in today's build on win98, the result of the onclick is not even displayed 
in the textarea. We need to get that squared away first and then we will take a 
look at the other issue.
Depends on: 37441
I just tried this again using the 5/2 build and found that if I don't scroll and 
select go, the operation works. If I scroll and then select go, the operation 
does not even work. Assigning to Mike for review.
Assignee: beppe → mjudge
Target Milestone: --- → M17
No longer depends on: 37441
good one! i will check this out.
Status: NEW → ASSIGNED
Clicking go always works it's just that if you scroll first you don't see the
new text. That what the bug is about! Try scrolling, pressing go and the
dragselect around in the "empty" textarea and you'll se that the new text is
there, it's just scrolled away (as said in original report).

I'm pretty sure this is a dup of bug 30548. If you add a few extra lines to the
"click-go-value" the textarea scrolls correctly, it's only when the srollbar
dissapears that this dosn't work.

Attaching testcase that shows when this works.

per beppe
Whiteboard: correctness, nsbeta3
Target Milestone: M17 → M18
*** Bug 40282 has been marked as a duplicate of this bug. ***
setting to nsbeta3+
Keywords: correctness, nsbeta3
Whiteboard: correctness, nsbeta3 → nsbeta3+
adding the brackets in the status
Whiteboard: nsbeta3+ → [nsbeta3+]
looks good now. please try again. added in caret moving to first element.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
The testcase still dosn't work for me. On Win98SE with build 2000-08-09-08
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attached image first image as sample — 
yes, this is still broken, the issue now is when you hit the go button, the 
result is the caret is displayed above the textarea and the content of the 
textarea is not displayed, pressing the down arrow key forces the caret back 
into the textarea and the text then appears.
Attached image second image as sample — 
This behaves exatly has it has from day one. As said before I think this is a 
dup of bug 30548. However I'm not sure that fixing that would automaticlly fix 
this. Also that bug has been marked nsbeta3- so marking this a dup would make 
this a nofix for beta 3
Whiteboard: [nsbeta3+] → [nsbeta3+][p:3]
hmm.. sorry, this seems to be working now. Don't konw if I did something wrong
last time I tested it or if another fix has been checked in since then. This is
working now anyway.
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
Reopening.
Tested on:
- LinuxRH62 2000-09-08-08-M18 Commercial
- Win98     2000-09-08-08-M18 Mozilla
- MacOS86   2000-09-07-04-M18 Commercial

This only works on Linux.  On Win98 & MacOS86, clicking on the go! button 
appears to clear the text field instead of writing
a
b
c
d

in the text field when you follow the prescribed steps.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
please retest NOW ;) I checked something in that will scroll the selection into 
view after value is set. marking this as fixed.
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
This is a dup of the bug I had on my plate: Bug #49339

I think the expected behavior was to scroll to the top left (0,0) of the text 
widget every time it is set. I replaced the call to ScrollSelectionIntoView with 
some code to scroll to (0,0).

   mozilla/layout/html/forms/src/nsGfxTextControlFrame2.cpp  revision 1.97
   mozilla/layout/html/forms/src/nsGfxTextControlFrame2.h    revision 1.31

r=sfraser@netscape.com
oh no please don't scroll to the top every time.

IMO it shouldn't be neccesery to specialcase for fixing this bug, it should be 
fixed by fixing bug 30548. 
Marking VERIFIED FIXED on:
- LinuxRH62 2000-09-13-08-M18 Commercial
- Win98     2000-09-13-08-M18 Mozilla
- MacOS86   2000-09-13-04-M18 Commercial
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.