465 bytes, text/html
97 bytes, text/html
767 bytes, text/html
7.91 KB, patch
Kevin McCluskey (gone): review+
Simon Fraser: superreview+
|Details | Diff | Splinter Review|
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.
Assignee: rods → beppe
Summary: textarea control has problems with focus and selection → textarea control has problems with caret positioning at end
assigning to kin to review
Assignee: beppe → kin
Priority: -- → P2
Target Milestone: --- → mozilla0.9.3
Confirming on build 2001-05-31-22-trunk windows 98
Status: UNCONFIRMED → NEW
Ever confirmed: true
also happens on linux 2001-05-31-08-trunk changing OS to all
OS: Windows 98 → All
confirmed on win98 using trunk opt build from 6/19
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
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 → ---
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
Move to target milestone Mozilla 1.0 for now as per email@example.com.
was able to reproduce this bug even without setting 'wrap=virtual' on win2k build iD :- 2001-09-28-05-0.9.4
Summary: textarea control has problems with caret positioning at end → textarea control has problems with caret positioning at end (when scrollbar is visible)
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
*** Bug 103154 has been marked as a duplicate of this bug. ***
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
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.
Nominating mozilla1.0 and nsCatFood since this is serious ui issue.
Keywords: mozilla0.9.6 → mozilla1.0, nsCatFood
Pull this in to mozilla1.0. This is probably related to my findings noted in bug 97207.
Target Milestone: mozilla1.0.1 → mozilla1.0
Pull into mozilla0.9.9 I have a fix for this.
Target Milestone: mozilla1.0 → mozilla0.9.9
Created attachment 67456 [details] [diff] [review] Patch Rev 1 (corrects coordinate translation done by event system and GetFrameForPointUsing())
Whiteboard: [textarea][EDITORBASE] → [textarea][EDITORBASE] FIX IN HAND, need r= and sr=
*** Bug 123405 has been marked as a duplicate of this bug. ***
Severity: major → critical
Keywords: nsbeta1 → nsbeta1+
Comment on attachment 67456 [details] [diff] [review] Patch Rev 1 (corrects coordinate translation done by event system and GetFrameForPointUsing()) firstname.lastname@example.org
Attachment #67456 - Flags: review+
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+
*** Bug 55233 has been marked as a duplicate of this bug. ***
Whiteboard: [textarea][EDITORBASE] FIX IN HAND, need r= and sr= → [textarea][EDITORBASE] FIX IN HAND, ready for checkin
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 ago → 17 years ago
Resolution: --- → FIXED
Whiteboard: [textarea][EDITORBASE] FIX IN HAND, ready for checkin → [textarea][EDITORBASE] fixed on trunk
Whiteboard: [textarea][EDITORBASE] fixed on trunk → [textarea][EDITORBASE][CANDIDATE_094] fixed on trunk
Verifying on build 2002-02-20-03-trunk windows 98 and 2002-02-13-08-trunk linux red hat
Status: RESOLVED → VERIFIED
*** Bug 132296 has been marked as a duplicate of this bug. ***
*** Bug 112585 has been marked as a duplicate of this bug. ***
Fix caused regression bug 184616.
You need to log in before you can comment on or make changes to this bug.