Closed Bug 109209 Opened 24 years ago Closed 24 years ago

PlainText Cached Composition Window Displays Strange Look Font In Message

Categories

(MailNews Core :: Composition, defect, P2)

Product:
MailNews Core
Component:
Composition
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.8

People

(Reporter: jay, Assigned: bugzilla)

References

Details

(Keywords: regression, Whiteboard: have fix)

Attachments

(1 file, 1 obsolete file)

Proposed fix, v2.
2.47 KB, patch
dmosedale
: review+
Bienvenu
: superreview+
Details | Diff | Splinter Review
Win98SE 200110803 Add the following to the prefs.js or user.js file: user_pref("mail.compose.max_recycled_windows", 1); This will enable the cached composition window. 1 Start a new composition window and close it. 2 Start a new composition window, this one is from cache. 3 Type anything in the message body. Font looks like a strange rendition of Times New Roman but a little compressed and also appears as if you're in HTML compose mode. The appearance of the sent message looks normal as if the cached window preference was not enabled. Removing the preference returns all back to normal.
Just noticed that this seems to happen ONLY in the Modern Theme, classic unaffected.
compose -> ducarroz
Assignee: sspitzer → ducarroz
Component: Mail Window Front End → Composition
also see this on linux rh7.2. i have message compose set to plaintext, and using the modern theme. i encounter this when i open a new compose window [click Get Msgs button or ctrl+M]. sheelar/esther, d'you see this on mac 9.x or OS X?
Keywords: mozilla0.9.7, nsbeta1, regression, ui
OS: Windows 98 → All
QA Contact: esther → sheelar
Hardware: PC → All
I have never been able to reproduce this problem myself. Sarah, can I come to see you tomorrow?
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.8
*** Bug 115987 has been marked as a duplicate of this bug. ***
Ok, I can reproduce it under MacOS X using the following step: 1) be sure you have the pref "mail.compose.max_recycled_windows" set to 1 or greater 2) start Mozilla 3) Open a plain text compose window 4) Close the compose window 5) Open again a plain text compose window 6) type into the message body ==> wrong font! I wonder if I clear the node that specify the font when clearinf the body of the recycled window!
wacky, i cannot seem to get this to occur on winNT [2001.12.17 bits], so far...
QA Contact: sheelar → esther
Here is the content of a brand new plain text window: <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><title></title></head><body style="font-family: -moz-fixed; white-space: -moz-pre-wrap; width: 72ch;"><br> </body></html> and here is the content of a recycled plain text compose window: <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"> <title></title></head><body style="white-space: -moz-pre-wrap; width: 72ch;"><br> </body></html> For some reason, we lose the "font-family: -moz-fixed;"!
Summary: Cached Composition Window Displays Strange Look Font In Message → PlainText Cached Composition Window Displays Strange Look Font In Message
Keywords: nsbeta1 → nsbeta1+
Priority: -- → P2
The font get changed when we set the wrap column. This because the editor internal flags got changed when we disable/enable the editor. Patch coming...
Attached patch Proposed fix, v1 (obsolete) — — Splinter Review
Whiteboard: have fix
Comment on attachment 64209 [details] [diff] [review] Proposed fix, v1 >- editorShell.editor.SetFlags(nsIPlaintextEditor.eEditorReadonlyMask); >+ var flags = new Object; >+ editorShell.editor.GetFlags(flags); >+ editorShell.editor.SetFlags(flags.value | nsIPlaintextEditor.eEditorReadonlyMask); Is it really necessary to deal with the XPCOM setter and getter manually? IE could these three lines be replaced by: editorShell.editor.flags |= nsIPlaintextEditor.eEditorReadonlyMask; > var disableElements = document.getElementsByAttribute("disableonsend", "true"); > for (i=0;i<disableElements.length;i++) >@@ -153,5 +155,8 @@ > function enableEditableFields() > { >- editorShell.editor.SetFlags(nsIPlaintextEditor.eEditorMailMask); >+ var flags = new Object; >+ editorShell.editor.GetFlags(flags); >+ if (flags.value & nsIPlaintextEditor.eEditorReadonlyMask) >+ editorShell.editor.SetFlags(flags.value - nsIPlaintextEditor.eEditorReadonlyMask); Similarly, how about using the javascript xor assignment operator here with the same pattern: editorShell.editor.flags ^= nsIPlaintextEditor.eEditorReadonlyMask; > var enableElements = document.getElementsByAttribute("disableonsend", "true"); > for (i=0;i<enableElements.length;i++) >@@ -184,8 +189,7 @@ > > onReopen: function(params) { >- dump("This is a recycled compose window!\n"); > InitializeGlobalVariables(); >- enableEditableFields(); > window.editorShell.contentWindow.focus(); >+ enableEditableFields(); > ComposeStartup(true, params); > } >@@ -1141,4 +1145,7 @@ > var args = null; // old way, parameters are passed as a string > >+ if (recycled) >+ dump("This is a recycled compose window!\n"); >+ How about removing the above if/dump statement; for 99% of the people who use this, it's just clutter, and it makes seeing important console messages harder. r=dmose@netscape.com, with those changes. However, I know essentially nothing about the editor and editorShell, so you might wanna get someone who has experience with those to review it also.
Attachment #64209 - Flags: review+
>Is it really necessary to deal with the XPCOM setter and getter manually? nsIEditor does not define flags as an attribute but provide only GetFlags and SetFlags. >Similarly, how about using the javascript xor assignment operator here... I tried using x & ~y but as we use a js variable, it wasn't considered as unsigned and therfore wasn't working. Let me try x ^ y... >How about removing the above if/dump statement I already had this discusion a while ago. We are keeping it until we turn the recycled pref on by default. This dump is the only good way to be sure the user is using a recycled windoe or not.
The only change in the second patch is the use of an bitwise exclusive or to clear the eEditorReadonlyMask bit.
Attachment #64209 - Attachment is obsolete: true
Comment on attachment 64216 [details] [diff] [review] Proposed fix, v2. sr=bienvenu
Attachment #64216 - Flags: superreview+
Fix checked in
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
*** Bug 121313 has been marked as a duplicate of this bug. ***
Using build 20020322 on winxp and 20020318 on mac os9.1 and linux this is fixed. Verified.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: