Open Bug 30896 Opened 25 years ago Updated 15 years ago

no UI for "Use my default fonts" pref for mail / message display

Categories

(SeaMonkey :: MailNews: Message Display, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

People

(Reporter: akkzilla, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 1 obsolete file)

The fonts pref panel has a pref for "Use my default fonts even if the document specifies otherwise". I don't set that in the browser, because it isn't a problem that often and I want to see most html pages the way they're formatted, but in mail, all I care about is reading the text, and I would love to be able to set this pref for mail only in order to read messages from OE users who set their fonts too small. We have other prefs like "disable JS" that can be set separately for mail and browser; any chance we could add "use default fonts" to the list? (It would also be neat to be able to turn off showing colors and backgrounds, but that's probably harder and not as critical.)
not sure how this stuff works, adding rich to the CC adding Jennifer so maybe she can design a UI around this. It seems like a good idea to me
Actually, to change the mail display prefs, see the follow: user_pref("font.name.monospace.x-unicode", "Font_Name"); --> plain text mail body user_pref("font.name.serif.x-unicode", "Font_Name"); --> HTML mail body user_pref("font.size.fixed.x-unicode", 12); --> sizes in pixels user_pref("font.size.variable.x-unicode", 16); --> sizes in pixels
Rich, are you saying that setting these fonts will override tags like <font face=""> in the message? I assumed that the font prefs you mention only applied to mail that does not specify a font face or size (I'm fairly sure that was how 4.x worked). If true, then this bug is invalid, because it's already the case anyway (though someone might want the opposite bug, requesting a way to see the message's specified fonts).
Status: NEW → ASSIGNED
Target Milestone: M16
P4 per m/n staff mtg today
Priority: P3 → P4
wondering if this should go to RHP or putterman. Not sure if this is a "feature" bug per say. taking off [FEATURE] list for now.
Summary: [FEATURE] "Use my default fonts" pref for mail → "Use my default fonts" pref for mail
Since this bug is marked P4, moving to M17. If you disagree, please let me know.
Target Milestone: M16 → M17
Not critical for this release. M20.
Target Milestone: M17 → M20
Assignee: alecf → putterman
Status: ASSIGNED → NEW
give to putterman
I fixed this months ago with bug 18427. *** This bug has been marked as a duplicate of 18427 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
where is the UI for this? re-opening
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Summary: "Use my default fonts" pref for mail → no UI for "Use my default fonts" pref for mail (but you can hack your userChrome.css)
taking from putterman.
Assignee: putterman → sspitzer
Status: REOPENED → NEW
> where is the UI for this? nowhere, but the reporter didn't ask for it :). I'd like to have UI as well, shouldn't be hard. Ask me for some hints, when you are about to implement it. > (It would also be neat to be able to turn off showing colors and backgrounds, > but that's probably harder and not as critical.) BTW: That works, too.
*** Bug 107885 has been marked as a duplicate of this bug. ***
ssu is going to take this bug. here's where he'll start: start by figuring out where the browser fonts affect browser and mail. nsPresContext::GetFontPreferences() looks very likely if that's correct, see if there is a way to distinguish between a browser presentation context and our message pane presentation context. my guess is there will be (some how, might require some investigation) we can tweak that code so that we ask for the mail prefs when it's a mail presentation context. if that works out, we would then make sure that the pref observer code (the code that gets notified when the font pref values change) does the right thing in mail when the mail fonts change. then we need to find a way to share the pref font UI (pref-fonts.xul and pref-fonts.js) between both mail and browser. we should be able to re-use and share it.
mine now.
Assignee: sspitzer → ssu
Jennifer, any UI ideas for this?
I take it we want a separate ui in mail Prefs to display these settings? I'll take a look.
Attached image Example (deleted) —
See HTML Messages group box. Is this what we want? Let me know nec changes.
Would be a nice candidate for bug 31907.
Blocks: 31907
jglick, the current mailnews Message Display pref page has a "Languages" section. Where should that be moved to in order to fit the new "HTML Messagees" section?
Status: NEW → ASSIGNED
jglick: nevermind. I just saw the "Languages" pref panel section in your image :)
Attached patch patch v0.1 (obsolete) (deleted) — Splinter Review
This patch is no where near done, but it provides clues to where changes might take place. It can already detect if the browser element is in the mailnews context or not. I'm still working on figuring out where to do the checks for if the browser is in the mailnews context.
the plan is to do this with prefs, not userChrome.css (see ssu's start of a patch) qa -> laurel (or stephend). no more rhp.
QA Contact: lchiang → laurel
Summary: no UI for "Use my default fonts" pref for mail (but you can hack your userChrome.css) → no UI for "Use my default fonts" pref for mail
Currently, the code in nsPresContext does this: 1) in ::Init() register pref callbacks for "font." 2) in ::Init() call GetUserPreferences() [which calls GetFontPreferences()] 3) in ::~nsPresContext(), unregister the pref callback for "font." Here's what ssu is proposing to do: 1) move the pref callback registration to ::SetShell() 2) in ::SetShell(), determine if the browser element has a fontprefix attribute(*), if so, store the fontprefix in a nsCString member variable mFontPrefix 3) in ::SetShell(), register a pref callback for mFontPrefix + "." + "font."(if mFontPrefix is not empty, otherwise just "font.") 4) in ::SetShell(), call GetUserPreferences(), heeding the mFontPrefix member variable. 5) in ::~nsPresContext(), unregister the pref callback for mFontPrefix + "." + "font."(if mFontPrefix is not empty, otherwise just "font.") Here's a code snippet of how ssu plan's on determining the font prefix: + if (mShell) { + nsCOMPtr<nsIDocument> doc, parentDoc; + mShell->GetDocument(getter_AddRefs(doc)); + doc->GetParentDocument(getter_AddRefs(parentDoc)); + if (parentDoc) { + // get content for <browser> + nsCOMPtr<nsIContent> browserElContent; + parentDoc->FindContentForSubDocument(doc, getter_AddRefs(browserElContent)); + nsCOMPtr<nsIDOMElement> browserElement = do_QueryInterface(browserElContent); + + if (browserElement) { + browserElement->GetAttribute(NS_LITERAL_STRING("fontprefix"), mFontPrefix); layout should not have any hard coded knowledge of mail.
+nsPresContext::IsMailnewsContext() This leaves a nasty taste in my mouth.
OS: Linux → All
Hardware: PC → All
The part that sfraser objects to is going away. I didn't cc sfraser on my private mail, so let me post it here for comments: Just like the user can set default font prefs for the browser, we want to allow the user to be able to set default prefs for message display. But we don't want layout to have any hard coded knowledge of mail. Currently, the code in nsPresContext does this: 1) in ::Init() register pref callbacks for "font." 2) in ::Init() call GetUserPreferences() [which calls GetFontPreferences()] 3) in ::~nsPresContext(), unregister the pref callback for "font." Here's what ssu is proposing to do: 1) move the pref callback registration to ::SetShell() 2) in ::SetShell(), determine if the browser element has a fontprefix attribute(*), if so, store the fontprefix in a nsCString member variable mFontPrefix 3) in ::SetShell(), register a pref callback for mFontPrefix + "." + "font."(if mFontPrefix is not empty, otherwise just "font.") 4) in ::SetShell(), call GetUserPreferences(), heeding the mFontPrefix member variable. 5) in ::~nsPresContext(), unregister the pref callback for mFontPrefix + "." + "font."(if mFontPrefix is not empty, otherwise just "font.") Does this sound reasonable? Here's a code snippet of how ssu plans to determine the font prefix: + if (mShell) { + nsCOMPtr<nsIDocument> doc, parentDoc; + mShell->GetDocument(getter_AddRefs(doc)); + doc->GetParentDocument(getter_AddRefs(parentDoc)); + if (parentDoc) { + // get content for <browser> + nsCOMPtr<nsIContent> browserElContent; + parentDoc->FindContentForSubDocument(doc, getter_AddRefs(browserElContent)); + nsCOMPtr<nsIDOMElement> browserElement = do_QueryInterface(browserElContent); + + if (browserElement) { + browserElement->GetAttribute(NS_LITERAL_STRING("fontprefix"), mFontPrefix);
Comment on attachment 101470 [details] [diff] [review] patch v0.1 marking as obsolete / needs work, to make sure people know this isn't what we plan to check in.
Attachment #101470 - Attachment is obsolete: true
Attachment #101470 - Flags: needs-work+
*** Bug 180351 has been marked as a duplicate of this bug. ***
taking
Assignee: ssu → sspitzer
Status: ASSIGNED → NEW
per seth, I'm going to mark target milestone as future
Target Milestone: --- → Future
Summary: no UI for "Use my default fonts" pref for mail → no UI for "Use my default fonts" pref for mail / message display
QA Contact: laurel → esther
Didn't the bug 30888 fix make this functionally obsolete?
*** Bug 263018 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
Assignee: sspitzer → mail
Please look at Bug 351982 which I think best captures the problem with this and bug Bug 178362.
Priority: P4 → --
QA Contact: esther → search
Target Milestone: Future → ---
Assignee: mail → nobody
QA Contact: search → message-display
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: