Wednesday, June 10th, 2009
Category: Debugging
, Firefox, Utility
Over the years we are have mentioned many Firefox, and Firebug plugins to aid us Web developers. Wouldn’t it be nice to subscribe to a bundle of these tools? The Firefox Add On team has now given us that ability with Add On Collections:
Today, we’re excited to introduce a new feature to our website that will expose the niche add-ons that can be hard to find, and gives users a more active role in helping outstanding add-ons bubble to the top. One thing we’ve learned as add-ons have grown in popularity over the years is that once a user finds an add-on they love, they become a fan for life. We see this all the time as people recommend add-ons to their friends and write great reviews.
You will notice the Web Developer collection that features:
What is missing? What should be on the list?
Wednesday, June 3rd, 2009
Category: Adobe, Browsers, Debugging
We were excited to see the sneak preview of what was called Meer Meer, at the last Adobe MAX.
Today Adobe has released a preview of the newly branded Adobe BrowserLab:
BrowserLab provides web designers exact renderings of their web pages in multiple browsers and operating systems, on demand. BrowserLab is a powerful solution for cross-browser compatibility testing, featuring multiple viewing and comparison tools, as well as customizable preferences. Since BrowserLab is an online service, it can be accessed from virtually any computer connected to the web. Also, Adobe Dreamweaver® CS4 software users have access to additional functionality such as testing local and active content.
Once into the browser lab you put in the URL for the site that you want to check, and then you can see it loaded up on the server on various browsers:
This is a great tool. Being able to point my application and view how it looks in various browser in a nice UI is great. Doing onion peal analysis is great. A lot faster than other browser shot sites up there.
The team will be adding to the list of current browsers supported (OS: XP or OS X, Firefox 2/3, IE 6/7), for example adding IE 8, Chrome, etc. There is also a lot of room for other great features.
Here is my wish list:
- I would love to setup alerts and have the browser lab be watching over my site. Tell me when something goes wrong (e.g. difference in browsers in the onion peal of more than X pixels?)
- Open API: I would love to have Bespin able to send up its projects to BrowserLab. Opening a new window would work, and inline would be even cooler. They have integrated Dreamweaver so that it can do more than you can on the website. For example, you can interact with the pages and see the differences due to the live WebKit magic they have. I would love to see this on the website itself.
- Dreamweaver features online. Dreamweaver has a bunch of cool analytics that it runs on the codebase. I would love to see those available in BrowserLab, so it could tell me “hey, the CSS that you are using with this HTML structure causes a problem in IE 6″. Gold!
Really glad to see BrowserLab out there, and can’t wait to see progress. What would you like to see?
Category: Debugging, Utility
Jan Odvarko of the Firebug team has created a new plugin and site that allows you to export data from Firebug in the HTTP Archive Format and then also view the JSON data via a HTTP Archive Viewer.
The format will look a little like this:
JAVASCRIPT:
-
-
({
-
"log":{
-
"pages":[{
-
"startedDateTime":"Fri, 29 May 2009 23:19:08 GMT",
-
"id":"page_0",
-
"title":"Facebook | Home"
-
}
-
],
-
"entries":[{
-
"pageref":"page_0",
-
"startedDateTime":1243639103761,
-
"time":3503,
-
"sent":0,
-
"received":65978,
-
"overview":[],
-
"request":{
-
"method":"GET",
-
"path":"/home.php?",
-
"prePath":"http://www.facebook.com",
-
"port":-1,
-
"httpVersion":"HTTP/1.1",
-
"cookies":[{
-
"name":"login_x",
-
"value":"idontthinkso"
-
},
-
...
-
Hopefully we will see other tools sharing the same format so we can go in between!
Friday, May 22nd, 2009
Category: Debugging, Firefox, Utility
Robert Nyman has a new Firebug extension called Firefinder.
The idea is to quickly text CSS selectors/XPath in a document to see what will match, or how many instances of a certain element there are (thinking certain type of heading, for instance).
It offers:
- A quick way to filter HTML elements via CSS selector(s) or XPath
- Highlight them in the document
- List them in the Firebug panel in a collapsable list
- A count of the total matching number of elements
Friday, May 1st, 2009
Category: Cappuccino, Debugging, JavaScript, Safari
It's no secret that we're mightily impressed with the fine work of the 280 North crew, what with 280 Slides, Cappuccino, Atlas, working with SOFA to make Aristo free for other projects to use, and that whole Objective-J thing which we'll never use but we love nonetheless. ;-)
Francisco Tolmasky, one-third of the team, started blogging this week over at Alert Debugging. The inaugural post, Building a Better JavaScript Profiler with WebKit, is a bit of an opus.
He starts out pointing out a familiar sight to those of us who have profiling JavaScript:
Note the green question marks:
The reason these question marks show up is because somewhere the script in question contains an anonymous function. Anonymous functions, or lambdas as they’re sometimes referred to, are functions that you can declare just about anywhere in your program and not bother naming. Take the following code for example:
JavaScript:
-
document.addEventListener("click", function() { /*...*/ }, false);
Francisco goes on to point out that while in the case of event listeners you could simply bind the event to a non-anonymous function, for many meta-programming cases, there's no practical work-around. Further, he points out that there are often ambiguously-named functions that are also difficult to distinguish in the profiler.
displayName
To solve this problem, the Francisco introduced support for a "displayName" property into WebKit that its profiler supports, yielding much easier-to-read results:
![](http://ajaxian.com/wp-content/uploads/profiling2.png "Profiling with \\"displayName\\"")
Francisco built on this feature to create this rather nice profiling experience:
The best part about this though is that it’s not just limited to Objective-J: any language abstraction now has the opportunity to make the same use of these tools... Surprisingly enough, the folks over at Joose wasted no time incorporating this into their own library, so I’ve included links to their additions as well.
Francisco didn't stop here; he also patched the WebKit profiler to support a much better "Bottom Up View" that matches the behavior of Apple's popular Shark profiler, resulting in the ability to drill down into exactly where bottlenecks are occurring in code.
See Francisco's blog entry for more details!
Friday, April 17th, 2009
Category: Debugging, Firefox, Mozilla
Kevin Decker has released FireDiff a very cool Firebug extension that tracks changes to the page and CSS.
Firediff implements a change monitor that records all of the changes made by firebug and the application itself to CSS and the DOM. This provides insight into the functionality of the application as well as provide a record of the changes that were required to debug and tweak the page’s display.
The release, which you can find here uses recent features of the latest Firebug 1.4 code. Early days!
Friday, April 10th, 2009
Category: Debugging, Firefox, PHP
FirePHP solves the problem of AJAX debugging by sending debug information along with the response. To avoid breaking the response content, the debug information is placed into special HTTP response headers. This works for all types of requests, not just AJAX requests, which means you can even debug requests for images that are dynamically generated by a PHP script. You can use FirePHP in your development environment, or use it to track down bugs that only appear on your production site.
This is what Christoph Dorn has to say about FirePHP in his recent writeup.
He goes into detail on how you can setup the Firebug plugin, and how you use it from within PHP:
PHP:
-
-
// use an ini file to turn it on and off
-
-
-
if ($settings['FirePHP'] == 'Enabled') {
-
FB::setEnabled(true);
-
} else {
-
FB::setEnabled(false);
-
}
-
-
// log away!
-
FB::
log('This is a log message');
-
-
// selectively log
-
if (Debug::getOption('DisableCache')) {
-
// code to disable cache
-
FB::info('Cache has been disabled!');
-
} else {
-
// default code
-
}
-
Check out the article for more info.
In related news, Zend just stepped it up a notch with their new Zend Server that fits in nicely with the cloud.
Thursday, March 5th, 2009
Category: Debugging
Having trouble working out a selector to grab that DOM element? Take heart, Blake Edwards and Kit Sunde pointed us to something that may help you out: SelectorGadget.
SelectorGadget is an open source bookmarklet that makes CSS selector generation and discovery on complicated sites a breeze.
With SelectorGadget, you just click on the DOM element(s), and presto, you get a selector. Try it out! Nice work from Andrew Cantino and Kyle Maxwell.
Category: Debugging, JavaScript
Nicholas Zakas recently wrote a piece covering the basics of throwing errors in JavaScript:
You can throw an by using the throw operator and providing an object to throw. Any type of object can be thrown, however, an Error object is the most typical to use:
JavaScript:
-
-
throw new Error("Something bad happened.")
-
When you throw an error in this way, and the error isn’t caught via a try-catch statement, the browser will display the error text in the browser’s typical way.
He provides a few more details on how error handling works in browsers, and then goes on to assert that:
All JavaScript libraries should throw errors from their public interfaces for known error conditions. YUI/jQuery/Dojo/etc. can’t possibly anticipate when and where you’ll be calling their functions. It’s their job to tell you when you’re doing stupid things. Why? Because you shouldn’t have to debug into their code to figure out what went wrong. The call stack for an error should terminate in the library’s interface, no deeper. There’s nothing worse than seeing an error that’s 12 functions deep into a library; library developers have a responsibility to prevent this from happening.
A quick glance at, oh, pretty much any of the popular JavaScript frameworks out there shows that this advice is followed sparingly. Is he right that our libraries should be failing fast? Is that the "art of JavaScript", as he asserts, or is it the art of Java, etc. being brought to JavaScript? Do you follow this practice in your code?
Wednesday, February 18th, 2009
Category: Debugging, Utility
Dirk Jesse pointed us to his YAML Debug project, a cool little bookmarklet with a nice interface:
While he talks about its special abilities when mated with YAML-powered websites, its general abilities are quite handy indeed, including highlighting various code quality and accessibility metrics, conditionally removing style sheets, viewing layout information, and more.
One interesting feature is the ability to highlight the semantic structure of the document in-line, as shown below:
Content without semantic information
Content with semantic information
The YAML Debug project is calling out for feedback and feature requests; now's a good time to give it a go. It's a great complement to MODI, which focuses on DOM inspection, and Design from Allan Jardine, which provides some neat design-time tools.
Friday, February 6th, 2009
Category: Debugging, Utility
Firescope is a nice new Firebug extension that adds a reference tab to your debugging pane as well as hooks into your context menu.
Features
- You can search for HTML elements, HTML attributes, or CSS properties (or any combination). The search happens live as you type, so usually you'll only have to type one or two letters to get the results you want.
- Search results have information about browser compatibility, standards-compliance, and a brief summary of usage. There are also links to further information on the SitePoint Reference web site.
- Right-click in the search results and you'll be given two options, one of which is for more information online, and the other is to show a code example for the selected item.
- Code examples open in the side-panel of the Reference, HTML or CSS panels, and are practical examples with summaries, to show you how the item can be used. Code examples are also editable and easy to copy (simply double-click in Firefox 3 to Select-All).
- In the HTML panel you can right-click on any element name, attribute name or attribute value (include while it's being edited) and you'll have two options — to "Look up" the item you clicked on, or to "Show Code Example" for that item.
- Similarly, in the CSS panel you can right-click any property name or value, for the same options.
- While in the HTML panel, if you right-click on the tag name of the element that's currently selected (usually highlighted in dark blue), the context menu will say "Look up selection"; clicking that will then do a special search — for the selected element, all the attributes that are defined for it, and all the CSS properties that currently apply to it. The special search also happens automatically — whenever you click the "Reference" tab, the panel will default to showing you data for the currently-selected element.
- While using the Inspector to select different elements, if the Code Example side-panel in the HTML panel is open, it will automatically bring up an example for whatever element is being inspected.
- Likewise, the DOM crumbtrail responds to clicks to show code examples, if the Code Example side-panel is open. It also has context-menu items the same as the main HTML panel, with options to look-up the selected item or view a code example for it.
Thursday, January 8th, 2009
Category: Debugging
Rob Campbell posted on the 1.3 final release of Firebug, the stable release for the Firefox 3 world:
Release notes are here. As mentioned previously, this version will not be compatible with Firefox 3.1 (Shiretoko) and up. For that you’ll need a Firebug 1.4 alpha, soon to be dubbed beta available on getfirebug.com’s releases directory. Notes are on the releases page.
If I can babble a bit for a second, I’d like to say that I’m pretty proud of this release. Honza has made some fantastic improvements to the Net panel. John Barton has improved the Script panel and debugging features as well as tweaking the console. Maybe more significantly were some of the changes under the covers. The new Tracing panel (FBTrace) for debugging Firebug itself during development is a huge improvement over the previous console-based system. We’re starting to get some unittest coverage through John Resig’s and Honza’s FireUnit. And I think community involvement is at an all-time high with some excellent testing and bug reporting coming from all corners of the world. The message is getting out that Firebug is a great project to be involved in and that community contribution can really help move it forward.
So, thanks to everybody who helped out with this release. I think it’s the best Firebug yet.
The team seems to be gelling together and really doing some great work. I am looking forward to see more in 1.4 and above.
Wednesday, January 7th, 2009
Category: Canvas, Debugging
Ben was cursing at a bug in some canvas code that he was playing with, where the rendering was off. One piece of his UI was blurred instead of crisp.
The debugging exersize was fun, and he shares it with you on his personal blog.
The moral of the story is: watch out for that zoom feature in today's browsers!
Along the way, I got to learn that canvas supports fractional coordinates:
My first thought was that it would be due to fractional coordinates. I have years of experience with drawing APIs that force integer coordinates, so I’m used to relying whacking off the fractional part of a coordinate and making up the difference when necessary in a second pass. Canvas, on the other hand, supports fractional coordinates, which I’m told is the fancy thing to do these days. (How the fraction is converted to an actual pixel is depenendent on whatever drawing system is doing the heavy lifting somewhere down the stack.) When your coordinates are fractional, you can get this kind of fuzziness.
Because the interface I’m working with involves a few layers of rendering code, ensuring that integers ruled the roost took some time. But after quite a bit of poking around, I found no evidence of fractional coordinates. It was around this time I saw Vlad (Mozilla’s graphics guru) walking around the office and asked for some help.
We started looking for evidence of transforms that would introduce fractional coordinates–but ultimately came up empty handed. As we went through this process, he pointed out that the <canvas> context instances are reused, so it’s a really good idea to save() and restore() when obtaining a canvas to avoid polluting the context:
JAVASCRIPT:
-
-
var ctx = canvas.getContext("2d");
-
ctx.save();
-
// painting here
-
ctx.restore();
-
I had assumed each call produced a fresh, stateless context, so this was welcome news indeed.
But, user error was the true case:
And that’s when we noticed that I had zoomed in a click using Firefox 3’s fancy full page zoom feature. And that was causing the image the be scaled up, and the blurriness.
Monday, January 5th, 2009
Category: Debugging
Alvaro Videla has a fun post on extending the WebKit Web Inspector with something a little strange.... a game:
Alvaro walks through how to take some JavaScript/CSS/HTML and plug it into the inspector world (normally hidden somewhere like /Applications/WebKit.app/Contents/Frameworks/10.5/WebCore.framework/Versions/A/Resources/inspector) and adding panels (e.g. see the new game panel here:)
JAVASCRIPT:
-
-
this.panels = {
-
elements: new WebInspector.ElementsPanel(),
-
resources: new WebInspector.ResourcesPanel(),
-
scripts: new WebInspector.ScriptsPanel(),
-
profiles: new WebInspector.ProfilesPanel(),
-
databases: new WebInspector.DatabasesPanel(),
-
game: new WebInspector.GamePanel()
-
};
-
Thursday, December 18th, 2008
Category: Debugging, Firefox
John Resig and Jan Odvarko have announced something pretty darn cool, FireUnit.
FireUnit provides a simple JavaScript API for doing simple test logging and viewing within a new tab of Firebug.
The example given shows the API nicely:
JAVASCRIPT:
-
-
// Simple true-like/false-like testing
-
fireunit.ok( true, "I'm going to pass!" );
-
fireunit.ok( false, "I'm going to fail!" );
-
-
// Compare two strings - shows a diff of the
-
// results if they're different
-
fireunit.compare(
-
"The lazy fox jumped over the log.",
-
"The lazy brown fox jumped the log.",
-
"Are these two strings the same?"
-
);
-
-
// Compare a string using a regular expression
-
fireunit.reCompare(
-
/The .* fox jumped the log./,
-
"The lazy brown fox jumped the log.",
-
"Compare a string using a RegExp."
-
);
-
-
// Display the total results
-
fireunit.testDone();
-
-
// -- browser events
-
-
// You can also simulate browser events
-
var input = document.getElementsByTagName("input")[0];
-
fireunit.mouseDown( input );
-
fireunit.click( input );
-
fireunit.focus( input );
-
fireunit.key( input, "a" );
-
-
// -- Run batches
-
-
// Or run multiple pages of tests:
-
fireunit.runTests("test2.html", "test3.html");
-
-
// Place at the end of every test file in order to continue
-
fireunit.testDone();
-
Tuesday, December 2nd, 2008
Category: Debugging, Utility
Greg Salisbury has released a new JavaScript debugger called XBug that "currently runs on the Windows XP/Vista platform, but, it can also be used to debug webpages on Windows or Linux servers. It's cross-browser compatible, and works with Chrome, Firefox 2/3, IE 6/7, and Safari 3. After selecting your web page, you can then trace or step through your javascript code in real-time. Set breakpoints, and watchpoints in a separate code window, see a trace log while your code is executing, inspect variables, and even get an indexed list of the functions/methods in your scripts."
Fancy a try? Grab the msi and get to it.
Next Page »
