Closed
Bug 9455
Opened 25 years ago
Closed 25 years ago
Regression:IMAP only:Reply-Unable to type in Compose body
Categories
(MailNews Core :: Composition, defect, P3)
MailNews Core
Composition
Tracking
(Not tracked)
VERIFIED
FIXED
M9
People
(Reporter: fenella, Assigned: rhp)
Details
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.
Summary: Regression: Reply - Unable to type in the Compose body → Regression: Reply - Unable to type in the mail Compose body
Target Milestone: M8
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?)
Comment 7•25 years ago
|
||
I haven't looked at this yet, but adding Simon in case he knows anything about
this.
Comment 8•25 years ago
|
||
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.
Comment 10•25 years ago
|
||
Can anyone display an imap message? I can't do that. If you can't that could
explain why the reply window looks wrong.
Comment 11•25 years ago
|
||
Yes, I can display IMAP messages. I did get (unreproducibly) into a state today
where I wasn't able to, but restarting fixed it.
Comment 12•25 years ago
|
||
(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....)
Comment 13•25 years ago
|
||
Yes, I can read imap messages. But when I reply the compose window comes up and
hangs.
Comment 14•25 years ago
|
||
Hmmm. Restarting doesn't do anything for me regarding displaying an IMAP
message. I also have no problem with POP.
Comment 15•25 years ago
|
||
Is the temp message file getting created?
Comment 16•25 years ago
|
||
No. I'll go into the debugger and see what is happening.
Comment 17•25 years ago
|
||
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
Comment 18•25 years ago
|
||
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()
Summary: Regression: Reply - Unable to type in the mail Compose body → Regression:IMAP only:Reply-Unable to type in Compose body
Reporter | ||
Comment 19•25 years ago
|
||
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.
Updated•25 years ago
|
Assignee: phil → putterman
Comment 20•25 years ago
|
||
who can/is fix the xul file?
Comment 21•25 years ago
|
||
Chris W., does the crash I listed mean anything to you?
Comment 22•25 years ago
|
||
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!
Comment 23•25 years ago
|
||
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 :)...
Comment 24•25 years ago
|
||
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.
Comment 25•25 years ago
|
||
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.
Comment 26•25 years ago
|
||
(Scott - if you still have a problem with your crash, then that should get filed
as a separate bug from this one, I think (?))
Updated•25 years ago
|
Assignee: putterman → rhp
Comment 27•25 years ago
|
||
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.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 28•25 years ago
|
||
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
Comment 29•25 years ago
|
||
Can we not make this call for imap messages? Is there a simple workaround?
Assignee | ||
Comment 30•25 years ago
|
||
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
Comment 31•25 years ago
|
||
I can live with that.
Comment 32•25 years ago
|
||
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.
Assignee | ||
Updated•25 years ago
|
Target Milestone: M8 → M9
Assignee | ||
Comment 33•25 years ago
|
||
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
Comment 34•25 years ago
|
||
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.
Assignee | ||
Comment 35•25 years ago
|
||
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
Comment 36•25 years ago
|
||
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.
Assignee | ||
Comment 37•25 years ago
|
||
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
Comment 38•25 years ago
|
||
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.
Comment 39•25 years ago
|
||
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.
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 40•25 years ago
|
||
This is fixed by us not doing multiple loads of URL's into Ender as well as
Ender actually handling this now.
- rhp
Reporter | ||
Comment 41•25 years ago
|
||
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.
Reporter | ||
Comment 42•25 years ago
|
||
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.
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
•