Posts Tagged Bugzilla

v0.4 Release - Linkifying all Bug Strings

This post is again concerning my fixes for bug 459727. One of my goals for this release is to fix the bug link functionality. I’ve made some progress on that front in terms of creating correct bug links for the differnt types of patterns presented. This time I decided to tackle the other issue with bug links.

The problem is that for any given string that contains bug links only the very first bug string is converted into a link. The subsequent ones fail to get converted. Case in point below:

Both the first bug string “bug 437288″ and the second one, “bug 437288″ should be converted into buglinks but only the first one actually gets converted. This is what I’m looking to fix.

Now, this problem had me stumped for a while. I tried solving it using regexp functions in JavaScript but that was a dead end. I tried to think up other ways but none of them seemed to make sense to me.

Yesterday, while staring at my computer and thinking about this issue it just hit me, a perfect example of the light bulb effect. The answer to my problem was RECURSION!!! A concept I had come to dispise during my data structures and alogrithms class. I had never really used it in any of my programs before. This would be the first time.

Lets jump into the code as I explain this further. I have my main work horse function that creates the bug links:

function createBuglink(str) {
  //Create buglink
  var matchFound = new Boolean(false);
  var bugInDesc = 0;
  var pattern = -1;
  var bugLink = "";
 
  re = new RegExp("[bB][uU][gG]\\s\\d\{6\}");
  re2 = new RegExp("b=\\d\{6\}");
  re3 = new RegExp("\\d\{6\}\\W");
 
  bugInDesc = str.search(re);
  if(bugInDesc != -1) {
    matchFound = true;
	pattern = 1;
  } else {
      bugInDesc = str.search(re2);
	  if(bugInDesc != -1) {
	    matchFound = true;
	    pattern = 2;
	  } else {
	      bugInDesc = str.search(re3);
	      if(bugInDesc != -1) {
	        matchFound = true;
		    pattern = 3;
		  }
	  }
  }
 
  if(matchFound == true) {
    if(pattern == 1) {
	  bugLink = bugLinkify(bugInDesc, str, 4, 10);
	} else if(pattern == 2) {
	  bugLink = bugLinkify(bugInDesc, str, 2, 8);
    } else if(pattern == 3) {
	  bugLink = bugLinkify(bugInDesc, str, 0, 6);
    }	
  } else { //No bug provided
      bugLink = str;
    }
 
  return bugLink;
}

Then I have a function that does the actual string manipulation to insert the link code into the string which is called within createBugLink():

function bugLinkify(bugInDesc, str, start, end) {
  var bugLinkName = str.substring(bugInDesc, bugInDesc + end);
  var bugNumber = bugLinkName.substring(start, end);
  var bugLink = 
    str.substring(0, bugInDesc) + 
    '<a href=\"https://bugzilla.mozilla.org/show_bug.cgi?id=' + 
    bugNumber + 
    '\">' + 
    bugLinkName + 
    '</a>' + 
    createBuglink(str.substring(bugInDesc + end, str.length));
 
  return bugLink;
}

Now, in bugLinkify() the genius of recursion gets to take over. I just call the createBuglink() function again on the rest of the string that didn’t get converted into a buglink and keeps gettig called until there are no bug strings left to be converted.

The upside to this method is that a string could contain an unlimited amount of bug strings and they would all get converted into bug links. But the thing I love most about this method is that I didn’t have to add even a SINGLE line of code. That fact makes this implementation awesome. Gaining functionality without having to add more lines of code is always great.

The following are the results:

, , , , ,

1 Comment

v0.3 Release - Problems with my Patch for bug 459727

Lately there has been some activity on bug 459727 concerning the patch I had submitted to implement an OnScroll feature for the pushlog. View comments 8 and 9 to see the problems that jorendorff as identified. So far there hasn’t been an official review but it is inevitable that I will have to make changes to the patch I had submitted.

In comments 10 and 12 I underlined what steps I will be taking to fix the problems that jorendorff has identified so far. They don’t seem to be major changes although I am worried about using JSON.parse(). I don’t know if that will work or not. I guess I will have to try it out and see what I can do.

Also I don’t really understand what is wrong with using `new Function(”return ” + entries.responseText) ()` as jorendorff mentioned in comment 9. In comment 11, Justin mentioned that it may cause vulnerabilities to XSS attacks but he couldn’t explain why that was. This has me interested and I would love it if someone could tell me why.

This is the biggest patch I submitted for my v0.2 so I’m expecting to go through several iterations before the patch is accepted. Look out for a new patch soon…

, , , ,

No Comments

My patch for Bug 448707 Approved!

Some good news to report today. My patch for bug 448707 has been approved by jorendorff. He did find some problems but they were minor enough that they could be ignored for now.

Getting an r+ on the first go is pleasently surprising. Hopefully I can keep moving along and get a patch up for the graph view very soon.

, , ,

No Comments

v0.3 Release - Fix for my Patch for bug 445560

In a previous blog post I detailed problems with my previous patch for bug 445560. There were 2 problems that ted identified which need to be fixed:

  1. Should use ids instead of dates
  2. Should store unique identifiers in the class instead of the id of the tag

The Fix

I made a change to pushlog-feed.py to use ids of the changeset instead of the dates by adding the following code which passes the id to the client-side (line 270):

248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
def changelist(limit=0, **map):
        allentries = []
        lastid = None
        ch = None
        l = []
        mergehidden = ""
        p = 0
        currentpush = None
        for id, user, date, node in entries:
            ctx = web.repo.changectx(node)
            n = ctx.node()
            entry = {"author": ctx.user(),
                     "desc": ctx.description(),
                     "files": web.listfilediffs(tmpl, ctx.files(), n),
                     "rev": ctx.rev(),
                     "node": hex(n),
                     "tags": nodetagsdict(web.repo, n),
                     "branches": nodebranchdict(web.repo, ctx),
                     "inbranch": nodeinbranch(web.repo, ctx),
                     "hidden": "",
                     "push": [],
                     "mergerollup": [],
                     "Id": id
                     }

Then a change needed to be made to the hg_templates\gitweb_mozilla\map file. The id needs to be stored in the class of the hidden rows and the expand row. So I made the following changes:

mergehidden = '<br/>← #count# hidden changesets <a class="expand hideidentifier#Id#" href="#">[Expand]</a>'
pushlogentry = '<tr class="parity#parity# #hidden# identifier#Id#">...

Now each expand row will have the class hideidentifier#id#, which is a unique identifier telling us which expand link is clicked. Then we can take this unique identifier and hide all the rows that have the same #Id#. To do this I needed to add some JavaScript code to hg_templates\gitweb_mozilla\pushlog.tmpl…

30
31
32
33
    var id = $(this).attr("class");
    id = '.' + id.substring(11, id.length);
    $(id).nextAll(id).toggle();
    return false;

So line 30 gets the id of the current object (the expand row whose [Expand] link is clicked by the user). So the id might be something like “hideidentifier2434″ after line 30 is executed. Next a ‘.’ character is added on the front and the id is substringed to give us something like “.identifier2434″. Now we have the class of the rows we want to hide/unhide and we can then execute line 32. Voila! Problem fixed.

, , , , , ,

No Comments

v0.3 Release - Problem with my Patch for bug 445560

I had a discussion with ted today relating to my patch for bug 445560 for the pushlog. There seems to be a slight problem with it. When there are 2 merges on one page, if one clicks the second expand link, it shows those changesets, but the row with the [Expand] link disappears (example of the problem). This is a problem that we don’t want happening.

Problem

Currently I’m using the date as a unique identifier (view here for full details) but if somehow (very unlikely, but possible) two rows have the same date then there will be a problem, which is the case with the example linked above.

Fix

This problem can be solved by using the id as the unique identifier instead of the date. This will work because each changeset has a different id and each set merge changesets have the same id so it will allow one to identify all the merge changesets to hide on a page and not hide the ones that shouldn’t be hidden.

I will be putting up a new patch to fix this issue.

Edit: I didn’t read the comments (comment #6) that ted put on bug 445560 for my patch before I made this post. There is another problem that he identified, which I need to fix. Apparently I’m not allowed to have multiple elements with the same id so I can’t be putting my unique identifiers in the id of the tag. ted recommended putting them in the class of the tag which is what I will be doing. Look out for a new blog post explaining the code.

, , , , , ,

No Comments

Bugzilla - Watch a User Feature

As a part of an exercise humph asked us to fiddle around with bugzilla. In this case, watch another user. Now what does that mean? That means that any bugmail that the user you are tracking receives will get forwarded to you. You can set this by

  1. going to bugzilla
  2. logging in
  3. going to preferences
  4. adding a person to your watch list.

This basically gives you an idea of what kind and amount of bugmail that that person receives. It puts you in their shoes.

I decided to track bsmedberg since he seems to be a busy man. So I “watched” him for about a week and got around 70 bugmail during that time. Thats quite a lot of traffic for just one week. It definitely gives me an idea of the amount of work bsmedberg has to deal with on a weekly basis, and this is just email.

This bugzilla feature gives me an idea of how someone like bsmedberg (someone that has a more important presence in the Mozilla community than myself) deals with the various kinds of bugs that he recieves on a regular basis. I’d recommend this feature to any novice or beginner looking to get involved with tracking or fixing bugs.

,

3 Comments