click / cursor problems in mail compose / editor (works better on reply, than with new messages) if I compose a new message, with this for the body: this is a body test, more to follow this is a body test, more to follow this is a body test, more to follow this is a body test, more to follow this is a body test, more to follow so now imagine your compose window / editor new page as four quadrants. lines of text(1) blank(2) blank(3) blank(4) clicking in blank(4) doesn't seem to do the right thing: move the cursor to the end of the document. clicking in (2) and (3) seem to work ok. note, doing this in a quoted reply seems to work much better, except that double clicking in blank(2) (when this is a reply) opens up the "advanced property edit" dialog for the block quote element. that sounds like an editor feature that has made it's way into html mail compose (on accident?)
> except that double clicking in blank(2) (when this is a reply) opens up the > "advanced property edit" dialog for the block quote element. that sounds like > an editor feature that has made it's way into html mail compose (on accident?) I get a similar dialog, when double clicking beyond a line that is a link (I get the link properties dialog). I'll spin this issue to another bug.
--> mjudge Seth is this a regression? If so I'm wondering if it's a dup of bug 202677.
brendan seems to think it is a recent regression, so this might be a dup.
I believe this is a recent regresion. I believe I started seeing it in Thunderbird between Thursday and this weekend (my two cents from the peanut gallery). Those dates seem to match up well with when Bug #202677 was filed.
15 years ago
I believe this is a dupe of bug 202677, but that's a nice description of the problem
Created attachment 121300 [details] [diff] [review] patch for nsLineBox in layout\html\base\src fixes the regression. the regression was caused from the bug to prevent caret jumping on lines with 0 width frames. This fixes the logic involved in finding the proper frame on the line without going beyond the lines boundaries.
*** Bug 202677 has been marked as a duplicate of this bug. ***
Comments from bug 202677: This 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. 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 a 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". -> All/All. Product / Summary should also be changed to Browser / Selection. (Or at least to something other than MailNews/Composition specific.)
I experiment same problem reported in comment #8. Build 2003042112.
Comment on attachment 121300 [details] [diff] [review] patch for nsLineBox in layout\html\base\src email@example.com
Confirming that all textarea mouse/cursor key problems are now fixed (what a relief). I can't mark this Verified, however, since I don't use Mail/News and can't confirm that aspect of the bug.
I would say yes, confirmed fixed, but... One would expect that if you mouse clicked below the end of a new mail's sig text that the cursor would position to the end of the last line of the sig. It positions in the line vertically above the mouse click. I assume that might be cosnidered a new bug?
firstname.lastname@example.org (comment 13)--I'm guessing you are on Windows? That is expected behavior on Windows (I believe most (not all) editors on Windows behave like this). On Mac (and maybe linux?) there is a pref to get the behavior you desire. Conclusion--if you are on windows, it is not a regression--it is intended behavior; else please file a bug.
Yes, Winderz. Filing a bug with Redmond now...
even though the problem i had seen in bug 202677 is now fixed, i think the fix here caused bug 195080 to regress.
Using trunk builds 20030424 on linux and 20030423 on winxp and macosx this bug as originally reported is fixed. Verified, Note: bug 195080 is opened and a possible regression due to the fix of this bug.
The bug is back (regression again?) on 1.6 and 1.7b (both macosx). BTW, it's as bad on replies as on new messages for me.