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)
SeaMonkey
MailNews: Message Display
Tracking
(Not tracked)
NEW
People
(Reporter: akkzilla, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file, 1 obsolete file)
(deleted),
image/gif
|
Details |
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.)
Comment 1•25 years ago
|
||
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
Comment 2•25 years ago
|
||
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
Reporter | ||
Comment 3•25 years ago
|
||
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).
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M16
Comment 5•25 years ago
|
||
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
Comment 6•25 years ago
|
||
Since this bug is marked P4, moving to M17. If you disagree, please let me know.
Target Milestone: M16 → M17
Updated•24 years ago
|
Assignee: alecf → putterman
Status: ASSIGNED → NEW
Comment 8•24 years ago
|
||
give to putterman
Comment 9•24 years ago
|
||
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Comment 10•24 years ago
|
||
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)
Comment 11•24 years ago
|
||
taking from putterman.
Assignee: putterman → sspitzer
Status: REOPENED → NEW
Comment 12•24 years ago
|
||
> 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.
Comment 13•23 years ago
|
||
*** Bug 107885 has been marked as a duplicate of this bug. ***
Comment 14•22 years ago
|
||
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.
Comment 16•22 years ago
|
||
Jennifer, any UI ideas for this?
Comment 17•22 years ago
|
||
I take it we want a separate ui in mail Prefs to display these settings? I'll
take a look.
Comment 18•22 years ago
|
||
See HTML Messages group box. Is this what we want? Let me know nec changes.
Comment 20•22 years ago
|
||
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
Comment 21•22 years ago
|
||
jglick: nevermind. I just saw the "Languages" pref panel section in your image :)
Comment 22•22 years ago
|
||
Comment 23•22 years ago
|
||
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.
Comment 24•22 years ago
|
||
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
Comment 25•22 years ago
|
||
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.
Comment 26•22 years ago
|
||
+nsPresContext::IsMailnewsContext()
This leaves a nasty taste in my mouth.
OS: Linux → All
Hardware: PC → All
Comment 27•22 years ago
|
||
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 28•22 years ago
|
||
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+
Comment 29•22 years ago
|
||
*** Bug 180351 has been marked as a duplicate of this bug. ***
Comment 31•22 years ago
|
||
per seth, I'm going to mark target milestone as future
Target Milestone: --- → Future
Updated•22 years ago
|
Summary: no UI for "Use my default fonts" pref for mail → no UI for "Use my default fonts" pref for mail / message display
Comment 32•21 years ago
|
||
Didn't the bug 30888 fix make this functionally obsolete?
Comment 33•20 years ago
|
||
*** Bug 263018 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Product: Browser → Seamonkey
Updated•20 years ago
|
Assignee: sspitzer → mail
Comment 34•17 years ago
|
||
Please look at Bug 351982 which I think best captures the problem with this and bug Bug 178362.
Updated•16 years ago
|
Priority: P4 → --
QA Contact: esther → search
Target Milestone: Future → ---
Updated•15 years ago
|
Assignee: mail → nobody
QA Contact: search → message-display
You need to log in
before you can comment on or make changes to this bug.
Description
•