textarea control has problems with caret positioning at end (when scrollbar is visible)

VERIFIED FIXED in mozilla0.9.9

Status

()

Core
Layout: Form Controls
P2
critical
VERIFIED FIXED
17 years ago
4 years ago

People

(Reporter: Chris, Assigned: kinmoz)

Tracking

({topembed})

Trunk
mozilla0.9.9
x86
All
topembed
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [textarea][EDITORBASE][CANDIDATE_094] fixed on trunk, URL)

Attachments

(4 attachments)

(Reporter)

Description

17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9) Gecko/20010505
BuildID:    2001050515

The textarea form control has problems when you click on certain areas of the
control

Reproducible: Sometimes
Steps to Reproduce:
1. Type in some text in a textarea box 
<textarea rows=5 cols=70 name=ReproduceSteps wrap=virtual></textarea>
- in actual fact the form that I'm writing in now. 
2. Now type in the following (yes, this looks like junk, please bear with me): 
ldjfalsdfjalsdjflaskdjfladsjfdasljflasjdflkajsdflkasjfklajsdfkljasdlk;fjasdlkfjasldkjfalsdjflasdjfasldfjasldasdlfk
lsdakfjaslfjasldjfasldkfj alsdkjfasl;djflasdkjflasdkjf
lalsdjfalsdjflaksdjflkasdjflkasdjflkasdjflkasdjflkasdj
asdlfjasldfkjasdlkfjasdlkjfasldkfjlsdakj
flaskdjflkasjdflksajdflasdjfldkasjflaskdjflaskdjf asdlkfj sadfljkasdjflasdkjfa dog
3. Now, scroll up to the start of the textarea control. Click anywhere in the
first nonsense "word" to position the cursor
4. Scroll down the text area control to the bottom of the text control *using
your mouse*. What I am trying to get you to do here is to keep the cursor focus
position where you just put it
5. Try to click on the text (with your mouse) in the white area *after the last
word "dog"*. What users are trying to do is get the cursor to be positioned at
the very end of the line.

Actual Results:  You cannot get the cursor to position itself after the last
word! It selects the line above the one that you have chosen, sometimes it does
not select the line above, however, it just stays where it is. 

Expected Results:  It should select the end position of the line, not the line
above.

It appears that in the textarea form that if you try to select any text after a
newline when you have the cursor positioned elsewhere anywhere else then it will
not position itself after the cursor of the last word. Sometimes you will be
able to select the text correctly. My results vary with different text, however
I *know* that if you try the step by step results above then you will be able to
reproduce it.

Comment 1

17 years ago
reassigning
Assignee: rods → beppe

Updated

17 years ago
Summary: textarea control has problems with focus and selection → textarea control has problems with caret positioning at end

Comment 2

17 years ago
assigning to kin to review
Assignee: beppe → kin
Priority: -- → P2
Target Milestone: --- → mozilla0.9.3

Updated

17 years ago
Keywords: correctness
Whiteboard: [textarea]

Comment 3

17 years ago
Confirming on build 2001-05-31-22-trunk windows 98
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 4

17 years ago
also happens on linux 2001-05-31-08-trunk changing OS to all
OS: Windows 98 → All

Comment 5

17 years ago
confirmed on win98 using trunk opt build from 6/19
(Assignee)

Comment 6

17 years ago
This is a dup of bug 87133 which I fixed.

*** This bug has been marked as a duplicate of 87133 ***
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
(Assignee)

Comment 7

17 years ago
Created attachment 40122 [details]
Test case for this bug.

Comment 8

17 years ago
This bug is still occuring in build 2001-07-10-05-0.9.2 even though the
duplicate is resolved fixed. The testcase in the duplicate is passing but this
one does not.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(Assignee)

Comment 9

17 years ago
Created attachment 41871 [details]
Reduced test case.
(Assignee)

Comment 10

17 years ago
You're right this bug is caused by something else ... it also only happens when 
both the vertical and horizontal scrollbars are present.

In this particular case, the scrollport frame is using GetFrameForPoint() to 
find the frame that should handle the mouse down, and it's finding the frame for 
the previous line, whereas in bug 87133 the bug was in 
nsBlockFrame::GetClosestLine().
Status: REOPENED → ASSIGNED
(Assignee)

Updated

17 years ago
Target Milestone: mozilla0.9.3 → mozilla1.0
(Assignee)

Comment 11

17 years ago
Move to target milestone Mozilla 1.0 for now as per beppe@netscape.com.

Comment 12

17 years ago
was able to reproduce this bug even without setting 'wrap=virtual' on win2k 
build iD :- 2001-09-28-05-0.9.4


Updated

17 years ago
Summary: textarea control has problems with caret positioning at end → textarea control has problems with caret positioning at end (when scrollbar is visible)

Comment 13

17 years ago
I see this bug when I copy paste text into the textarea form control OR if I
already have some default value set in the control.

I am not seeing the bug when I type in the text firsthand.

Happening on all platforms.
nominating for mozilla0.9.6
Keywords: mozilla0.9.6

Comment 14

17 years ago
*** Bug 103154 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 15

17 years ago
Bulk move of mozilla1.0 bugs to mozilla.1.0.1. I will try to pull some of these
back in if I can.
Target Milestone: mozilla1.0 → mozilla1.0.1

Comment 16

17 years ago
Confirming in build 2001-11-2009-0.9.6. I can recreate this and a variant bug:
with the scroll bar present, if I click on the last line but to the left of the
end of the next-to-last line, the cursor will position itself within the
next-to-last line and not at the end of the last line as it should. (The
variant: if I have a vertical scroll, pressing <enter> within a line of text
causes much of that text to disappear.) My example case is the "Additional
Comments" box I'm using right now.

I really hope that this bug can be fixed prior to 1.0, because it prevents me
and my group from recommending it to our hundreds of users who currently use
Netscape 4.x for extensive data entry.

Comment 17

17 years ago
Nominating mozilla1.0 and nsCatFood since this is serious ui issue.
Keywords: mozilla0.9.6 → mozilla1.0, nsCatFood

Updated

17 years ago
Keywords: mozilla0.9.9

Updated

17 years ago
Blocks: 103039
(Assignee)

Comment 18

17 years ago
Pull this in to mozilla1.0. This is probably related to my findings noted in bug 
97207.
Target Milestone: mozilla1.0.1 → mozilla1.0
(Assignee)

Comment 19

17 years ago
Pull into mozilla0.9.9 I have a fix for this.
Target Milestone: mozilla1.0 → mozilla0.9.9
(Assignee)

Comment 20

17 years ago
Created attachment 67455 [details]
Another Test Case (Shows problem in textfields and textareas)
(Assignee)

Updated

17 years ago
Blocks: 97207
(Assignee)

Comment 21

17 years ago
Created attachment 67456 [details] [diff] [review]
Patch Rev 1 (corrects coordinate translation done by event system and GetFrameForPointUsing())
(Assignee)

Updated

17 years ago
Whiteboard: [textarea] → [textarea][EDITORBASE]
(Assignee)

Updated

17 years ago
Whiteboard: [textarea][EDITORBASE] → [textarea][EDITORBASE] FIX IN HAND, need r= and sr=
(Assignee)

Comment 22

17 years ago
*** Bug 123405 has been marked as a duplicate of this bug. ***
Severity: major → critical
Keywords: nsbeta1
Marking nsbeta1+
Keywords: nsbeta1 → nsbeta1+
Comment on attachment 67456 [details] [diff] [review]
Patch Rev 1 (corrects coordinate translation done by event system and GetFrameForPointUsing())

r=kmcclusk@netscape.com
Attachment #67456 - Flags: review+

Comment 25

17 years ago
Comment on attachment 67456 [details] [diff] [review]
Patch Rev 1 (corrects coordinate translation done by event system and GetFrameForPointUsing())

sr=sfraser
Attachment #67456 - Flags: superreview+
(Assignee)

Comment 26

17 years ago
*** Bug 55233 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

17 years ago
Whiteboard: [textarea][EDITORBASE] FIX IN HAND, need r= and sr= → [textarea][EDITORBASE] FIX IN HAND, ready for checkin
(Assignee)

Comment 27

17 years ago
Fix checked into TRUNK:

  mozilla/layout/base/public/nsIFrame.h              revision: 3.194
  mozilla/layout/html/base/src/nsContainerFrame.cpp  revision: 1.132
  mozilla/layout/html/base/src/nsFrame.cpp           revision: 3.359
  mozilla/layout/html/base/src/nsFrame.h             revision: 3.164
  mozilla/layout/html/base/src/nsPresShell.cpp       revision: 3.509
  mozilla/layout/xul/base/src/nsBoxFrame.cpp         revision: 1.180

Should appear in 02/08/02 QA builds.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED
Whiteboard: [textarea][EDITORBASE] FIX IN HAND, ready for checkin → [textarea][EDITORBASE] fixed on trunk
(Assignee)

Updated

17 years ago
Keywords: topembed
Whiteboard: [textarea][EDITORBASE] fixed on trunk → [textarea][EDITORBASE][CANDIDATE_094] fixed on trunk

Comment 28

17 years ago
Verifying on build 2002-02-20-03-trunk windows 98 and 2002-02-13-08-trunk linux
red hat
Status: RESOLVED → VERIFIED
(Assignee)

Comment 29

17 years ago
*** Bug 132296 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 30

17 years ago
*** Bug 112585 has been marked as a duplicate of this bug. ***

Comment 31

16 years ago
Fix caused regression bug 184616.
You need to log in before you can comment on or make changes to this bug.