Linux, win_nt 4.0 (1999-07-08-08 m8) Steps to reproduce: 1. From the folder pane, select a pop account 2. Select the Inbox, select a mail from the thread pane 3. Click on Message|Reply to bring up the Reply compose window Actual result: I see the cursor focus in the compose body, but when I type, nothing happens. No new text is displayed. Note: The original text is displayed with header information In Imap: The body of the Reply window is gray, original text is NOT displayed and there is no response when I type. Expected result: I should be able to type text into the body of the message This occurs on Linux and Win_nt 4.0 Will test Mac later.

cc: ducarroz and rhp. Fenella, did you try to actually click your cursor in the compose window body first? There was another bug that I recall on this. Is this on html or plain text compose window?

Might be the same as http://bugzilla.mozilla.org/show_bug.cgi?id=8481

I don't think it's the same as 8481. It happens with either plain text or html message windows.

I should have been clearer: the POP bit may be the same as 8481 (it seems to me to behave that way), but the IMAP issue seems separate, and much worse than the POP issue.

This is an M8 blocker for IMAP replies if there is no workaround available. cc: putterman and bienvenu. I'm going to take the liberty and mark this target milestone M8 for now. (Stacey or Fenella - can you verify that the workaround for POP messages specified in 8481 is working?)

Yup!

I haven't looked at this yet, but adding Simon in case he knows anything about this.

Have you tried adding dump()s to the JS to see if the editorShell is getting created OK? Also, put a breakpoint in nsEditorShell.cpp, PrepareDocumentForEditing(), and see if that get's hit. My guess is that this is a problem loading URLs in the compose window.

I don't think it is the same as 8481. And it happens in either HTML or plain text window. And yes, I did actually mouse over the body area and click the cursor in the compose window body first.

Can anyone display an imap message? I can't do that. If you can't that could explain why the reply window looks wrong.

Yes, I can display IMAP messages. I did get (unreproducibly) into a state today where I wasn't able to, but restarting fixed it.

