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?
possibly also a regression from this bug 163235
Keywords: nsbeta1, topembed
Discussed in edt bug triage. Plussing.
Keywords: topembed → topembed+
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.
patch is in 202834. marking this as dup of that bug *** This bug has been marked as a duplicate of 202834 ***
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.