Work done on 3 bugs

Axel axel.grude at
Thu Aug 2 08:23:59 UTC 2012

Hello Michel!

*From: *"Kent James"<kent at>
*Sent: *Thursday, 02/08/12 06:56:33 06:56 GMT Daylight Time {GMT DT} +0100 [Week 31]
> Hi Michel,
> Thank you for your efforts here! They are appreciated.
> On 8/1/2012 5:23 AM, Michel RENON wrote:
>> Hi,
>> I've been silent last days because I've been working/coding for Thunderbird.
>> Here are my first results :
>> - bug 281417 [1]
>> I found that a ultra-simple one-line patch would answer most of requests. The patch 
>> is inserted in the papercut wiki page [2].
> 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.
>> - bug 440377 [3]
>> I created an extension that does that ! And with autocompletion ! It's still not 
>> production-ready ...
> 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.
> 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.
good bug! If you want to send me a test version of your extension first, fire away!

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).
>>   I need help to correct last bugs ...
send it on to me :) I am good with the JS debugger.
> 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.
>>   - pb displaying names with non-ascii caracters :
>>     create a draft with name "john éè", save, re-open it : it displays
>>     the internally encoded name. What is the js api to decode it ?
>>     I saw some cpp code that seems to handle that, but nothing for js.
does this relate to the previous bug?
> I'm not exactly sure what you are asking for, but here is some code of mine that does
> some decoding, perhaps this is your issue:
>     var mimeConvert = Cc[";1"]
>              .getService(Ci.nsIMimeConverter);
>     var decodedSubject =  mimeConvert.decodeMimeHeader(subject, null, false, true);
>> - the default height of the address panel is too big. I spent hours searching what 
>> css rule/which js code defines that but found
>>     nothing. Have you an idea ?
> css is not my area.
As far as I can see from DOMi and mxr, the height isn't defined at the moment. the 
listbox addressingWidget has flex="1" and rows="4" and the container vbox 
addresses-box  also has flex="1".

As far as I can see, there are no CSS rules that specify an explicit height for the 
addressingWidgetelement, 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.

Without the interference of extensions, I believe that "rows=4" is more less designed 
to have one row each for


but that is obviously just an arbitrary decision. I think that flex is one of the more 
difficult topics, really the container addresses-box determines the height, and it 
also has to react to the demands of addressingWidget for four rows. It is hard to say 
what a sensible default height should be.

I would be happy to discuss this off list :)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the tb-planning mailing list