(Fenella, with the POP thing, I really think you just need to tinker a bit more with where you click...the workaround works for me with the same build you're using, but you have to get it just right....)

Yes, I can read imap messages. But when I reply the compose window comes up and hangs.

Hmmm. Restarting doesn't do anything for me regarding displaying an IMAP message. I also have no problem with POP.

Is the temp message file getting created?

No. I'll go into the debugger and see what is happening.

My imap troubles were due to a server that was down. Now I crash when I reply at: nsSupportsArray::ElementAt(nsSupportsArray * const 0x02cb64f0, unsigned int 1) line 118 + 3 bytes nsSupportsArray::GetElementAt(nsSupportsArray * const 0x02cb64f0, unsigned int 1, nsISupports * * 0x0012c580) line 39 + 16 bytes XPTC_InvokeByIndex(nsISupports * 0x02cb64f0, unsigned int 4, unsigned int 2, nsXPTCVariant * 0x0012c570) line 135 nsXPCWrappedNativeClass::CallWrappedMethod(JSContext * 0x033a5160, nsXPCWrappedNative * 0x02cb44b0, const XPCNativeMemberDescriptor * 0x02cb4de8, nsXPCWrappedNativeClass::CallMode CALL_METHOD, unsigned int 1, long * 0x0242febc, long * 0x0012c778) line 511 + 44 bytes WrappedNative_CallMethod(JSContext * 0x033a5160, JSObject * 0x027e2870, unsigned int 1, long * 0x0242febc, long * 0x0012c778) line 128 js_Invoke(JSContext * 0x033a5160, unsigned int 1, int 0) line 655 + 26 bytes

I realize this may have nothing to do with this bug and that it's probably a duplicated, but the crash I'm getting is below. It's trying to change the ready state of messengercompose.xul. I'm blocked on helping out on this bug until this other crash is fixed. nsSupportsArray::ElementAt(nsSupportsArray * const 0x02f7d2b0, unsigned int 1) line 118 + 3 bytes nsSupportsArray::GetElementAt(nsSupportsArray * const 0x02f7d2b0, unsigned int 1, nsISupports * * 0x0012c580) line 39 + 16 bytes XPTC_InvokeByIndex(nsISupports * 0x02f7d2b0, unsigned int 4, unsigned int 2, nsXPTCVariant * 0x0012c570) line 135 nsXPCWrappedNativeClass::CallWrappedMethod(JSContext * 0x02169290, nsXPCWrappedNative * 0x02f7b1c0, const XPCNativeMemberDescriptor * 0x02f7dde8, nsXPCWrappedNativeClass::CallMode CALL_METHOD, unsigned int 1, long * 0x02800f1c, long * 0x0012c778) line 511 + 44 bytes WrappedNative_CallMethod(JSContext * 0x02169290, JSObject * 0x02849fc0, unsigned int 1, long * 0x02800f1c, long * 0x0012c778) line 128 js_Invoke(JSContext * 0x02169290, unsigned int 1, int 0) line 655 + 26 bytes js_Interpret(JSContext * 0x02169290, long * 0x0012cfa4) line 2217 + 15 bytes js_Invoke(JSContext * 0x02169290, unsigned int 2, int 0) line 671 + 13 bytes js_Interpret(JSContext * 0x02169290, long * 0x0012d78c) line 2217 + 15 bytes js_Invoke(JSContext * 0x02169290, unsigned int 0, int 0) line 671 + 13 bytes js_Interpret(JSContext * 0x02169290, long * 0x0012df74) line 2217 + 15 bytes js_Invoke(JSContext * 0x02169290, unsigned int 1, int 0) line 671 + 13 bytes js_Interpret(JSContext * 0x02169290, long * 0x0012e75c) line 2217 + 15 bytes js_Invoke(JSContext * 0x02169290, unsigned int 0, int 0) line 671 + 13 bytes js_Interpret(JSContext * 0x02169290, long * 0x0012ef44) line 2217 + 15 bytes js_Invoke(JSContext * 0x02169290, unsigned int 1, int 0) line 671 + 13 bytes js_InternalCall(JSContext * 0x02169290, JSObject * 0x027b6d68, long 41643384, unsigned int 1, long * 0x0012f088, long * 0x0012f090) line 749 + 15 bytes JS_CallFunctionValue(JSContext * 0x02169290, JSObject * 0x027b6d68, long 41643384, unsigned int 1, long * 0x0012f088, long * 0x0012f090) line 2643 + 29 bytes nsJSEventListener::HandleEvent(nsIDOMEvent * 0x0302cfd0) line 97 + 34 bytes nsEventListenerManager::HandleEvent(nsIPresContext & {...}, nsEvent * 0x0012f284, nsIDOMEvent * * 0x0012f230, unsigned int 3, nsEventStatus & nsEventStatus_eIgnore) line 899 + 21 bytes RDFElementImpl::HandleDOMEvent(RDFElementImpl * const 0x02c09ec0, nsIPresContext & {...}, nsEvent * 0x0012f284, nsIDOMEvent * * 0x0012f230, unsigned int 1, nsEventStatus & nsEventStatus_eIgnore) line 2351 RDFElementImpl::ExecuteJSCode(nsIDOMElement * 0x02c09eb0) line 2690 RDFElementImpl::ExecuteOnChangeHandler(nsIDOMElement * 0x026f4520, const nsString & {"ready"}) line 2613 + 14 bytes RDFElementImpl::SetAttribute(RDFElementImpl * const 0x02c09f50, int 0, nsIAtom * 0x02c0ae50 {"ready"}, const nsString & {"true"}, int 1) line 1958 RDFXULBuilderImpl::AddAttribute(nsIContent * 0x02c09f50, nsIRDFResource * 0x02c0a5b0, nsIRDFNode * 0x0217f5d0) line 2873 + 31 bytes RDFXULBuilderImpl::OnChange(RDFXULBuilderImpl * const 0x0216abe4, nsIRDFResource * 0x02b923d0, nsIRDFResource * 0x02c0a5b0, nsIRDFNode * 0x02b92d30, nsIRDFNode * 0x0217f5d0) line 1327 + 31 bytes CompositeDataSourceImpl::OnChange(CompositeDataSourceImpl * const 0x0216ac44, nsIRDFResource * 0x02b923d0, nsIRDFResource * 0x02c0a5b0, nsIRDFNode * 0x02b92d30, nsIRDFNode * 0x0217f5d0) line 1411 InMemoryDataSource::Change(InMemoryDataSource * const 0x0216aab0, nsIRDFResource * 0x02b923d0, nsIRDFResource * 0x02c0a5b0, nsIRDFNode * 0x02b92d30, nsIRDFNode * 0x0217f5d0) line 1241 CompositeDataSourceImpl::Change(CompositeDataSourceImpl * const 0x0216ac40, nsIRDFResource * 0x02b923d0, nsIRDFResource * 0x02c0a5b0, nsIRDFNode * 0x02b92d30, nsIRDFNode * 0x0217f5d0) line 946 + 28 bytes RDFXULBuilderImpl::OnSetAttribute(RDFXULBuilderImpl * const 0x0216abec, nsIDOMElement * 0x02c09f40, const nsString & {"ready"}, const nsString & {"true"}) line 1777 + 71 bytes XULDocumentImpl::OnSetAttribute(XULDocumentImpl * const 0x02168e78, nsIDOMElement * 0x02c09f40, const nsString & {"ready"}, const nsString & {"true"}) line 3735 RDFElementImpl::SetAttribute(RDFElementImpl * const 0x02c09f40, const nsString & {"ready"}, const nsString & {"true"}) line 916 setAttribute(nsIWebShell * 0x0216a520, const char * 0x017daf88, const char * 0x017daf80, const nsString & {"true"}) line 267 + 57 bytes nsArgCallbacks::ConstructBeforeJavaScript(nsArgCallbacks * const 0x0216a310, nsIWebShell * 0x0216a520) line 299 + 41 bytes nsWebShellWindow::ExecuteStartupCode() line 2170 nsWebShellWindow::OnEndDocumentLoad(nsWebShellWindow * const 0x0216a03c, nsIDocumentLoader * 0x02168690, nsIURI * 0x0216b630, int 0, nsIDocumentLoaderObserver * 0x0216a534) line 1798 nsWebShell::OnEndDocumentLoad(nsWebShell * const 0x0216a534, nsIDocumentLoader * 0x02168690, nsIURI * 0x0216b630, int 0, nsIDocumentLoaderObserver * 0x0216a534) line 3008 nsDocLoaderImpl::FireOnEndDocumentLoad(nsIDocumentLoader * 0x02168690, int 0) line 1030 nsDocLoaderImpl::LoadURLComplete(nsIURI * 0x02c68770, nsISupports * 0x02c68530, int 0) line 1306 nsDocumentBindInfo::OnStopRequest(nsDocumentBindInfo * const 0x02c68530, nsIURI * 0x02c68770, unsigned int 0, const unsigned short * 0x02e2cc50) line 2033 OnStopRequestProxyEvent::HandleEvent(OnStopRequestProxyEvent * const 0x02e2b590) line 593 + 45 bytes StreamListenerProxyEvent::HandlePLEvent(PLEvent * 0x02e2b594) line 473 + 12 bytes PL_HandleEvent(PLEvent * 0x02e2b594) line 493 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x01064620) line 454 + 9 bytes _md_EventReceiverProc(HWND__ * 0x01c50a60, unsigned int 49451, unsigned int 0, long 17188384) line 912 + 9 bytes USER32! 77e71250() 01064620()

