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




15 years ago
15 years ago


(Reporter: sairuh (rarely reading bugmail), Assigned: Joe Francis)


({regression, topembed+})

regression, topembed+

Firefox Tracking Flags

(Not tracked)


(Whiteboard: edt_x3,edt_b3,edt_c3)



15 years ago
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:

here is some text.<br>

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

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.
I see this also in the win32 mail text-composer
OS: Linux → All
*** Bug 202709 has been marked as a duplicate of this bug. ***

Comment 3

15 years ago
From dupe: this regressed between 2003041709 and 2003041804
*** Bug 202781 has been marked as a duplicate of this bug. ***

Comment 5

15 years ago
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.

Comment 6

15 years ago
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

Comment 7

15 years ago
Is this a regression from 195080?
Could someone try backing out that patch and confirming my suspicions?

Comment 8

15 years ago
Maybe a regression from the checkin in nsSelection.cpp (bug 191498 and bug 192167)

Comment 9

15 years ago
possibly also a regression from this bug 163235


15 years ago
Hardware: PC → All

Comment 10

15 years ago
Keywords: nsbeta1, topembed

Comment 11

15 years ago
Discussed in edt bug triage.  Plussing.
Keywords: topembed → topembed+
Whiteboard: edt_x3,edt_b3,edt_c3

Comment 12

15 years ago
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'

Comment 13

15 years ago
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

Comment 14

15 years ago
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)

Comment 15

15 years ago
*** Bug 202568 has been marked as a duplicate of this bug. ***

Comment 16

15 years ago
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):


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".

Comment 17

15 years ago
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. (?)

Comment 18

15 years ago
Text areas fail also.


15 years ago
Flags: blocking1.4b?

Comment 19

15 years ago
patch is in 202834. marking this as dup of that bug

*** This bug has been marked as a duplicate of 202834 ***
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE

Comment 20

15 years ago


15 years ago
Flags: blocking1.4b?
You need to log in before you can comment on or make changes to this bug.