<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hello Michel!<br>
    <div id="smartTemplate4-template"><br>
      <div id="newHeader"> <b>From: </b>"Kent
        James"<a class="moz-txt-link-rfc2396E" href="mailto:kent@caspia.com"><kent@caspia.com></a><br>
        <b>Sent: </b>Thursday, 02/08/12 06:56:33 06:56 GMT Daylight
        Time {GMT DT} +0100 [Week 31]<br>
      </div>
    </div>
    <blockquote class=" cite" id="mid_501A1691_9050403_caspia_com"
      cite="mid:501A1691.9050403@caspia.com" type="cite">Hi Michel,
      <br>
      <br>
      Thank you for your efforts here! They are appreciated.
      <br>
    </blockquote>
    ditto. <br>
    <blockquote class=" cite" id="mid_501A1691_9050403_caspia_com"
      cite="mid:501A1691.9050403@caspia.com" type="cite">On 8/1/2012
      5:23 AM, Michel RENON wrote:
      <br>
      <blockquote class=" cite" id="Cite_7" type="cite">Hi,
        <br>
        <br>
        I've been silent last days because I've been working/coding for
        Thunderbird.
        <br>
        Here are my first results :
        <br>
        <br>
        - bug 281417 [1]
        <br>
        I found that a ultra-simple one-line patch would answer most of
        requests. The patch is inserted in the papercut wiki page [2].
        <br>
      </blockquote>
      Could you post it on the bug instead? The papercuts list is not
      really designed as a place to have discussions of bugs and hold
      patches, so whatever you posted there will not get any attention.
      <br>
      <br>
      <blockquote class=" cite" id="Cite_8" type="cite">
        <br>
        - bug 440377 [3]
        <br>
        I created an extension that does that ! And with autocompletion
        ! It's still not production-ready ...
        <br>
      </blockquote>
      Unless this is intended purely as a throw-away proof of concept, I
      would encourage you to consider cleaning this up and submitted it
      for review on mozilla's addon site. Looking very briefly at it, I
      can see that you did not follow the practices that the AMO editors
      will want to get it production ready as an addon - and the
      standards for an addon are generally lower than those for core
      code. There are good guides on the AMO site that show what those
      practices are.
      <br>
      <br>
      When you submit it, you are likely to get a very brief comment
      about the problem. They are very busy there, and mostly focused on
      Firefox, but still the discipline is useful. Axel Grude who hangs
      out here as well as I are both amo-editors, so we could give you
      pointers if you need it.
      <br>
    </blockquote>
    good bug! If you want to send me a test version of your extension
    first, fire away! <br>
    <br>
    I would say that must be quite hard to code with autocompletion and
    all... once we have this, since this is a html field, it would also
    be cool if addresses would be open to be "styled" via CSS (e.g. by
    wrapping them in <email> tags). I think writing a working
    extension for "testing the waters" for a possible patch is a great
    way as you can get feedback without having to mess with the core
    code. Implementing it as an extension is harder (as you have to deal
    with overlaying) but also easier (as we reviewers on AMO are a lot
    less picky than on thunderbird-bugzilla).<br>
    <blockquote class=" cite" id="mid_501A1691_9050403_caspia_com"
      cite="mid:501A1691.9050403@caspia.com" type="cite">
      <br>
      <blockquote class=" cite" id="Cite_9" type="cite">  I need help to
        correct last bugs ...
        <br>
      </blockquote>
    </blockquote>
    send it on to me :) I am good with the JS debugger.<br>
    <blockquote class=" cite" id="mid_501A1691_9050403_caspia_com"
      cite="mid:501A1691.9050403@caspia.com" type="cite">
      <br>
      It is much easier to answer a request for information when you
      break it into smaller emails. When you ask detailed questions deep
      into a long email, they are likely to get ignored.
      <br>
      <br>
      <blockquote class=" cite" id="Cite_10" type="cite">  - pb
        displaying names with non-ascii caracters :
        <br>
            create a draft with name "john éè", save, re-open it : it
        displays
        <br>
            the internally encoded name. What is the js api to decode it
        ?
        <br>
            I saw some cpp code that seems to handle that, but nothing
        for js.
        <br>
      </blockquote>
    </blockquote>
    does this relate to the previous bug?<br>
    <blockquote class=" cite" id="mid_501A1691_9050403_caspia_com"
      cite="mid:501A1691.9050403@caspia.com" type="cite">I'm not exactly
      sure what you are asking for, but here is some code of mine that
      does
      <br>
      some decoding, perhaps this is your issue:
      <br>
      <br>
          var mimeConvert = Cc["@mozilla.org/messenger/mimeconverter;1"]
      <br>
                   .getService(Ci.nsIMimeConverter);
      <br>
          var decodedSubject =  mimeConvert.decodeMimeHeader(subject,
      null, false, true);
      <br>
      <br>
        <br>
      <blockquote class=" cite" id="Cite_11" type="cite">- the default
        height of the address panel is too big. I spent hours
        searching what css rule/which js code defines that but found
        <br>
            nothing. Have you an idea ?
        <br>
      </blockquote>
      css is not my area.
      <br>
    </blockquote>
    As far as I can see from DOMi and mxr, the height isn't defined at
    the moment. the listbox <tt><span id="the-code">addressingWidget</span>
    </tt>has flex="1" and rows="4" and the container vbox <tt><span
        id="the-code">addresses-box</span></tt>  also has flex="1". <br>
<a class="moz-txt-link-freetext" href="http://mxr.mozilla.org/comm-central/source/mail/components/compose/content/messengercompose.xul#747">http://mxr.mozilla.org/comm-central/source/mail/components/compose/content/messengercompose.xul#747</a><br>
    <br>
    As far as I can see, there are no CSS rules that specify an explicit
    height for the <tt><span id="the-code">addressingWidget</span></tt><tt>
    </tt>element, which actually leads to problems when you have
    extensions installed that overlay items into the  addresses-box
    (such as copy to current - it "steals" a row from the addressing
    widget). The addresses-box can be increased / decreased by pulling
    down the splitter bar underneath. <br>
    <br>
    Without the interference of extensions, I believe that "rows=4" is
    more less designed to have one row each for <br>
    <pre>To:
Cc:
Bcc:
Reply-To:</pre>
    but that is obviously just an arbitrary decision. I think that flex
    is one of the more difficult topics, really the container <tt><span
        id="the-code">addresses-box</span></tt> determines the height,
    and it also has to react to the demands of <tt><span id="the-code">addressingWidget</span>
    </tt>for four rows. It is hard to say what a sensible default height
    should be.<br>
    <br>
    I would be happy to discuss this off list :)<br>
    <br>
    regards,<br>
      Axel<br>
  </body>
</html>