weblog dedicated to software development, philosophy, and theology

Leave a comment

MXR, A DPS911 student’s best friend

I’m loving MXR more and more! I think I’m getting more comfortable with this tool and so I think I’ll raise the bar just a little bit for myself and aim to provide both the last two features that Alex Faaborg suggested for my release 0.6. I’m also planning to clean my code and include the comments and feedback that Dietrich provided.

Here are the ways I think we should consider exposing the ability to tag

multiple pages at the same time:Adding tags:

-multiple selection, editing the tag field in the properties pane
-multiple selection, drag operation to the tag in the left pane
-multiple selection, copy and paste to a tag folder

The one that is fascinating and challenging about developing bug fixes is that you are forced not to program for yourself which again is one key lesson learned in Barb’s Systems classes -my own personal opinion. The job is to take something that has been created and updated by numerous people, use all that and creatively attempt to apply your solution making sure that it not only works but its cohesive with the entire application / system… that’s why I agree with my Stock Broker neighbor’s perspective on computer science: “Computer science? I thought that’s more of a an art than a science…”

Lesson Learned

A lesson learned based on my previous patch thats worth sharing to new mozilla code contributors is when submitting prototype patches –that is code thats not ready to be reviewed for checkin into the source, Firefox full time engineers prefer the following:

> So basically you want me to clean up the code? So in the future when I
> submit prototype code I will just attach the file but not assign it for
> review? The assign for review is something more formal? That's what I wanted
> to talk to you about.

here's how i do it:

1. upload "WIP" (work in progress) patches, no review request, to save
my work, and for drive-by reviews of the approach
2. once you think a patch is ready to be added to the product, ask for review

Progress notes on release 0.6

My initial search for a solution to release 0.6 and some results that stood out and I’m going to further investigate. I just want to describe and share what and how I searched for a solution within MXR.

Used “drag and drop” as a value for “Text Search” field.


* line 740 — * Drag and Drop handling specifically for the Bookmarks Menu item in the


* line 1508 — * Handles drag and drop operations for views. Note that this is view agnostic!

Used “drag and drop” as a value for “Search for” field and filtered the “in files matching” field to query anything with a value of “places”. The filtering by file name (“in files match”) happens when you initially perform a “Text Search” in


* line 115 — case “cmd_paste”:
* line 116 — return this._canInsert() && this._isClipboardDataPasteable();
* line 189 — case “cmd_paste”:
* line 215 — case “cmd_paste”:
* line 216 — this.paste();
* line 342 — * Looks at the data on the clipboard to see if it is paste-able.
* line 343 — * Paste-able data is:
* line 349 — _isClipboardDataPasteable: function PC__isClipboardDataPasteable() {
* line 351 — // pasteable, with no need to unwrap all the nodes.
* line 1138 — * Paste Bookmarks and Folders from the clipboard
* line 1140 — paste: function PC_paste() {
* line 1171 — * Gets a list of transactions to perform the paste of specific types.
* line 1173 — * The types of data to form paste transactions for
* line 1174 — * @returns An array of transactions that perform the paste.
* line 1208 — // Get transactions to paste any folders, separators or links that might
* line 1213 — var txn = PlacesUtils.ptm.aggregateTransactions(“Paste”, transactions);
* line 1216 — // select the pasted items, they should be consecutive


* line 825 — * Constructs a Transaction for the drop or paste of a blob of data into
* line 828 — * The unwrapped data blob of dropped or pasted data.
* line 832 — * The container the data was dropped or pasted into


Leave a comment

Perseverance: Release 0.5

A speaker at my church illustrated perseverance as carrying a heavy load and maintaining this over a period of time. He then stated that building endurances requires taking on this load. This project, along with my other last term courses is going to build some major endurance! I just want to share this and to encourage both the people out in the web and DPS911 students (especially the ones preparing for graduation) to keep persevering! Keep fighting, Keep doing the right thing, Keep producing amazing work! You’re building endurance so that you can continue to persevere on whatever load you’re going to carry!

Release 0.5 Reflections Notes

The process of finding where I need to code came from a top-down approach where I started reading the UI layer to find the targeted functions/components (item selection/properties panel view states and the tag persistence layer). The techniques I used are mainly educated guesses/assumptions and debug “alert” statements to help me trace and walkthrough the code. In this release I also leveraged the MXR repository tool to assist in understanding code. For instance there was a discrepancies I found with a method in the Places View so I shifted my focused to MXR for an answer. The last notable highlight of release 0.5 and the code review is the persistence layer. The persistence layer is encapsulated in a XPCOM class called nsITaggingService. I created a mind map but its a hard copy. I still need to get use to creating a soft copy as I like the traditional manual way –the usability and user experience is much better!

Release 0.5 Status

There are three problems I had encountered. Two are bug related while the other is more on process. The bug related problems can be found as a posted comment filed in Bug 412002. I have also attached my latest patch there as well.
My process problem was a possible patch collision. A patch collision problem is when you create a patch from an outdated source tree on your local directory and attempt to apply it on the current source tree in the repository. I consulted my classmate Cesar about this issue. He informed me that testing out my outdated patch on a separate folder containing the updated source tree would be the best idea. Luckily I had only one block that failed during the patch and was small enough to manually fix it.

Now I want to find out a more efficient method in resolving collision problems with patches!