Adam Christian
March 9, 2009 by

MozMill 1.1 UI Overview

During the Open Design session at Mozilla with Aza we were informed that we could load a HTML file with a Chrome URL, allowing me to rebuild the MozMill UI a bit more like a web page instead of using the XUL constructs that I had been struggling with. Granted it feels a lot more like a web page than it does a desktop application, but the speed that I can build new UI features by using libraries like JQuery UI have made it worth it.

The combination of writing content style HTML, and the good advice we received have come together into what I feel is a pretty usable user interface. Granted this is the first revision and will probably continually be refined to become even more user friendly, but from 1.0 to 1.1 it is a vast improvement.

MozMill Editor

Improved Editor

The first major improvement is the implementation of a full featured code editor named EditArea.

We have been keeping our eye on Bespin, which we will look more into integrating when it is a bit more modular.

For the meantime EditArea does a great job, and was *relatively* painless to integrate.

Some of the features include:

  • Multiple file editing
  • Syntax hilighting
  • Full Screen mode
  • Adjustable font properties
  • Jump to line numbers
  • Search and replace
  • Automatic tabulation
  • Toggle hi-lighting
  • Toggle edit modes

EditArea implements execCommand similar to the implementation in Midas.

Reorganized Menu’s

Part of the move from XUL involved no longer relying on the toolbox, so we have reorganized the menu’s into dialog’s (don’t worry most functions have a keyboard shortcut if you are one of those people that doesn’t want to deal with that extra click).

This cleanly displays all the available options, and doesn’t clutter up the main UI. This also provides space to easily add new features that fall into these logical spaces in the future.

Test Dialog

File Dialog

Options Dialog

Improved Inspector
Inspector

There was a lot of frustration when it came to getting the results from the inspector into the editor, some of this had to do with the non editable default nature of the elements we were using to draw them out in XUL, but the integration of the feature into the IDE became very messy and confusing.

This creates an obvious separation between the rest of the UI and the inspector feature and puts helper features out in front of you to simplify the process by dumping to the clipboard and then moving you to a focused editor window.

Improved Output
Output

The output UI has been completely revamped to give you the most important information quickly, but allow you to navigate down an expandable tree to explore the output of the exception.

All of the information in the output divs can be easily selected and copied to stick in bugs etc, but also saves you a trip to the error console as it should encompass all of the information being thrown in the error object, serialized and organized into a more readable format.

Thanks to JQuery UI’s information and error boxes I was able to tweak the CSS to make some relatively attractive, but more importantly, informative UI that should quickly give you the status of your test run.

More Information

Thanks everyone who logged bugs!

  •   •   •   •   •
February 23, 2009 by

Micro-Bookmarking with MyTabs

MyTabsA few weeks ago I realized that every time I boot my laptop, one of the first things I do is to open Firefox, and immediately load about 7 web sites as tabs. Some of them requiring user interaction to navigate to the desired state. I didn’t realize that this was actually a phenomenon called “micro-bookmarking”, and that I may not be the only person who has this routine.

I don’t necessarily want to bookmark these sites, and this process of opening them is somehow part of my routine, however spending this kind of time every time I want to get to this state is just silly. Part of the ritual is to go through each of the open tabs, read the most recent updates and then close the tab, repeating this whole process many times a day.

At this point you should be starting to get the jist, to automate this whole process I created a Firefox Extension called MyTabs. The UI and use case is simple, but some of the tools I built in make it potentially very powerful.

MyTabs has the MozMill Controller built in, and is automatically setup in the tabs content window scope, allowing you to write and attach scripts to each tab to be executed ‘onload’. Thus automating the need to ever manually login to your web applications again.


Example script for logging into Facebook:

1
2
3
4
5
6
7
8
9
10
11
12
13
//Lookup the three elements I want to interact with
var email = new elementslib.ID(doc, 'email');
var pass = new elementslib.ID(doc, 'pass');
var login = doc.getElementsByClassName('UILinkButton_A')[0];
 
//Controller expects elementslib objects
var elibLogin = new elementslib.Elem(login);
 
//Tell the controller to type the credentials
tab.type(email, 'my_facebook_account@address.com');
tab.type(pass, 'my_password');
//Click the login button
tab.click(elibLogin);

This is all possible by a really slick snipped of code I found on MDC:

1
2
var newTabBrowser = gBrowser.getBrowserForTab(gBrowser.addTab("http://www.google.com/"));
newTabBrowser.addEventListener("load", function() { newTabBrowser.contentDocument.body.innerHTML = "Stuff"; }, true);


Security/Preferences

