Closed Bug 9139 Opened 25 years ago Closed 25 years ago

[Regression] Plain text mail ASCII/Latin 1input into body is disabled when the plain text option is on

Categories

(MailNews Core :: Composition, defect, P3)

Product:
MailNews Core
Component:
Composition
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 9153

People

(Reporter: momoi, Assigned: sfraser_bugs)

Details

** observed with 7/1/99 Win32 build **

With the pref option, "compose_html, false" inserted into the
prefs50.html or with pref line for this (Cf. Bug 9021), we get
plain text mail editing window.

But I cannot input any characters for ASCII or Latin 1.
Interestingly, I can input Japanese but some of its functionalities
seem to be disabled, e.g. deleting "comitted" characters don't
work at all.

Currently we can test Japanese send only with plain text mail,
this makes it very difficult to conduct our testing.
Severity: normal → critical
OS: Windows NT → All
Hardware: PC → All
Summary: Plain text mail ASCII/Latin 1input into body is disabled when the plain text option is on → [Regression] Plain text mail ASCII/Latin 1input into body is disabled when the plain text option is on
This is occuring in today's builds (7/1) on all platforms.
I'll mark this critical.  Kat, if this is blocking you, pls change to severity
of blocker.

People will run into this because the default right now is for plain text
compose window.
Severity: critical → blocker
I'm moving this to a blocker because the regression disables some input method
functionality.  I need IME functionality working in M8.
Status: NEW → ASSIGNED
Target Milestone: M8
I don't have currently a build working. Can somebody test with the editor in plain text mode to see if you can

reproduce the problem. If yes, please reassign this bug to editor folk.
Momoi-san and I already looked at this with the plain text and html editors.
The ender components function correctly and don't show this regression.
Added jpatel and fenella to the CC line.
ok, I can reproduce the problem now on my PC, I have added sfraser to the cc
list.
Assignee: ducarroz → sfraser
Status: ASSIGNED → NEW
Simon, please could you take a look at it. For me everything seems to be
correctly initialized, nsEditorShell::InstantiateEditor is called and return no
error.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
This is a dup of 9153, which broke plain text ender everywhere.


*** This bug has been marked as a duplicate of 9153 ***
I'm not sure this bug is a duplicate of 9153 from reading the bug report.  On
Momoi-san's build the problem wasn't with "Ender everywhere", it was limited to
plain text editing in the mailnews window.  The plain text ender editor worked
fine -- was that also the case for 9153, that isn't clear from the bug report.
Well, I debugged it to the same failure point as bug 9153. That's good enough for
me.
Kat - pls mark verified if you agree with the resolution since you originally
reported this bug.
** Checked with 7/13/99 Win32 build **

I don't know if I should mark this bug a duplicate
of 9153. I just revisited all the problem points I reported
in the original report. With (compose_html, false) setting,
I was not able to reproduce any of the original problems.

Under the plain text mail, ASCII/Latin input is working. Delete
is working. Japanese input/delete is working.
Bug 9153 is still open. So we probably should mark this
bug as Worksforme.
Status: RESOLVED → VERIFIED
Per kat's comments (since he reported this bug), I'll marked verified as
duplicate.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.