Tabbed Composition - implementation questions

Jonathan Protzenko jonathan.protzenko at
Tue May 7 08:50:17 UTC 2013

Hi Liam,

Sorry for the delay in replying. I've been updating the bug with a
comment, but I'm replying here as well for posterity.

On 03/01/2013 07:26 AM, Liam Edwards-Playne wrote:
> Hello all,
> As you may/may not know, I've been working on tabbed composition for
> the past month now and I'd like some help on the
> codebase/architecture. Currently ported the bulk of OpenComposeWindow
> and OpenComposeWindowParams to JS functions and have rewritten nearly
> all the calls to the JS port, and now looking into the window/tab
> management stuff.  
> As discussed on BugZilla, it would be best to implement the new
> 'compose tab' like the message view tab
> (mail/base/content/mailTabs.js), so it can be opened in either a new
> window or new tab and so forth. This would also allow for older users
> to still use windows (should tabbed composition be a default?). So how
> are they implemented? How can I iterate over open compose tabs etc.?
The bulk of the code that does tab handling is in
. You can iterate over tabs by doing (untested):

let tabmail = document.getElementById("tabmail");
for (let candidate of tabmail.tabInfo)

You can easily define new tab types, I'm pretty sure that's what I did
with the "compose in a tab" experiment. You have to reimplement a few
things yourself but specialtabs.js contains good examples of how to
implement a new tab type.
> After this, I have to finish porting OpenComposeWindow, which includes:
> - integrating GetOrigWindowSelection to use the new compose tab mode
> - integrating LoadDraftOrTemplate - which is a tricky function
> compared to the others because it goes down a long road of function
> calls (DisplayMessage onwards) before it reaches any UI-related code. 
> - integrating ComposeMessage to iterate through open draft tabs
> - rewrite the argument passing mechanism (nsMsgComposeParams) to use
> something other than window.arguments - MsgComposeCommands.js
> - some other misc. stuff todo with js string encoding
I would suggest, as much as you can, to break this down into smaller
patches. You could implement, as a first step, a "composition manager"
written in JS. The JS object would provide JS-implemented versions of
GetOrigWindowSelection, possibly LoadDraftOrTemplate. This would
simplify the code by a significant margin, while providing after that an
easy way to build on top of that JS and make it work with composition in
a tab. Iterating of the tabs from C++, inside GetOrigWindowSelection is
going to be an incredible pain -- I think it's worth looking into
switching some of these methods to JS first.
> After that, some more things:
> - Rewrite the code to close the message tab (so it doesn't try to
> close the window and crash)
I've had that as well!
> - Redesign the UX so there are not 2 menu bars - this will be very
> interesting
This is another big chunk of work. What about having the "composition in
a tab" feature pref'd off, while we work out to solve these issues? This
would allow you to land a first set of patches and prevent them from
bitrotting, and this would allow other people to start playing with the
feature and find bugs, while we solve other problems in smaller chunks.
> - Add options similar to "Preferences->Advanced->Reading and Display"
> (open message in new tab/window etc.)
> When the majority of the coding is done, we'll have to get in touch
> with UX for the menu bar and whether compose should open in a new tab
> by default. 
> Look forward to getting this long-awaited feature done.
As Magnus said on the bug, it's usually better to hang out in #maildev
on IRC as people tend to be more responsive there.

Good luck and don't hesitate to ask specific questions about the code in
this thread, I'll do my best to reply if I have the knowledge.


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

More information about the tb-planning mailing list