For the sake of security I made it so that you can only attach scripts, not edit them so that you friends can’t go and view your script to get those plain text passwords. All the tab data is stored in the prefManager so that it is available across sessions. However if someone knew enough to pick apart the source, install a trusted JS Shell and manually access the prefManager you may be in trouble… so be careful about super sensitive information especially on a shared machine.

Using jQuery UI I was able to make the UI relatively attractive, intuitive and possibly skinnable in the future (if you want to do this yourself, grab the source swap out the jQuery UI theme CSS directory and boom you have yourself  new look.)


Some Screenshots

Welcome
Tab OverviewAdding new TabsTab Scripting

The source is fully available on GitHub, and the XPI is available on Mozilla Add-ons.

Remember that I am currently on bug fix release 0.3, but please let me know if you run into any problems!

  •   •   •   •   •
January 28, 2009 by

XUSH (.01), you know it’s fun to say.

Over the past 8 months I have been neck deep in XUL and XPCOM and with Venkman being as unintuitive as it is I have badly needed a shell with access to the trusted space in the browser. I also had a couple more requirements, which were that it was super easy to get at (keyboard shortcut), and that it looks awesome (transparency required).

Since making things looks really nice in XUL is really hard, I decided that I would build the UI in the current Firefox content window (sorry tbird etc, but I built a less shiny version of this into Mozmill trunk for all of you).

Some of the functionality that I decided was a top priority was some slightly abstracted access to the window mediator which I am calling ‘windows’, and is simply an array of all the different windows available in the whole browser. The other big one is dir(), I am constantly looking for a property in one of the many, many objects I am trying to access and now that is really easy.

All of that goodness combined with enough space to stick real code blocks and a full history (which you can access using the shift key and up/down arrows), I find myself pretty comfortable.

After installing the extension, you can simply press ‘meta (cmd on mac) + shift + s’ and you should be greeted with the following (toggling will show/hide the shell):

UPDATE: It was pointed out to me that on windows meta may not be bound, so I have updated both the extension and git, please try ‘alt+shift+ctrl+s’ or ‘ctrl+shift+s’ on windows/linux, (I am testing in a VM so it’s a bit strange. Sorry about the confusion!) 

 

Welcome to XUSH

Welcome to XUSH

To get started, you can type ‘help’ to see what is available to you.

Help Menu

Help Menu

 

 

Other available functionality includes a big chunk of the mozmill controller for driving user actions in the browser, as well as elementslib — which gives you all kinds of powerful features for looking up nodes in the browser.

ElementsLib

ElementsLib

As I mentioned above, the windows helper can quickly give you an idea of what is open in the browser and let you directly access the objects in the windows[x] array.

Windows Helper

Windows Helper

 

The nice big console gives you enough space (and using shift) you can do multiple line commands to actually execute code snippets:

Code Blocks

Code Blocks

My next round of features will include some more helpers, including tab completion and any bug fixes I find, please let me know of any that you find!

If you would like to play with the source, I have it on github and have a python script that uses mozrunner to launch it in dev mode (with venkman installed, although now I don’t really need it), but saves you from installing and uninstalling the extension every-time you want to try out your latest code changes:

python xush.py

That should launch Firefox with XUSH and Venkman both installed and allow you to hit the shortcut and wham, test away.

After another round of bug fixes I will be submitting this to Mozilla AMO.

Other projects you might be into if this interests you:

Thanks for your interest!

  •   •   •   •   •
November 19, 2008 by

Windmill Gets a Facelift for 1.0Beta1

Working up to the Windmill 1.0 Beta 1 Release, I finally had the opportunity to put some time into making the IDE (that a lot of you live in when in test writing mode) a little bit nicer to look at.

The IDE has been growing organically since 0.1 and there was a lot of functionality hacked into it that wasn’t in the original game plan, so I did what I could to improve the beauty of the CSS/Layout as well as the whole mess of code behind it.


Launching
If you have used our latest release, or are running trunk you know that we have significantly improved the load times for the Windmill IDE. By compressing the JavaScript when the service is instantiated we can simply hand the IDE window one file that contains the vast majority of the required code.

The reason that this makes such a huge performance difference is because we are loading the source via the local windmill proxy and the data size size had very little impact, the overhead was in the browser two connection limit. When you have to pull down ~30 files two at a time it takes its toll and made the IDE feel very sluggish and more like a web page loading than an IDE.

In the process of figuring out exactly what was slowing down the launch time we added some more informative messages and output so you don’t sit there staring at a twirling circle graphic wondering if anything is happening. And to make the experience even more fun, I couldn’t help but implement a progress bar.

