Closed Bug 202677 Opened 21 years ago Closed 21 years ago

more difficult to place cursor at end of a line (in textarea, compose or editor window) using pointer (mouse)

Categories

(Core :: DOM: Editor, defect)

defect
Not set
normal

Tracking

()

VERIFIED DUPLICATE of bug 202834

People

(Reporter: bugzilla, Assigned: mozeditor)

References

Details

(Keywords: regression, topembed+, Whiteboard: edt_x3,edt_b3,edt_c3)

found using 2003.04.18.08 comm bits in linux rh7.3 --this wasn't a problem with
the 2003.04.14.11 bits.

1. open either an editor window or mail compose (either plaintext or html).
2. type a line of text, such as the following:

<body>
here is some text.<br>
</body>

3. mouseclick to somewhere in the middle of the sentence.
4. now, move the pointer to the outside (to the right) of the sentence, so that
the pointer is has the solid arrow appearance.
5. click the mouse.

expected: cursor should be placed at the end of the sentence, to the right of
the period.

actual results: nothing happens, i cannot move the cursor via mouseclick to that
postion.

workaround: i need to move the pointer till is nearly next to the period --it'll
turn into an I-beam-- after which clicking will then place the cursor. more
precision is needed (and thus more difficult) to place the cursor.

this also seems to occur in html textareas.

could this be due to recent checkins by mjudge and/or kaie? reassign as needed.
thanks!
I see this also in the win32 mail text-composer
OS: Linux → All
*** Bug 202709 has been marked as a duplicate of this bug. ***
From dupe: this regressed between 2003041709 and 2003041804
*** Bug 202781 has been marked as a duplicate of this bug. ***
This (or something similar, but could be the same cause) is also happening with
texareas - such as when entering Bugzilla comments as I'm doing now.  When
clicking on whitespace to the right of the last line of text in a paragraph
(prior to a carriage return), the cursor is moved to the end of the line of text
*below* the line of text you'd actually clicked to the right of.  If there *is*
no line of text below the last line in the paragraph you'd clicked to the right
of, then nothing happens.
Please note this regression occurred after building from the post 4/15 22:15 tree.
The build with the tree as of 4/15 22:15 works fine. Mail composition window only.
I'll check the textarea in bugzilla using a build from last night and post an
update.
Is this a regression from 195080?
Could someone try backing out that patch and confirming my suspicions?
Maybe a regression from the checkin in nsSelection.cpp (bug 191498 and bug 192167)
possibly also a regression from this bug 163235
Hardware: PC → All
nominating.
Keywords: nsbeta1, topembed
Discussed in edt bug triage.  Plussing.
Keywords: topembedtopembed+
Whiteboard: edt_x3,edt_b3,edt_c3
could this bug be a DUPE of bug 202568 ?
Bug 202568 the text cursor is potitioned incorrectly when clicking with the mouse

there is a typo in the summary of bug 202568, should be 'positioned'
Despite the lower number, bug 202568 would be a dupe of this one if anything. 
(More progress has been made here.)

David: Did you get a chance to test the texarea issue as you'd mentioned in
comment 16?  (Or can anybody else confirm and/or tie its symptoms into the same
cause.)
I reported bug 202709 on specifically the textarea problems, which was duped to 
this, so yeah, it's the same.
Summary: more difficult to place cursor at end of a line using pointer (mouse) → more difficult to place cursor at end of a line (in textarea, compose or editor window) using pointer (mouse)
*** Bug 202568 has been marked as a duplicate of this bug. ***
It's not just the mouse cursor/pointer that's behaving oddly, it's also the
cursor keys.  Consider the following four lines of text (you can copy/paste them
into the "Additional Comments:" box as test):

aaaaaa
bbb
cccccc
ddd
eeeeee

If I have the cursor after the last "c" and hit the up arrow, the cursor moves
to the right of the 1st "c" rather than actually moving up a line. 
Additionally, if my cursor is to the *left* of the last "e" and I hit up arrow,
the insertion point is moved to the left of the last "c", *not* to right of the
last "d" as it is when I have the insertion point positioned to the right of the
last "e".  In reverse, if the insertion point is anywhere to the right of the
3rd "a" and I hit down arrow, rather than going down to the right of the last
"b" I'm taken to the right of the 1st "c".
If this cursor misbehaviour is also caused by the same thing as the misbehaving
mouse clicks, the Summary should be updated to reflect that too (not only that
it's the cursor keys, but that it's not just related to text selection w/r/t the
end of a line of text.

Also, I don't believe that this belongs in Editor: Core anymore - it's obvious
by now that it effects more than just that component.  Most likely this should
be moved to Selection. (?)
Text areas fail also.
Flags: blocking1.4b?
patch is in 202834. marking this as dup of that bug

*** This bug has been marked as a duplicate of 202834 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
okay
Status: RESOLVED → VERIFIED
Flags: blocking1.4b?
You need to log in before you can comment on or make changes to this bug.