johndduncaniii/messagefaces

displays 'face' images in the message header section of e-mails and newsgroup messages in Mozilla SeaMonkey. These face images are intended to represent the sender, in the form of photos, cartoons, logos and so on.

messagefaces's Issues

Add-on couldn't be installed because it appears to be corrupted

I downloaded the zip file, ran build and got messagefaces-1.3.xpi.

Then I installed it with Thunderbird and it appears to be corrupted.

My Thunderbird version is 60.0 on macOS Mojave.

Gravatar regression in SeaMonkey 2.53.5.1

The fix for #4 and/or a change in SeaMonkey 2.53.5.1 (or earlier) and deployed in https://github.com/JohnDDuncanIII/messagefaces/releases/tag/1.3.1 is causing a refresh loop to occur when we render the Gravatar PNG into the messagepanebox under certain circumstances.

If this occurs for you, please disable Load face images from gravatar.com.

I will try to fix this as soon as possible.

gravatar/picon need their own vbox

If there is no Face or X-Face, the picon will always display because mfSetImage is always called on the same (one) box (whatever is last).

Removing a face, then adding a new one (in add-on prefs) causes deletion of other 'face' headers

ex: mail.identity.id15.headers;xface,xface2,face
gets renamed to
mail.identity.id15.headers;xx2,face'

this affects the users 'extra' headers that are sent. If they are only using one header, or multiple headers w/o the word 'face' in them, then there is no problem.

TODO: better regex

X-Face custom colors

Given the black&white nature of X-Faces I want to make them blend with my UI colors better by having the white as the "dialog" color, and the black as the "dialog" text color. So I'm trying to apply the following CSS rules (either using userChrome.css, or using the Stylish extension):

  #fromBuddyIconXFace {
    image-rendering: -moz-crisp-edges;
    color: -moz-DialogText;
    background-color: transparent;
  }

If -moz-DialogText is actually green on my system, I'm currently seeing:

while I would like to see:

This has been previously implemented by the Mnenhy extension:

function ReadCSSColor(aoComputedStyle, asColorName, asDefaultValue)
{
  let sColor = aoComputedStyle.getPropertyCSSValue(asColorName).cssText;
  if (/^rgba\(/.test(sColor))
  {
    // have rgba values
    sColor = sColor.substr(5, sColor.length - 6);
  }
  else if (/^rgb\(/.test(sColor))
  {
    // only rgb values, assume opaque
    sColor = sColor.substr(4, sColor.length - 5) + ",1";
  }
  else if (sColor == "transparent")
  {
    // special value
    sColor = "0,0,0,0";
  }
  else
  {
    // default: plain opaque white
    sColor = asDefaultValue;
  }
  return sColor;
}


//
//  Create data URL for X-Face-PNG
//
let goPNGFace = new PNGFace();

function FaceURL(asFace, aoComputedStyle)
{
  UnCompAll(asFace.replace(/[^!-~]/g, "")); // eliminate illegal chars
  Gen();

  // set colour values:
  //  #fromBuddyIcon
  //  {
  //    color:            green;
  //    color:            -moz-rgba(50%, 50%, 50%, 0.5);
  //    background-color: red;
  //    background-color: transparent;
  //    padding:          0 ! important;
  //    margin:           5px;
  //  }
  // Unfortunately, the alpha channel value of -moz-rgba is retrievable
  // only on trunk since about 2007-01-24...

  // background; defaults to plain opaque white
  let sBackColors = ReadCSSColor(aoComputedStyle, "background-color", "255,255,255,1");
  goPNGFace.Color(0, sBackColors);
  // foreground; defaults to plain opaque black
  let oForeColors = ReadCSSColor(aoComputedStyle, "color", "0,0,0,1");
  goPNGFace.Color(1, oForeColors);

  return "data:image/png;base64," + btoa(goPNGFace.URL(F));
}

Stuck loading IMAP message

The issue is not apparent if the message has already been preloaded locally – that is using the default Syncronization & Storage account setting (checked):

☑ Keep messages for this account on this computer

Unchecking this causes any new (not preloaded locally) message to get stuck loading ("Downloading message...") while selecting it to view, given the MessageFaces extension has been installed and enabled. Preloading the message by other means like using the "Download Now" button from the Folder Properties / Synchronization tab also enables it to be viewed along side with the MessageFaces shown. Keeping all messages loaded locally may not be feasible for some IMAP usages (like with the "All Mail" folder of Gmail).

This is all using SeaMonkey 2.49.3 but happens with previous versions, also. Can't really say about Thunderbird as the extension doesn't appear to function properly with the current version 52.7.0 for me – no face images, and enlarged message header with blank area. Loading IMAP messages doesn't get stuck using this version of Thunderbird, though.

Note, after a message gets stuck loading the SeaMonkey process doesn't exit normally and should be forced to stop.