Update anyone?

Talk about timing issues.

So this is meant to be the blog where I tell everyone how I managed to finish two bugs and get them to work perfectly and what not.

Sadly though that isn't the case as I feel I'm more or less where I started.

But lets go back to the beginning.

I chose two bugs, the first being 471560 and the second being 501076.

Both are bugs related to the copy/move menu that can be brought up by right clicking upon any email header. The first expresses a wanted addon that may allow new folders to be added from with the move/copy folder in the sense of ("Local" → "Sub Local" → "New Folder in Sub Local ,"New Folder in Local") and so forth. So when I first chose the bug I assumed that the menu building might just be a loop (which it is) that works in a nested method with nice little action listeners or something.

But instead after using mxr for a while I came up with this file (responsible for generation the move/copy menu) → folderWidgets.xml

The minute I saw that I felt a little snap inside of me. Javascript is not my favourite thing, embedded within xml kind of just adds a bit of not so nice tang to it and above that everything was working in a (I'm your dad, your my son.. go check if all your sons have any sons that may need to be accounted for) which made tracing go wack.

But yeah anyways the main problem that limited any progress was the generic format they were using. Your have a few accounts, from those accounts a flat list is generated that contains all the folders and subfolders within.

So the method that interested me most within folderWidgets → _ensureInitialized which is responsible for seeing if the menu was built, and if not then to rebuild it by tearing it down and building it up again.

Line 331 to 336 interest me most as as you can see below they are responsible for rebuilding the list.

             // subFolders for that parent
             var myenum = this._parentFolder.subFolders;
             while (myenum.hasMoreElements()) {
               folders.push(myenum.getNext().QueryInterface(Ci.nsIMsgFolder));
             }
           }

What this does is take each parent and get its subfolders and add them to the list. So what I done was try and add a line that can add an empty folder with a name of *CREATE FOLDER* after the while loop that for subElements. However that was incorrect since it disrupts the concept of a general folder generator by manipulation of the method in which the folder list is generated, and not how the menu list is actually generated.

So the second option was to go the method _build(folders) which is called from _ensureInitialized() at line 338 which builds the list into an actual menu. This method is alot more benificial as it takes the flat list we generated in ensureInitialized and turns it into menu items. This is were I wasn't able to continue as no matter which menu items or menus I have added even randomly (just to ensure it works) I was not able to come up with anything other then having the "CREATE FOLDER" shown within only one root. Other than that the result was always a runtime javascript error which I couldn't debug even after I ran the thunderbird java debugger which resulted in an empty menu.

Then thunderbird decided to give me compiling errors (not related with editing xml javascript) and everything just went grey.




The second bug 501076 was also related to the same exact folderWidgets.xml file and relates to the recent menu file only updating when restarting. The only idea i had to why this wasn't working was a missing listener but was not able to go anywhere beyond that point.


Seems like quite a miserable note all in all.