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)
Tracking
(Not tracked)
VERIFIED
FIXED
M12
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.
Assignee | ||
Comment 1•25 years ago
|
||
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
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M12
Assignee | ||
Comment 3•25 years ago
|
||
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
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
Severity: critical → blocker
Summary: [DOGFOOD][REGRESSION] Application hangs after Reply button is applied → [DOGFOOD][REGRESSION][BLOCKER] Application hangs after Reply button is applied
Comment 8•25 years ago
|
||
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
Comment 10•25 years ago
|
||
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.
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•