Closed Bug 173818 Opened 23 years ago Closed 23 years ago

First char typed in reply causes caret to jump a line [can't type in plain text editor when replying or signature present]

Categories

(MailNews Core :: Composition, defect)

Product:
MailNews Core
Component:
Composition
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.2beta

People

(Reporter: scottputterman, Assigned: mozeditor)

References

Details

(Keywords: regression, Whiteboard: [adt1])

Attachments

(1 file)

patch to nsHTMLEditor.cpp
720 bytes, patch
akkzilla
: review+
kinmoz
: superreview+
asa
: approval+
Details | Diff | Splinter Review
Using 10/10/02 build on XP 1. Reply to a message 2. The caret is in the body. Type 'a' 3. Instead of the letter 'a' appearing, the caret moves down a line and nothing shows up We need to fix this for mozilla1.2Beta
Keywords: nsbeta1+
Whiteboard: [adt1]
reassigning to akkana. It was suggested I should reassign this to the editor team. If it's a mail bug, please reassign back.
Assignee: ducarroz → akkana
Sounds related to issues Joe is working on.
Assignee: akkana → jfrancis
BTW, I don't see this on linux, but you didn't indicate any of your settings so there are a lot of variables. Html? Plain? Auto-quote? Reply before or after quoted text?
HTML, auto quote, reply before. All of the defaults for the Netscape builds :)
I think reply before was the key -- if I set that, I see this too. I traced it into InsertElementTxn::DoTransaction, line 116: result = mParent->InsertBefore(mNode, refNode, getter_AddRefs(resultNode)); and this fails, returning result = 2147500037 = 0x7fffffff. But gdb isn't letting me step into InsertBefore to find out what type mParent is or why InsertBefore is failing. I defer to Joe for now, who knows a lot more about how these routines work. Joe, any ideas? Feel free to kick it back to me if you think it's something I did -- maybe the caret is in a weird place? But it looks okay and it's a normal text-sized caret, not an ubercaret.
setting as 1.2 beta, since I'm going to ask mozilla.org not to ship 1.2 beta with this regression.
Keywords: regression
Target Milestone: --- → mozilla1.2beta
Seth, I agree. This regression shouldn't go out in Mozilla 1.2
Blocks: 1.2b
Here's the assertion I get on win32: ###!!! ASSERTION: transaction did not execute properly : '(NS_SUCCEEDED(result))', file c:/builds/buffy/mozilla/editor/libeditor/base/nsEditor.cpp, line 540
My fix for bug 174369 doesn't fix this one.
investigating...
Status: NEW → ASSIGNED
It looks like the selection is inside a br when this happens (i.e. when the user goes to hit the first character). It's not clear how the selection ended up there. Clicking in the document before typing the character makes the bug disappear.
OS: Windows XP → All
Hardware: PC → All
Summary: Typing causes caret to jump a line → First char typed in reply causes caret to jump a line
Blocks: 1.2
No longer blocks: 1.2b
*** Bug 174773 has been marked as a duplicate of this bug. ***
Here's the stack when that selection setting happens: #0 nsTypedSelection::Collapse (this=0x8b8d8f8, aParentNode=0x8b89238, aOffset=0) at nsSelection.cpp:6168 #1 0x447cc2f3 in nsHTMLEditor::BeginningOfDocument (this=0x8984c88) at nsHTMLEditor.cpp:525 #2 0x44992bcd in nsMsgCompose::ConvertAndLoadComposeWindow (this=0x8b65f98, aPrefix=@0x8be0580, aBuf=@0x8be0570, aSignature=@0x8be0590, aQuoted=1, aHTMLEditor=1) at nsMsgCompose.cpp:680 That nsHTMLEditor::BeginningOfDocument method is new (jfrancis v. 1.44); prior to that I think we fell back to nsPlaintextEditor::BeginningOfDocument. If I insert: return nsPlaintextEditor::BeginningOfDocument(); at the beginning of nsHTMLEditor::BeginningOfDocument(), then I can type the first character correctly. So we need Joe to tell us the appropriate fix for this, or else we need to back out that routine (or run around it like I did).
Attached patch patch to nsHTMLEditor.cpp — — Splinter Review
possible fix; i am blocked on testing right now by an unrelated prob
Comment on attachment 103112 [details] [diff] [review] patch to nsHTMLEditor.cpp This does indeed fix the problem -- thanks! I'm not too clear on the address_of thing, but I see that's the pattern already used elsewhere in this file, so this is nothing new. r=akkana
Attachment #103112 - Flags: review+
Attachment #103112 - Flags: superreview+
Comment on attachment 103112 [details] [diff] [review] patch to nsHTMLEditor.cpp sr=kin@netscape.com
Comment on attachment 103112 [details] [diff] [review] patch to nsHTMLEditor.cpp a=asa for checkin to 1.2 (on behalf of drivers)
Attachment #103112 - Flags: approval+
fix landed on trunk
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
jfrancis: thanks for fixing this for 1.2 beta.
*** Bug 174342 has been marked as a duplicate of this bug. ***
I'm seeing this again in Moz 1.2b (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016). Occurs on both new messages and replys - tabbing into the compose window, the first character is eaten, and the second one jumps down a line.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Michael, the fix landed on the 16th (at night, no less), so of course it's not in the build you referenced: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016) Re-closing
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
*** Bug 174712 has been marked as a duplicate of this bug. ***
*** Bug 175148 has been marked as a duplicate of this bug. ***
*** Bug 175249 has been marked as a duplicate of this bug. ***
*** Bug 175393 has been marked as a duplicate of this bug. ***
*** Bug 173769 has been marked as a duplicate of this bug. ***
*** Bug 175512 has been marked as a duplicate of this bug. ***
Summary: First char typed in reply causes caret to jump a line → First char typed in reply causes caret to jump a line [can't type in plain text editor when replying or signature present]
*** Bug 175444 has been marked as a duplicate of this bug. ***
*** Bug 175473 has been marked as a duplicate of this bug. ***
*** Bug 175557 has been marked as a duplicate of this bug. ***
*** Bug 175665 has been marked as a duplicate of this bug. ***
*** Bug 175654 has been marked as a duplicate of this bug. ***
*** Bug 175952 has been marked as a duplicate of this bug. ***
*** Bug 176033 has been marked as a duplicate of this bug. ***
*** Bug 176021 has been marked as a duplicate of this bug. ***
*** Bug 174998 has been marked as a duplicate of this bug. ***
*** Bug 176039 has been marked as a duplicate of this bug. ***
*** Bug 176136 has been marked as a duplicate of this bug. ***
*** Bug 176223 has been marked as a duplicate of this bug. ***
Confirmed I saw the orininally stated problem with a 10-16 trunk build on linux and winxp. I also saw the problem when clicking Reply when in a plain text compose window the text did not display when user started typing. Verified these are both fixed with a 10-17 trunk build and a a 10-22 branch build even though this was not mentioned that it was checked into the branch. I will check though the scenarios in the dups to see if they are similar to the two mentioned above.
Status: RESOLVED → VERIFIED
OK, another dup bug 175665 mentions New Msg window with a plain text signature has the problem. This was the missing criteria to see the problem in a New Msg window, I did see this and it is fixed too.
It's NOT fixed, as it's still happing with build 2002101612. It's still happening...
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
chris, see comment 23. Re-resolving.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Re-verifying.
Status: RESOLVED → VERIFIED
*** Bug 176562 has been marked as a duplicate of this bug. ***
*** Bug 177073 has been marked as a duplicate of this bug. ***
*** Bug 177169 has been marked as a duplicate of this bug. ***
*** Bug 176719 has been marked as a duplicate of this bug. ***
*** Bug 177108 has been marked as a duplicate of this bug. ***
*** Bug 177231 has been marked as a duplicate of this bug. ***
*** Bug 177295 has been marked as a duplicate of this bug. ***
How do I get myself off this distribution list? I am not a programmer and I get 5-10 of these a day. Please help...
*** Bug 177327 has been marked as a duplicate of this bug. ***
OK. How do I update my version to the new "trunk??" build??? I am seeing this cpp and guessing it is a C-plusplus file which indicates to me that I would have to compile to check? Let me know if there is a way I can check the latest build. I do not mind being on the "bleeding" edge and testing. In fact, I want to do more. Thanx, Jim jim@leaders.net
I'm seeing similar in Mozilla 1.2b. I have the original message after my reply, compose in plain text. When i click Reply or Forward and tab into the message body, my cursor sits there and flashes, but does not move or do anything as I type text. I need to actually *click* in the message body before it begins accepting keyboard input as normal.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
I'm on Windows 2k.
I've just checked with the latest nightly build (2002102908) and I no longer experience the bug.
Jase Roberts: that you see it in 1.2b is because it was fixed _after_ 1.2b. Reresolving again. See comment 23. (Which was mentioned before.) Jim Garner: You can download nightly builds of Mozilla (in which this bug is fixed) from ftp://ftp.mozilla.org/pub/mozilla/nightly/latest-trunk/
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
re-verifying. Additionally, jim garner: if you want to help out with testing mozilla, this page serves as a good starting point: http://www.mozilla.org/quality/help/
Status: RESOLVED → VERIFIED
*** Bug 177754 has been marked as a duplicate of this bug. ***
*** Bug 177575 has been marked as a duplicate of this bug. ***
*** Bug 178176 has been marked as a duplicate of this bug. ***
*** Bug 178231 has been marked as a duplicate of this bug. ***
Is this related to Bug 82534 (the current most popular)?
*** Bug 178320 has been marked as a duplicate of this bug. ***
*** Bug 175935 has been marked as a duplicate of this bug. ***
*** Bug 178356 has been marked as a duplicate of this bug. ***
*** Bug 178496 has been marked as a duplicate of this bug. ***
*** Bug 178505 has been marked as a duplicate of this bug. ***
do you can investigated if this bug http://bugzilla.mozilla.org/show_bug.cgi?id=178537 have a relation?
*** Bug 178581 has been marked as a duplicate of this bug. ***
*** Bug 178586 has been marked as a duplicate of this bug. ***
*** Bug 178712 has been marked as a duplicate of this bug. ***
*** Bug 178914 has been marked as a duplicate of this bug. ***
*** Bug 177472 has been marked as a duplicate of this bug. ***
*** Bug 179640 has been marked as a duplicate of this bug. ***
*** Bug 179216 has been marked as a duplicate of this bug. ***
This is still getting a lot of dups. Let's set it Resolved/Fixed rather than Verified/Fixed so it shows up on the Duplicates list.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Re-resolving Fixed. Let's leave it unverified until 1.2 ships.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
*** Bug 179811 has been marked as a duplicate of this bug. ***
*** Bug 180235 has been marked as a duplicate of this bug. ***
*** Bug 182223 has been marked as a duplicate of this bug. ***
*** Bug 182361 has been marked as a duplicate of this bug. ***
verified
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: