Show sender's picon in message header panel. (x-face)

RESOLVED WONTFIX

Status

--
enhancement
RESOLVED WONTFIX
19 years ago
7 years ago

People

(Reporter: brane, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

19 years ago
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;"/>
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!

Comment 3

19 years ago
reassigning to mscott and adding patch keyword.
Assignee: putterman → mscott
Keywords: patch

Comment 5

19 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

19 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 8

19 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.
> 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

18 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

18 years ago
Doh. I found a bug in the latest version of my patch.
The line

    foundMailFace = true;

should read

    founcPicon = true;

Comment 13

18 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

18 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

17 years ago
See bug 20417 and bug 83364 for existing X-Face work.
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

17 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?

Updated

16 years ago
Blocks: 169117

Comment 18

16 years ago
sorry, i am a bit dummy. How to apply the patch ??
Product: Browser → Seamonkey

Updated

14 years ago
Assignee: sspitzer → mail
Assignee: mail → nobody
Priority: P3 → --
QA Contact: esther → message-display
Target Milestone: Future → ---

Comment 19

10 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

10 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

10 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

10 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

10 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

10 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

9 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
Last Resolved: 9 years ago
Resolution: --- → EXPIRED
Still valid.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: EXPIRED → ---

Updated

8 years ago
Status: REOPENED → NEW

Comment 27

8 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

7 years ago
In addition to the privacy issues I think this is extension fodder => WONTFIX
Status: NEW → RESOLVED
Last Resolved: 9 years ago7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.