General Layout
I removed the toolbar at the bottom of the screen, which I felt it was an irritation for test editing (especially with the drag and droppable actions). It is now in a drop down menu at the top right of the screen, with the rest of the UI access to IDE functions.

Settings and Firebug Lite Improvements
The settings dialog has continued to improve by implementing more useful defaults, adding new options, removing deprecated options and simply making it just look better. Thanks jQuery UI!

Firebug Lite has been a very popular feature since we first announced it, which has led to a handful of bug fixes over the last month. The most major of these was that the initial Windmill implementation of Firebug Lite required you to have Internet access as it was using resources that were hosted elsewhere.

These have since been copied to our source tree and are made available by the Windmill server so you can happily introspect your Web Apps JavaScript while writing tests on your Intranet.


Output and Performance
Instead of writing all the raw windmill output to the output and performance tabs there is now an array called windmill.errorArr, where all terrible errors and warnings about technical details are pushed in the case you are interested to see all that data. However, it’s more likely that you aren’t and scrolling through all that output data becomes tedious.

This is why we have implemented output in blocks with the background color representing pass/failure with green/red (white for performance). These blocks are expandable, clicking them will reveal all output (or performance information) we know about the action that was executed. This should give you a faster general overview of your results and allow you to quickly see the details you care about.


Other Worthwhile Mentions
We moved our XPath implementation from Ajax-Slt to JS-XPath, which has proven to be more accurate when it comes to resolving XPath generated in Firefox (or using Firebug) against non XPath native browsers such as IE.

Many bugs and improvements have been made to the DOM Explorer, which should now feel a lot more like the Firebug DOM inspector, but should work in any browser.

We have also put a lot of effort into improving the communication between the JavaScript Controller and the Python Service so that when a test fails you get as much detailed information in the service as you do in the IDE.

Timing and MozMill
The timing has lined up nicely as we are working on both a 1.0 release for Windmill and MozMill. MozMill is geared towards automated testing of all applications on the Mozilla Platform and functions in the trusted space providing lots of very useful flexibility.

You can currently try out MozMill 1.0rc1 as a Firefox Add-on, and keep your eyes pealed as some exciting new MozMill feature work is around the corner.

Participate
We are always trying to make life easier for the test writer, so please log your bugs and feel free to come chat with us in #windmill on FreeNode.

  •   •   •   •   •
July 30, 2008 by

Mozilla Summit

I am currently up here in Whistler BC for the Mozilla Summit. There is about 400 people here staying at the Westin Resort & Spa up here in scenic Canada. 

The schedule for the con can be found here; http://wiki.mozilla.org/Summit2008/Sessions/Schedule

I do have to say that Mozilla is doing a great job at taking care of all their contributors and employees this week, and I feel like a lot of progress is being made on many levels. It’s very useful to see details as to how people are going about this, but it’s even more useful to see things on a bit higher level. It can be easy to get lost in the forest of Open Source, especially the way that Mozilla builds on things organically. 

The sessions are ranging from “The History of the Browser” to Mobile, QA, UE/UI, Thunderbird, planning etc. As Moz has people all over the world I am getting to hear some very interesting accents and interpretations of things. At the dinner last night I was sitting across from people from Germany, Macedonia and Israel. Amazing how the Moz projects can cross the globe and still keep communication open with each of it’s appendages. The keynote from Mitchell Baker and John Lilly gave me a very solid impression of what they feel the company values, where it should be going and most importantly their extreme satisfaction with where it currently is.

Tomorrow I will be doing a session with Mikeal Rogers and Clint Talbert to demo and explain the GristMill XUL testing framework. My piece of this project is called Mozmill, which started out as a straight across port of the Windmill source with the addition of XUL support and has turned into a much more advanced tool that will fill some needs that have existed for a very long time.

I found it interesting to find out that the VP of Engineering Mike Schroepfer announced his departure last week during Oscon. Their have been mixed reactions about this, but many speculations were proven correct today when he announced he was going to facebook, http://blog.mozilla.com/schrep/. The idea of an IPO is can be extremely appealing, apparently they made him an offer he couldn’t refuse.

This morning we were alerted that tons, literally tons of rock had fallen on the highway 99 which turns out is the most convenient of two possible road trips to get back to Vancouver. We are leaving Friday morning, and the new word is that we will all be loaded onto shuttles to embark on the 7 hour trip back to the airport. This will make for an extremely long day and I am not looking forward to it, but the trip was well worth it and I look forward to getting home and picking up where I left off at Slide.

  •   •   •   •   •
Get Adobe Flash playerPlugin by wpburn.com wordpress themes