This problem also occurs on Mac (1999-07-08-10 m8) Stacey, you are right. In pop, if I double click my cursor right before the original text, I am able to type. So I am changing this bug to IMAP only.

who can/is fix the xul file?

Chris W., does the crash I listed mean anything to you?

I'm pulling a tree to see if maybe someone checked something in that fixes this. I will try again later from home where maybe I can get further. There must be some reason why I crash and nobody else does!

This is what it means to me: somebody is calling GetElementAt() on an nsISupportsArray from JavaScript. Are we sure that the wrapper got constructed correcly (probably it did). Are we sure that the nsISupportsArray is initialized ok? What specifically is the crash? But you probably knew all that :)...

At what stage is this ready property set? Should I be looking in the onload handler? Is this js code in messengercompose.xul or someplace else? I just don't know where we are in window creation.

The reply problem with IMAP seems to be due to the new asynchronus quoting. When JS ask the backend to load the body in the ender (nsMsgCompose::LoadFields), nothing append because the backend is waiting on a asyncronus load of the original message that never come/finish. Scott, you should reassign this bug to rhp which should be able to fix it, I hope.

(Scott - if you still have a problem with your crash, then that should get filed as a separate bug from this one, I think (?))

That sounds perfect to me. Reassigning to rhp. I'm still bothered by the fact that no one else is crashing. I crash at home as well. I'll look at it for a bit more.

I don't think this is a regression. It doesn't work because the call I make to retrieve the body of the mail message only supports pop folders. I have a feeling I know what is going on here, but we aren't going to fix this for M8 are we? - rhp

Can we not make this call for imap messages? Is there a simple workaround?

Uh, not sure if there is an easy fix. Plus, my tree is so far removed from trunk right now, it would take me a bit to get back there just to look at the issue. There is a fix where you can turn off the new quoting with a pref to work around it. I would rather go with that. - rhp

I can live with that.

For those who care, my crash was being caused by 9081 which I now have a fix for. This was a problem when you had more than 4 accounts.

Ok, I see what the problem is here and I have addressed it in my tree, but I would rather wait until past M8 to do a checking because I have a ton of changes in my tree. oh, unfortunately, the pref hack may not work. I can fix that with a one line change if we need to...tell me what you would like me to do. - rhp

Is the fix for this bug big? Is it something you could email me that I could checkin since I don't have any changes in the files you are touching.

The proper fix for this bug is in a few files, so I would rather not try to translate it over to your tree, but the fix for the pref hack is a single line...that we could do easily. Just AIM me if you want to give that a try. - rhp

Why is this M9? We still need a fix or some workaround for this in M8. Maybe I'm not understanding the past few comments accurately. If this is to be fixed in M9, what is the workaround in M8 so I can tell my group as well as update the release notes. Thanks.

The workaround is set the mail.old_quoting pref to true for IMAP and it should work. Scott Putterman needs to check in a one line fix to make this work, but he will do this today. - rhp

I checked in Rich's workaround. You'll need to set the pref for it to work. We should leave this as M9 since the real fix hasn't gone in yet.

Update, 7_12 Linux: mail.old_quoting = true doesn't seem to make any difference, but with or without it, I'm able to reply to IMAP messages in some manner. I get a gray background on the compose window, no signature, I can't use my arrow keys, but I CAN type, after placing my cursor near the first character of the quoted text, and I can select words that I've typed and retype over them.

This is fixed by us not doing multiple loads of URL's into Ender as well as Ender actually handling this now. - rhp

Linux (1999-08-03-08 m9) and win_nt 4.0 (1999-08-04-08 M9) I try this using both HTML and plain text window, both works fine. This problem has been fixed.

I have not tested Mac because today's Mac build does not passed smoke test. Since this bug was not tested on Mac in the original report, I am going to mark this Verified.