This lab, I found to be quite challenging yet unique and interesting at the same time. Utilizing the knowledge learned from previous lectures, I discovered that I became quickly familiar with the Mozilla tree and searching through MXR and the directory structure of the debug build we were using. The specific goal of altering the behaviour of the tabbed browsing functionality was a great choice as it was not too difficult nor too easy.
Admitedly, the hands on approach of the lab aided in the specific areas to change. I believe that without the aid, I would have certainly found the specific file, tabbrowser.xml but the code to be changed would require a considerable amount of investigation before editting.
The code that I did change was similar to that in the lab.
// Insert tab after current tab, not at end.
var currentTabIndex = this.mTabContainer.selectedIndex; this.mTabContainer.insertBefore(t, this.mTabContainer.childNodes.item(currentTabIndex + 1));
Having then compiled this code, I discovered the same bug posted in the lab. The functionality works – tabs open after the currently selected tab, but tabs would not close.
Post compile, I continued to read the lab and mimicked the changes by altering line #1228.
var position = currentTabIndex + 1
Prior to this change, the current position based on the number of tab nodes was used. With this change, this solved the close tab issue, but alas again, more buggers. With two tabs open, when you close one, they both close – interesting.
Anyhow, I learned how fragile some code can be. It reminds me of a deck of cards built into a house, you have to be very careful which cards you wish to remove or add to your masterpiece. Altering a single line changed other lines. Mozilla is right when they name dev/unstable builds, Minefield. You have to observe everything you do and watch where you step.