Closed Bug 157811 Opened 22 years ago Closed 22 years ago

plain text compose and reply busted

Categories

(MailNews Core :: Composition, defect)

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

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: endico, Assigned: bugzilla)

References

Details

(Keywords: smoketest) 

uncheck 'compose messages in HTML format' in prefs.

reply to a mail. The compose window is displayed but the only field filled out
is the subject. None of the address fields are filled in.

Type an address in the To: field and press enter. The cursor should
move to the next line and create a new To: field. It does not. Its
impossible to get any more address fields. Address fields are broken in
new compose windows as well.

the problem seems to have started with today's nightly build. Myk says
that yesterday's build works fine. Asa isn't able to reproduce the problem
with win32.

Removing the xul fastload file doesn't fix the problem. Nothing shows up
in the js console.

When a new mail compose window is started from a terminal window, this is
echoed to the screen when a mail compose window is opened:

----------------------
PrepareDocumentForEditing
marking as smoketest blocker at asa's request. setting meehan as
qa contact at sdonner's request.
Severity: normal → blocker
Keywords: smoketest
QA Contact: esther → meehansqa
Accepting an looking into it...
Status: NEW → ASSIGNED
This is working in yesterday's trunk build and broken in today's trunk build
Here's the hook from yesterday. The only suspicious checkin is mjudge
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=Head&date=explicit&mindate=07/15/2002+09:00&maxdate=07/16/2002+09:00
Right, nothing changed in mailnews, therefore an editor problem! maybe a api
change not reflected in mailnews/compose?

Does this problem occurs on other platform? (I don' have an up-to-date build yet)
*** Bug 157815 has been marked as a duplicate of this bug. ***
append on WinXP (see bug 157815)
OS: Linux → All
Hardware: PC → All
here is the js error which probably cause the problem:

WEBSHELL+ = 6
CSS Error (chrome://global/skin/menulist.css :182.27): Error in parsing value
for property '-moz-border-radius'.  Declaration droppe
d.
[nsIMsgIdentity: id2],[nsIMsgIdentity: id3],[nsIMsgIdentity:
id4],[nsIMsgIdentity: id1]
CREATE nsMsgCompose: 64a3a30
----------------------
PrepareDocumentForEditing
goUpdateTableMenuItems: too early, not initialized
************************************************************
* Call to xpconnect wrapped JSObject produced this error:  *
[Exception... "Security error"  code: "1000" nsresult: "0x805303e8
(NS_ERROR_DOM_SECURITY_ERR)"  location: "chrome://editor/content/
editor.js Line: 2335"]
************************************************************

the problem occurs only with brand new created compose window. If a recycled
compose window is reused, plain text replie work well.

The compose window first call editor to register a DocumentStateListener, then
it call editor to load about:blank. The problem is that message compose never
get the NotifyDocumentCreated callback from editor!

Simon, Mike, any idea?
the document state listener regitered my the message compose is never called
because another one (probably registered by editor) failed which cause the loop
to stop sending notification in nsEditor::NotifyDocumentListeners
the function EditorSetDefaultPrefsAndDoctype() in nsEditor.js failed on the
following line (2224):

          AddAttrToElem(domdoc, "http-equiv", "content-type", element);

Because of:
************************************************************
* Call to xpconnect wrapped JSObject produced this error:  *
[Exception... "Security error"  code: "1000" nsresult: "0x805303e8
(NS_ERROR_DOM_SECURITY_ERR)"  location: "chrome://editor/content/
editor.js Line: 2356"]
************************************************************
BTW, using a plain text composer (editor) produce the same error!
cc'ing jst in case the regression has anything to do with the fix for bug 156452
plain text compose, reply and reply all are working fine for me in an IMAP
account. plain text compose in a POP account, however, only allows one
addressee. Otherwise it's working fine for me; with reply and reply all the
subject, message body addressee fields are all working. I'm not sure if this is
technically a blocker, but since Asa wants it as such, so it stays.  POP usage
is a bummer with this bug.
I'm not seeing this bug on this morning's trunk MacOSX build (2002071703)

*** Bug 157929 has been marked as a duplicate of this bug. ***
I see the problem (only allows one addressee) using 7/16 commercial trunk, 7/15
commercial trunk does not have the problem. I am using IMAP.

Other problem started from yesterday is that "To:" field is empty for new
compose by addressbook/mailto (bug 157759).
i still see the same problem with today's trunk build.
I also see the problem (2002-07-17-08 Linux), and it's consistent.  It always
fails, it fails for all my accounts, and changing to HTML mode always fixes it.
note that Myk and i are using the mozilla build, and i believe the
rest of you are testing the netscape builds.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020717
*** Bug 157759 has been marked as a duplicate of this bug. ***
I am still building a Mozilla debug build on Windows...
but for what I have investigated with yesterday's debug build, this is not a
mail compose bug but rather a problem between editor and DOM. Plain text editor
cannot add dom attributes for security reason!!! seen comment #8, #9 and #10 for
full explanation.
A simple try/catch in editor.js may fix this issue for plaintext reply but I
don't know about the addressee stuff.  This sounds like a regression due to bug
156452 but I'm just guessing.
Unable to reproduce on Mac 9.1 using Mozilla trunk build Mozilla/5.0 (Macintosh;
U; PPC; en-US; rv:1.1b) Gecko/20020717
the fact you cannot enter more than one address in a brand new plain text window
(works fine with recyled window) is the same problem than the blank body.
Message compose need the DocumentCreated notofication from editor in order to
finish its initialization.
I have a fix in my tree, testing it now...
Since Jonas' fix can't land, I propose we take the patch in bug 157851 which
will fix this bug.
I have checked in patch in bug 157851 so I am resolving this bug as fixed.

The real problem here is that the plaintext mail editor is calling too much in
editor.js because it's type isn't being detected correctly.  JFD or someone
should file a bug about that.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
verified; plain text compose is working again...as seen on trunk builds:
linux 2002-07-18-04-trunk
mac os9 2002-07-18-03-trunk
Status: RESOLVED → VERIFIED
I don't think twalker is the best person to verify this bug
since he didn't see the problem in the first place. Can someone
else verify too before we release 1.1b? I'm on my way out the
door for vacation.
I am confirming comment #29.

It works perfectly. Thanks for the quick fix.

Using trunk build 2002071804 - WinXP.
WFM. Another datapoint, although XP also.
Fixed on linux
Bug present in 2002071704
Bug fixed in 2002071808
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.