Open Bug 206219 Opened 22 years ago Updated 2 years ago

Background color for HTML messages is forced

Categories

(MailNews Core :: Composition, enhancement)

Product:
MailNews Core
Component:
Composition
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: rameshkumarp, Unassigned)

References

Details

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030507 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030507 In mozilla1.4 Beta, there is option to set the background color for HTML messages. I want to have HTML message. But I dont want to set any color in the HTML page, so that receiver can read the mail according to their background color setting. You can say that use the option "Use my chosen colors ...." in Appearance -> Colors. But it is not so convenient. Kindly let me know is there any way to disable the background color setting in HTML messages. Reproducible: Always Steps to Reproduce: 1. 2. 3.
The same problem exists in version Mozilla 1.4 [Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624]. The problem with using "Use my chosen colors ...." in Appearance -> Colors is that it applies only to RECEIVING information, not composing or transmitting it. The default setting in Mozilla 1.3 was to have the background be TRANSPARENT, i.e. unselected, which would cause the (as the originator says) receiver can read the mail according to their background color setting. THis bug existed in an earlier (pre 1.0) version of Mozilla, but was corrected.
If you set the preference msgcompose.background_color to a null string, then you will get the results you expect. For the default text color, you can also set msgcompose.text_color to null. (Use about:config in the browser address bar to set these preferences.) The outgoing message will still put 'color' and 'bgcolor' attributes on the <body> tag, but these will be empty strings. It would be nice if a UI could be provided for this, and even better if it would leave the attributes off for the default/transparent case.
Severity: major → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
Summary: Background color for HTML messages → Background color for HTML messages is forced
Another mechanism for achieving the goals of this bug: After opening the HTML Compose window, select Format | Page Colors and Background and choose the radiobutton: (x) Reader's default colors This will entirely turn off coloration for the message -- the 'text' and 'bgcolor' attributes will not be written. However, there is still no way to make this persist.
Product: MailNews → Core
*** Bug 255106 has been marked as a duplicate of this bug. ***
> options > display > formatting > HTML message > background color update with V1.0+ [1.8b3: 2005071208 - windows] Seems to behave exactly the opposite: background color will not be used by HTML message, but by plain-text. Is reformatting text already formatted useful ? Is this setting necessary ? May be more useful for plain-text as it is now, except that the title "HTML message" is wrong or confusing. 1. this is a bug 2. this feature should likely be reviewed Also to be clarified if this setting is supposed to supersede following lines of user. js: // Previewpane Background color user_pref("browser.display.background_color", "#XXYYZZ");
(In reply to comment #5) > > options > display > formatting > HTML message > background color That feature is for message display. This bug is about message composition. See bug 283268, and please refrain from commenting there or in any other bugs until you have read and understood the bug.
I did not check what exactly happens with Gecko/2003.05.07. With [1.8b3: 2005071208 - windows], you are right, what I describe is likely closer to Bug 283268 although I don't agree with the comments. My comment #5 is still relevant about this bug/feature. I just tried to avoid re-opening an old bug already identified, but which still needs clarification about what this feature is supposed to do.
*** Bug 358161 has been marked as a duplicate of this bug. ***
> *** Bug 358161 has been marked as a duplicate of this bug. *** Possibly this bug covers most of the concepts of my bug. But age is not the only metric for deciding which bug is a duplicate of which. Oftentimes the later bug is better and it's better to mark the earlier bug as a duplicate of the later one. I'm not particularly enthralled by the prospect that this bug is assigned to {<sspitzer@mozilla.org> (not reading, please use sspitzer@mozilla.com instead)}. It feels as though this bug is one of those ones that will have been consigned to the scrapheap of bugs which aren't interesting enough to get fixed, whereas a nice, new, fresh, nicely worded bug might stand a better chance of getting some attention.
> If you set the preference msgcompose.background_color to a null > string, then you will get the results you expect. For the default > text color, you can also set msgcompose.text_color to null. > (Use about:config in the browser address bar to set these > preferences.) > The outgoing message will still put 'color' and 'bgcolor' > attributes on the <body> tag, but these will be empty strings. I am using Thunderbird. I cannot browse to about:config because Thunderbird is not a web browser. However I can set these preferences manually in "prefs.js". This still leaves the unwanted empty attributes in the BODY tag. But I found a way to get rid of those on a persistent basis. I have a file C:\Program Files\Mozilla Thunderbird\defaults\pref\mailnews.js If I go in there and comment out the lines which read: pref("msgcompose.text_color", "#000000"); pref("msgcompose.background_color", "#FFFFFF"); using '//', i.e. to give // pref("msgcompose.text_color", "#000000"); // pref("msgcompose.background_color", "#FFFFFF"); Then those preference values don't exist at all in the preferences system, and the BODY tag is emitted as: <body> with no attributes at all, which is exactly what I want. The preference values in mailnews.js appear to be the program-default settings for this thing, i.e. across all users on the system. If this were changed in the master source repository, it would fix the bad-default issue straight off. Also it seems that, unless this is done, there is no way to configure "no attributes" in the "user" "prefs.js", because it would entail completely *deleting* the two preference values which are normally defined in mailnews.js, and I don't think prefs.js supports outright deleting of preference values. However, if they are removed from mailnews.js, this then means that both scenarios selectable in the message compose window would then be persistently configurable via prefs.js. If the preference values are removed from mailnews.js, then we can do: scenario 1: persistent user-setting of "no BODY attributes" => do not mention the two preference values in prefs.js scenario 2: persistent user-setting of "some BODY attributes" => do mention the two preference values in prefs.js At the minute, scenario 1 isn't possible because once the preference values are defined in mailnews.js, it seems they can't be deleted in prefs.js; they can only be set to empty strings, which don't get the baby bathed (they only make the BODY attributes go to empty strings rather than making them be not emitted at all) ("no BODY attributes" is currently available on a non-persistent basis by going through the per-message setting via the GUI.)
(In reply to comment #9) > But age is not the only metric for deciding which bug is a duplicate of > which. Oftentimes the later bug is better and it's better to mark the > earlier bug as a duplicate of the later one. If you care to start volunteering to do work in Bugzilla, or better to start coding for the project, that would be great. Otherwise, just imagine how little I'm interested in your peanut-gallery comments. > I'm not particularly enthralled by the prospect that this bug is assigned to > {<sspitzer@mozilla.org> (not reading, please use sspitzer@mozilla.com > instead)}. OK, I'll take care of that right now. You won't like the result any better. (In reply to comment #10) > I am using Thunderbird. I cannot browse to about:config because Thunderbird > is not a web browser. Tools | Options | Advanced | General Config Editor > But I found a way to get rid of those on a persistent basis. > > I have a file > > C:\Program Files\Mozilla Thunderbird\defaults\pref\mailnews.js > > If I go in there and comment out the lines which read: > > pref("msgcompose.text_color", "#000000"); > pref("msgcompose.background_color", "#FFFFFF"); > > using '//', i.e. to give > > // pref("msgcompose.text_color", "#000000"); > // pref("msgcompose.background_color", "#FFFFFF"); > > Then those preference values don't exist at all in the preferences system, > and the BODY tag is emitted as: > > <body> > > with no attributes at all, which is exactly what I want. That is useful information. Do any errors appear in the error console when you open a new message after setting the prefs up like this? What happens if you go to Options | Composition | HTML options -- how do the buttons appear? Does *this* cause any errors on the console? Do the prefs remain unset after you click OK?
Assignee: sspitzer → nobody
QA Contact: esther → composition
Thank-you for coming back so quickly. > OK, I'll take care of that right now. You won't like the result any better. :-) On one level yes, but on the bright side it is now clear that this bug is not assigned to anyone, which I didn't understand before. > That is useful information. Ta. > Do any errors appear in the error console when you open a new message > after setting the prefs up like this? Not familiar with using the error console under Thunderbird. I opened up the 'JavaScript console' and that did not show any errors on opening a new compose window. > What happens if you go to Options | Composition | HTML options -- how do the > buttons appear? With the values commented-out in mailnews.js, the text and background buttons appear grey, i.e. the same colour as the dialog background, in a way which is actually fairly logical considering the colour options are, at that point, 'undefined'. > Does *this* cause any errors on the console? Yes. Four errors each time the dialog comes up, all the same: Error: Expected color but found 'null'. Error in parsing value for property 'background-color'. Declaration dropped. Source File: chrome://messenger/content/preferences/htmlcompose.xul Line: 0 Interestingly there's no error for the text colour; only the background colour. > Do the prefs remain unset after you click OK? Yes. If I click OK and go back into the dialog, then I still get two grey buttons. And if I check my user prefs.js, it has indeed not created any preference values for text and background colours.
> Error: Expected color but found 'null'. Error in parsing value for > property 'background-color'. Declaration dropped. > Source File: chrome://messenger/content/preferences/htmlcompose.xul > Line: 0 Hmmm. It seems I can even go and look at the file htmlcompose.xul right on my system even just with a run-time install. Amusing.
(In reply to comment #12) > Not familiar with using the error console under Thunderbird. I opened up the > 'JavaScript console' and that did not show any errors on opening a new compose > window. In 2.0, "JavaScript Console" is renamed to "Error Console." (In reply to comment #13) > Hmmm. It seems I can even go and look at the file htmlcompose.xul right on my > system even just with a run-time install. Many source files (.JS, .XUL, .CSS, etc.) are stored in the .jar files (which are basically ZIPs) and interpreted at runtime. You can click the error location in the console and it will open a source-browser window.
I checked to see if this issue still exists on the latest development code, and it still does as of the latest-trunk nightly as of 2006-10-27. It seems that the condition of the preference values not being present and this making no BODY attributes be set for bgcolor and text is a back-stop/marginal case and not really a 'proper' condition that Thunderbird expects to be seeing. Also, we can't rely on preference values being absent because some people might want to create a custom site-specific version of Thunderbird which defaults to including BODY attributes, with them being able to be persistently configured away on a per-user basis. I don't thing preference values can be 'deleted' from the in-memory set by a per-user configuration, and even if they could it would be confusing for most people to follow. So, we are going to need at least one additional preference value. Something like 'msgcompose.set_body_colors' which would be a boolean value. If true it would mean that parameters 'bgcolour' and 'text' would be added to the BODY element in the newly-created in-memory message object for a new compose, and would be initialised with the values of msgcompose.background_colour and msgcompose.text_colour respectively. If false it would mean that no parameters would be added. If the preference value 'msgcompose.set_body_colors' did not exist, then it would be treated as if it were false. This would then mean that people upgrading from older versions with this new support would get the 'right' behaviour, viz. not setting any BODY colours. I am fairly sure I've seen the bit of JavaScript where the above change would need to be made. We then need additional UI elements in the persistent configuration to be able to control this. In fact the persistent configuration would likely mirror the per-message Format:{Page Colors and Background...} UI. Theoretically the existing persistent background/text controls could be extended to include a the link, active link and visited link colours. But my interest is on making the bgcolor and text attributes be not specified for BODY, so I won't pursue persistent link colours myself. So the persistent configuration would need to gain a radio button with options like: * Don't set colors * Use custom colours The existing colour choosers for background and text would appear under the 'Use custom colours radio button. Then the radio buttons would set the value 'false' or 'true' respectively on the preference value 'msgcompose.set_body_colors'. It looks like we can do all of this in the XUL and JavaScript space. I am wondering if it would even be possible to do a test implementation just by making changes to a run-time installation, i.e. without even getting a source set.
> So, we are going to need at least one additional preference value. Come to think of it, maybe not. All we need to do is to define that empty strings in msgcompose.background_colour and msgcompose.text_colour are to be interpreted as "do not add the corresponding attribute to the BODY element for the newly-created in-memory message object for a new Compose". This will still do the (in my view) 'right' thing for users upgrading from older software. Users who have never messed with the HTML colour defaults will not have per-user preference values for msgcompose.background_colour and msgcompose.text_colour, so they will end up using the program defaults which would be the empty strings, which would mean no colour attributes on BODY. > We then need additional UI elements in the persistent configuration > ... > So the persistent configuration would need to gain a radio button Maybe not. The current colour picker brings up a pop-up-menu style colour picker, with no available option for "no color" (which is what we want). I had a sniff around and found another colour picker in "Table Properties". In table properties you have a little button for the background colour. When you press it you get a whole new dialog with a colour picker in it. You can then choose either a colour, or "default". There is also a text field which shows the text value for the colour (e.g. #ff0000), which goes empty if you click "default". Which is exactly the kind of thing we want. As an added bonus, as well as being able to select "no colour", we also get the ability to set any 24-bit colour directly from the main UI (without the user having to hack on prefs.js).
> The current colour picker brings up a pop-up-menu style colour picker, with no > available option for "no color" (which is what we want). Sorry, this should be: > The current color picker brings up a pop-up-menu style color picker, with no > available option for "no color" (which is no good because we need an option > for "no color").
(In reply to comment #15) > So the persistent configuration would need to gain a radio button with options > like: > > * Don't set colors > * Use custom colours Like the ones seen in the compose window's Format | Page Background and Colors dialog? If you work on coding this, make sure that dialog properly reflects the current setting.
If you think allowing 'no color' specs for the preferences is the way to go, make sure that that dialog behaves correctly once you've set that up.
> Like the ones seen in the compose window's Format | Page Background and Colors > dialog? If you work on coding this, make sure that dialog properly reflects > the current setting. Actually with the first scheme, for users that had messed with the persistent BODY colours, on upgrade, it would lose their configuration and re-set it to "no colors". With the later scheme I proposed (using empty strings), it would be better because: * for users that had never touched that preference, they would not have any preference values in the per-user prefs.js and would take on the new software's defaults, i.e. "no colors", * for users that *had* touched that preference, their preference would be preserved on upgrade.
> If you think allowing 'no color' specs for the preferences is the way to go, > make sure that that dialog behaves correctly once you've set that up. I am also a firm believer in programmer testing :-) Now you've made me aware of the error console, I would of course incorporate a check to make sure that was clean as well. If I were able to construct a sort of patch containing the relevant changes, would anyone be prepared to try it out? What version of Thunderbird should I use as the basis of any proposed modification? Could be 1.5.0.7, 2.0a1, or a nightly I suppose.
(In reply to comment #21) > If I were able to construct a sort of patch containing the relevant changes, > would anyone be prepared to try it out? The way to do this is to submit the patch with a request for review from one of the mail guys > What version of Thunderbird should I use as the basis of any proposed > modification? Could be 1.5.0.7, 2.0a1, or a nightly I suppose. Ideally, you'd pull the CVS from the trunk, or else the 1.8.1 branch (which is the basis for TB 2.0). As we're coming in fast at 2.0, you might not get the patch done in time, so the trunk would be better. And the patch you submit, ideally, would be generated via CVS diff.
Product: Core → MailNews Core
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.