Closed
Bug 60881
Opened 24 years ago
Closed 13 years ago
Show sender's picon in message header panel. (x-face)
Categories
(SeaMonkey :: MailNews: Message Display, enhancement)
SeaMonkey
MailNews: Message Display
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: brane, Unassigned)
References
(Depends on 1 open bug)
Details
Attachments
(3 files)
6.70 KB,
patch
|
Details | Diff | Splinter Review | |
8.42 KB,
patch
|
Details | Diff | Splinter Review | |
7.84 KB,
patch
|
Details | Diff | Splinter Review |
I'd very much like to have a feature I saw in Exmh: it looks up the sender's mail address in the picons database at http://www.cs.indiana.edu/picons/ and displays the picon alongside the mail header. Ah ... before somebody accuses me of expecting other people to do the work ... I'm attaching a patch that does this, and adds appropriate bits to the MailNews preferences to toggle this feature. diff -ru bin/chrome/en-US/locale/en-US/messenger/pref-viewing_messages.dtd Seamonkey/chrome/en-US/locale/en-US/messenger/pref-viewing_messages.dtd --- bin/chrome/en-US/locale/en-US/messenger/pref-viewing_messages.dtd Wed Sep 13 23:17:18 2000 +++ Seamonkey/chrome/en-US/locale/en-US/messenger/pref-viewing_messages.dtd Tue Nov 21 01:00:56 2000 @@ -43,7 +43,7 @@ <!ENTITY sendDefaultCharset.label "Character Coding:"> <!ENTITY sendDefaultCharset.accesskey "h"> <!ENTITY forceCharsetOverride.label "Apply default to all messages (ignore character coding specified by MIME header)"> -<!ENTITY forceCharsetOverride.accesskey "p"> +<!ENTITY forceCharsetOverride.accesskey "o"> <!ENTITY fixedWidth.label "Fixed width font"> <!ENTITY fixedWidth.accesskey "f"> <!ENTITY variableWidth.label "Variable width font"> @@ -57,8 +57,9 @@ <!ENTITY convertEmoticons.accesskey "d"> <!ENTITY example1.label "For example, display ' [:-)] ' as"> <!ENTITY example2.label "."> - +<!ENTITY displayPicons.label "Show sender's picon in message header."> +<!ENTITY displayPicons.acceskey "p"> + <!-- Tooltips --> -<!ENTITY convertEmoticons.tooltip "Convert Emoticons"> - - +<!ENTITY convertEmoticons.tooltip "Convert Emoticons"> +<!ENTITY displayPicons.tooltip "Show Picons"> diff -ru bin/chrome/messenger/content/messenger/msgHdrViewOverlay.js Seamonkey/chrome/messenger/content/messenger/msgHdrViewOverlay.js --- bin/chrome/messenger/content/messenger/msgHdrViewOverlay.js Tue Oct 17 11:03:54 2000 +++ Seamonkey/chrome/messenger/content/messenger/msgHdrViewOverlay.js Tue Nov 21 01:02:18 2000 @@ -45,6 +45,10 @@ var gNumAddressesToShow = 3; var gShowUserAgent = false; +// Picons +var piconsSearchURL = "http://www.cs.indiana.edu:800/piconsearch/"; +var piconsSearchSuffix = "/users+usenix+misc+domains+unknown/up/single/gif/order"; + // attachments array var attachmentUrlArray = new Array(); var attachmentDisplayNameArray = new Array(); @@ -90,6 +94,10 @@ msgPaneData.DateBox = document.getElementById("DateBox"); msgPaneData.DateValue = document.getElementById("DateValue"); + // Box with sender's picon + msgPaneData.PiconBox = document.getElementById("PiconBox"); + msgPaneData.PiconImage = document.getElementById("PiconImage"); + // Attachment related elements msgPaneData.AttachmentPopup = document.getElementById("attachmentPopup"); msgPaneData.AttachmentButton = document.getElementById("attachmentButton"); @@ -169,7 +177,11 @@ msgPaneData.CcValueToggleIcon.setAttribute('collapsed', 'true'); //hdrViewSetVisible(msgPaneData.ToValueToggleIcon, false); //hdrViewSetVisible(msgPaneData.CcValueToggleIcon, false); - + + // Hide the picons box, too. + msgPaneData.PiconBox.setAttribute('collapsed', 'true'); + msgPaneData.PiconImage.removeAttribute('src'); + ShowMessageHeaderPane(); UpdateMessageHeaders(); }, @@ -451,7 +463,9 @@ { var emailAddress = {}; var name = {}; - + var checkPicon = (currentHeaderName == "from" && pref.GetBoolPref("mail.display_picon")); + var foundPicon = false; + while (enumerator.hasMoreElements()) { var headerResult = enumerator.getNext(); @@ -463,6 +477,21 @@ var fullAddress = headerResult.getAddressAndName(addrValue, nameValue); emailAddress = addrValue.value; name = nameValue.value; + + // Compute the URL for the sender's picon + if (checkPicon && !foundPicon) + { + var atSign = emailAddress.indexOf('@'); + if (atSign != -1) + { + var host = emailAddress.substring(atSign + 1) + var user = emailAddress.substring(0, atSign); + msgPaneData.PiconImage.setAttribute('src', piconsSearchURL + host + "/" + user + piconsSearchSuffix); + msgPaneData.PiconBox.removeAttribute('collapsed'); + + foundMailFace = true; + } + } // if we want to include short/long toggle views and we have a long view, always add it. // if we aren't including a short/long view OR if we are and we haven't parsed enough diff -ru bin/chrome/messenger/content/messenger/msgHdrViewOverlay.xul Seamonkey/chrome/messenger/content/messenger/msgHdrViewOverlay.xul --- bin/chrome/messenger/content/messenger/msgHdrViewOverlay.xul Tue Sep 19 16:26:54 2000 +++ Seamonkey/chrome/messenger/content/messenger/msgHdrViewOverlay.xul Tue Nov 21 01:02:29 2000 @@ -69,6 +69,16 @@ </box> </box> + <box id="PiconBox" class="header-part1" orient="horizontal" collapsed="true"> + <spring class="buttonSpacer"/> + <vbox> + <spring flex="1"/> + <image id="PiconImage" style="width: 48px; height: 48px; border: 0px;"/> + <spring flex="1"/> + </vbox> + <spring class="buttonSpacer"/> + </box> + <box id="attachmentBox" class="header-part1" orient="horizontal" collapsed="true"> <spring class="buttonSpacer"/> <vbox> diff -ru bin/chrome/messenger/content/messenger/pref-viewing_messages.xul Seamonkey/chrome/messenger/content/messenger/pref-viewing_messages.xul --- bin/chrome/messenger/content/messenger/pref-viewing_messages.xul Mon Oct 9 21:15:04 2000 +++ Seamonkey/chrome/messenger/content/messenger/pref-viewing_messages.xul Tue Nov 21 01:02:50 2000 @@ -15,7 +15,7 @@ <script language="javascript"> <![CDATA[ - _elementIDs = ["mailFixedWidthMessages", "mailQuotedStyle", "mailQuotedSize", "wrapLongLines", "displayGlyph", "mailCitationColor", "sendDefaultCharsetList", "forceCharsetOverride"]; + _elementIDs = ["mailFixedWidthMessages", "mailQuotedStyle", "mailQuotedSize", "wrapLongLines", "displayPicons", "displayGlyph", "mailCitationColor", "sendDefaultCharsetList", "forceCharsetOverride"]; function Startup() { @@ -96,6 +96,9 @@ <checkbox id="wrapLongLines" value="&wrapInMsg.label;" pref="true" preftype="bool" prefstring="mail.wrap_long_lines" prefattribute="checked"/> + <checkbox id="displayPicons" value="&displayPicons.label;" + pref="true" preftype="bool" prefstring="mail.display_picon" + prefattribute="checked" tooltip="aTooltip" tooltiptext="&displayPicons.tooltip;"/> <checkbox class="iconic" id="displayGlyph" value="&convertEmoticons.label;" pref="true" preftype="bool" prefstring="mail.display_glyph" prefattribute="checked" tooltip="aTooltip" tooltiptext="&convertEmoticons.tooltip;"/>
Comment 1•24 years ago
|
||
reporter, could you please use the "Create a new attachment" link (http://bugzilla.mozilla.org/createattachment.cgi?id=60881) and attach the patch there? That will make it a lot easier to work with... Thanks!
Reporter | ||
Comment 2•24 years ago
|
||
Comment 3•24 years ago
|
||
reassigning to mscott and adding patch keyword.
Assignee: putterman → mscott
Keywords: patch
Brane do you have CVS access?
Comment 5•24 years ago
|
||
Thanks for contributing the patch. A couple comments: 1) I noticed you changed one of our access keys -<!ENTITY forceCharsetOverride.accesskey "p"> +<!ENTITY forceCharsetOverride.accesskey "o"> in order to use "p" as an access key for showing these picons. cc'ing our UE contact so we can go over this potential change to access keys. I haven't looked at everything yet but one thing stuck out at me: <image id="PiconImage" style="width: 48px; height: 48px; border: 0px;"/> By hard coding width, height and border values in the XUL we can make it really hard to make this "skinnable" so other themes can leverage these things. What you want to do is make a new image class in msgHdrViewOverlay.css for your picon. This class can have as attributes a width and height value. Different skins have different values for msgHdrViewOverlay.css since the skin dictates the style. So by pulling these values out into a style sheet you make your picons work much better for various skins.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Reporter | ||
Comment 6•24 years ago
|
||
> I haven't looked at everything yet but one thing stuck out at me:
> <image id="PiconImage" style="width: 48px; height: 48px; border: 0px;"/>
> By hard coding width, height and border values in the XUL we can make it really
> hard to make this "skinnable" so other themes can leverage these things. What
> you want to do is make a new image class in msgHdrViewOverlay.css for your picon.
Well, the fact is that picons are standardized to 48x48 pixels. But on the other
hand it wouldn't be much work to put that in the stylesheet. Will do.
Reporter | ||
Comment 7•24 years ago
|
||
Reporter | ||
Comment 8•24 years ago
|
||
I just attached a new version of this patch. The differences from the previous version are as follows: - The picon image properties are defined in msgHdrViewOverlay.css for each theme now (I added them for classic and modern themes). - I increased the height of the Preferences dialogue from 470 to 520, to accomodate the extra checkbox in the Message Display pane (checked with both themes). I also made sure that the patch applies cleanly to the Mozilla 0.6 sources. I patched my 0.6 installation and regenerated the .jar files, and everything seems to work fine. I think this is it, except for the question about accelerator keys in the prefs dialogue.
Comment 9•24 years ago
|
||
> I increased the height of the Preferences dialogue from 470 to 520
Mozilla should really be able to work nicely on a 640*400 screen ... (The 4.x
prefs dialog could fit in 640*400 with plenty of room to spare.)
Reporter | ||
Comment 10•24 years ago
|
||
> Mozilla should really be able to work nicely on a 640*400 screen ... (The 4.x
> prefs dialog could fit in 640*400 with plenty of room to spare.)
Maybe, but the prefs dialog would have to be redesigned quite a bit.
That's definitely not something I'm competent to do. I only enlarged it
so that all the controls fit in.
Reporter | ||
Comment 11•24 years ago
|
||
Doh. I found a bug in the latest version of my patch. The line foundMailFace = true; should read founcPicon = true;
Reporter | ||
Comment 12•24 years ago
|
||
Comment 13•23 years ago
|
||
Nominating for Mozilla 1.0 saying we have a patch and it's one of these features that may impress users (some people seem to like IE's favicon for bookmarks - this is a similar idea but for email). The main problem that I see if that Mozilla is relying on a server that they have no control over to provide the content. There is always a possibility that this site will go away and this feature will stop working. What we really need is a mozilla.org mirror of these icons so that as long as the mozilla browser is in active development there'll be the motivation to keep the site alive. I also believe we need a way for the user to add their own picon to the database easily, but that'll come as a separate RFE if this one gets implemented. Possibly just a link in a help file taking the user to the page to upload their picon or perhaps even integrated into the account wizard (you may specify an icon to use for this email address, if you'd like to provide an icon...)
Keywords: mozilla1.0
Comment 14•23 years ago
|
||
>The main problem that I see if that Mozilla is relying on a server that they >have no control over to provide the content. There is always a possibility that >this site will go away and this feature will stop working. What we really need >is a mozilla.org mirror of these icons so that as long as the mozilla browser is >in active development there'll be the motivation to keep the site alive. The Windows newsreader Xnews uses these "picons" (called "faces" or "X-Faces"), but they are encoded in the headers of the messages, so no additional server is required. Some people use Xnews *because* they can see other peoples X-Face with it... :-) >I also believe we need a way for the user to add their own picon to the database >easily, but that'll come as a separate RFE if this one gets implemented. >Possibly just a link in a help file taking the user to the page to upload their >picon or perhaps even integrated into the account wizard (you may specify an >icon to use for this email address, if you'd like to provide an icon...) Most Xnews users use the program WinFace to create this "X-Face:" header field. Maybe something similar could be build into Mozilla? Links: Xnews: <http://xnews.3dnews.net/> WinFace: <http://www.geocities.com/quazar_nl/winface/>
Comment 15•22 years ago
|
||
See bug 20417 and bug 83364 for existing X-Face work.
Comment 16•22 years ago
|
||
taking, as I own the x-face bugs. but I'm not sure we'll implement this. http://bugzilla.mozilla.org/show_bug.cgi?id=168236 for a way to make icons show up in the message header area.
Assignee: mscott → sspitzer
Status: ASSIGNED → NEW
Target Milestone: --- → Future
Summary: Show sender's picon in message header panel. → Show sender's picon in message header panel. (x-face)
Comment 17•22 years ago
|
||
Wait...Seth, are you advocating an approach that only works with people who use AIM, over an approach that is common and independent of proprietary systems?
Comment 18•21 years ago
|
||
sorry, i am a bit dummy. How to apply the patch ??
Updated•20 years ago
|
Product: Browser → Seamonkey
Updated•19 years ago
|
Assignee: sspitzer → mail
Updated•16 years ago
|
Assignee: mail → nobody
Priority: P3 → --
QA Contact: esther → message-display
Target Milestone: Future → ---
Comment 19•15 years ago
|
||
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
Comment 20•15 years ago
|
||
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Comment 21•15 years ago
|
||
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Comment 22•15 years ago
|
||
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Comment 23•15 years ago
|
||
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Comment 24•15 years ago
|
||
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Comment 25•14 years ago
|
||
MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → EXPIRED
Comment 26•14 years ago
|
||
Still valid.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: EXPIRED → ---
Updated•14 years ago
|
Status: REOPENED → NEW
Comment 27•14 years ago
|
||
Well X-Face sounds reasonable. But I'm not too keen on picon/gravatar/etc which require fetching remote data from a server that we don't have control over. Sounds like a security hole just waiting to be exploited.
Comment 28•13 years ago
|
||
In addition to the privacy issues I think this is extension fodder => WONTFIX
Status: NEW → RESOLVED
Closed: 14 years ago → 13 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•