Closed Bug 18922 Opened 25 years ago Closed 25 years ago

[DOGFOOD][REGRESSION][BLOCKER] Application hangs after Reply button is applied

Categories

(MailNews Core :: Composition, defect, P3)

x86
Linux
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: ji, Assigned: bugzilla)

References

Details

(Whiteboard: [PDT+])

Using today's Linux M12 1999111512 build, clicking on Reply button, the
reply compose window in HTML format comes up, but the recepient email
address doesn't show and the whole application hangs.

Steps of reproduce:
1. Highlight one mail in the thread pane,
2. Click on Reply button.
jj, can you reproduce the problem everytime?

what the content of the console window (output)?
I got this everytime (I tried 5 or 6 time).
And in the console window, I got:
....
Attaching to WebShellWindow[_blank]
RECEIVE CALLBACK: OnHeaderReady
Status: NEW → ASSIGNED
Target Milestone: M12
Ok, it's turn out that we it an infinity loop when we ask editor to position the cursor at the top of the document
(nsIEditor::BeginningOfDocument).

You can work around this problem either by adding the following prefs to your prefs.js file:
	user_pref("mailnews.reply_on_top", 2);

I will file a bug against editor for the problem with nsIEditor::BeginningOfDocument
Depends on: 18938
Severity: major → critical
Hardware: Other → PC
Summary: Browser hangs after Reply button is applied → [DOGFOOD] [REGRESSION] Application hangs after Reply button is applied
Summary: [DOGFOOD] [REGRESSION] Application hangs after Reply button is applied → [DOGFOOD][REGRESSION] Application hangs after Reply button is applied
I'd almost like to make this a blocker.
Severity: critical → blocker
Summary: [DOGFOOD][REGRESSION] Application hangs after Reply button is applied → [DOGFOOD][REGRESSION][BLOCKER] Application hangs after Reply button is applied
leaf - this came up. Can we keep the mozilla tree closed for this?
bug 18938 has been filed against editor
Whiteboard: [PDT+]
Putting on the PDT+ radar.
fixed - problem was the usage of an unfinished iterator feature: MakePre().  I
rewrote nsEditor::GetFirstEditableNode() and nsEditor::GetLastEditableNode() to
not use this iterator feature (indeed to not use iterators at all).

It works fine now although the caret might not be where you expect in the
EndOfDocument() case: it appears at the end of the quoted text rather on a line
after it.  However, when you type the new text appears in the right place.  I
think the caret issue will be fixed by some work I'm checking in later this week.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
QA Contact: lchiang → fenella
Fenella - can you help verify this? Thanks.
Status: RESOLVED → VERIFIED
Since today 11/19 build crash on startup, I am using the 11/18
(1999-11-18-08 M12) to verify the bug.  This problem does not occur on POP.
IMAP message does not load on the 11/18 build.
Since this bug does not say IMAP or POP, I am going to close this bug. if I see
the problem happen on IMAP in the future, I'll file a separate bug.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.