June 8
The pattern is not full
This past Friday I made my first Jetpack and on Sunday while lazily waiting for chores to finish themselves I posted my Jetpack on userscripts.org.
Bugzilla – Air Traffic Control
For Jetpackers a mid-air collision is an especially scary thing.
So this Jetpack does a pretty simple thing to help you avoid the mid-air collision by notifying you before it’s about to happen.
For every tab you have with a bug open this Jetpack does a simple check in the background to see if someone else has modified the bug while you were looking at it.
Code
The code for this is pretty simple and in total it probably took me only an hour to get up and running and then a bunch more time polishing things off. Here’s the break down.
I have a simple regex to find urls that are showing a bug:
var show_bug_regex = /^https:\/\/bugzilla\.mozilla\.org\/show_bug\.cgi\?id=(\d+)/;
Then I check if the url matches whenever a new page is loaded in a tab:
jetpack.tabs.onReady(function(doc) {
// here we setup our persistent check
var match = this.url.match(show_bug_regex);
if (match) {
init(this);
this.bug_id = match[1];
startCheckingTab(this);
}
});
Also for good measure I do a similar check when a tab is focused, in case the Jetpack wasn’t installed or running during the original load.
jetpack.tabs.onFocus(function() {
// here we just double check out status
var match = this.url.match(show_bug_regex);
if (match) {
/* if we've already notified then we aren't checking anymore */
if ( alreadyNotifiedTab(this) )
return;
if ( ! areCheckingTab(this) ) {
// they focused a url match that we haven't been checking!
init(this);
this.bug_id = match[1];
startCheckingTab(this);
} else {
resetCheckingTabInterval(this);
}
}
});
The start checking function simply runs an ajax request against the bug on an interval. All that was needed for this was to know if the bug had changed from the last time we looked so we build a url that only retrieves the delta_ts field to create a Date object.
"https://bugzilla.mozilla.org/show_bug.cgi?id=" + bug_id + "&ctype=xml&field=delta_ts";
That’s about it. If you want to check out the source or install it yourself you can go to the Bugzilla – Air Traffic Control page at userscripts.
Yay! This message always scared the hell out of me.
It could just as well have said: THE PLANE IS GOING DOWN, AND IT’S YOUR FAULT!
Wouldn’t be better to update comments display by AJAX marking it on red or doing other visual effect?
Andreas: haha, I know how you feel. Each time I get one I think for a second “Did I just break something?”… “Things collided!”
Maciej: You could pull in the latest comments but it’s extremely difficult to do much more. If someone modified a flag on the bug that will trigger a mid-air collision as well and it would be really hard to work out the conflicting flag. So really people have to reload no matter what.
I really wanted to do a lot more with this extension but Bugzilla is very old technology (web 0.2, not web 2.0). If you take a look at the HTML code you’ll see how broken it is, to work around it would take a substantial effort.
“Save and reload”? Save what? And after the reload? How to know what has changed?
Btw, entering a website (OpenID enabled!) gives strange errors for me.
Jens: I suppose that part could be clearer. Usually you have to save your comment if you made one and anything else that you might have changed in the form. It’s possible to figure out what changed however it’s a bit of work. It might be easy to start out with some simple change detection wrt the CC list or new comments and work from there.
I’ll try to look into the OpenID issue
Well, what do you mean by “save”? Copy the comment to the clipboard, ok …
Change detection? Isn’t there a change summary, that also gets sent by e-mail to subscribers?
P.S.: The exact error is:
Fatal error: Call to undefined function add_submenu_page() in /home/.peeper/clarkbw/clarkbw.net/blog/wp-content/plugins/structuredblogging.php on line 322
> Change detection? Isn’t there a change summary, that also gets sent by e-mail to subscribers?
But it does not need to save a state on server. E-mail can be send by a hook.
Yeah copy/paste is about the only way to save it. There is a firefox pref that is off by default which saves form fields on SSL connections. With that turned on you can just reload, but right now it will lose your comment and anything else you changed.
The change detection is possible at the level of this Jetpack. On the first request you could ask bugzilla for all the fields. Then on subsequent requests you’d only need to ask for the delta. Once you detect a change you could ask for all fields again and determine what changed. The code for this wouldn’t be that hard and you could display the change in some fashion that replaces the current notification. However the next part is hard.
Once you’ve figured out what changed likely the next step would be to try to merge those changes so a reload isn’t required. And this is where it gets near impossible. I tried for a while to insert new comments in order to allow myself to just post my comment but bugzilla holds some unnecessary state information in the form that makes this hard. I suppose with some real investigation this would be possible, but I suspect very fragile.
PS: I think I fixed the error, the structured blogging plugin was broken.
Test …
If this works, it works.
Uhm, just pressing CMD+R works for me in order to update the bug if it was changed in the mean time. The changes I made to the form fields will not go away.
Nice hack. This’ll have me installing JetPack.
Pretty cool! FWIW, Bugzilla 3.4 will have a Bug.get_history XML-RPC API that will allow you to figure out what has changed.
-Max
Fred: wow, I was certain that was a bug in Firefox from a while ago where you needed to set browser.cache.disk_cache_ssl to true for that to work. I guess I can update the code to add a document.reload(); link in there or even try to automatically reload.
Thanks crowder! Take a look at the source and let me know if you have any improvements.
Max: That would be sweet! I’d love to have some way to display the history.
Also, if you don’t mind, I was getting some inconsistencies checking the ifModified header; any ideas on that? That could have been some passing bug in my code but it seemed like bugzilla was not updating the ifModified flag so I always had to grab the XML. (i commented out the ifModified section in the source http://userscripts.org/jetpacks/27/source)
I think automatically reloading could be disorienting (maybe do that as a pref?), but a reload link would be nice. Also, it would be nice if my own posts didn’t constitute a change, can you update the change time to the time of the load, if I’m on a process_bug page?
Haven’t looked at your code yet, too much of my own to worry about…
The change detection is possible at the level of this Jetpack. On the first request you could ask bugzilla for all the fields. Then on subsequent requests you’d only need to ask for the delta. Once you detect a change you could ask for all fields again and determine what changed. The code for this wouldn’t be that hard and you could display the change in some fashion that replaces the current notification. However the next part is hard.
Awesome stuff…I just had a similar programming question you answered for me in this article…thanks!