Firefox vs Firebug
So why would you use the built-in tools?
Well, for one thing, Firebug feels a little sluggish. It's a massive extension written in JavaScript (like all extensions), and it hooks into everything. For another, it doesn't have the cool 3D DOM visualization. :) Or access to the JavaScript helper commands, like pprint().
But really, those are minor points. You'd do fine just sticking with Firebug as your one-stop shop. I personally still use the Firefox Web Console because that's the one tool I need most often, and the built-in version is faster and cleaner (probably because it's just one thing). For everything else, there's Firebug.
Getting Started
Firebug runs both deep and wide when it comes to features. It's fairly intuitive, and it's features are quite discoverable. It's also hard to describe without tons of screenshots. These are all very good incentives for me to not bother regurgitating everything from the tour and docs, so I'll just skim the parts I think are interesting, confusing, or especially relevant. Note: The docs link goes to a wiki which looks empty until you notice the table of contents in the sidebar.
Just remember that it's worth hovering, clicking, and right-clicking on just about everything in Firebug to see what happens. And if you have any questions you can't answer via Google, try the IRC channel.
On/Off, Hide/Show, Dock/Detach...
After installing it, you'll see a bug icon/drop-down menu to the right of the search box (which is to the right of the address bar). You can turn it on by clicking on it, though it's faster to just press F12. Like with Firefox's Web Console, you can change it's position or detach it completely. (Ctrl+F12 will open it as a separate window.)
Once the Firebug pane is open, if you click on the bug icon again it will minimize the pane but leave Firebug turned on, which means activity will continue to be monitored and logged. Same with pressing F12 again. So how do you turn the damn thing off?
At the top right of the pane are three buttons which minimize, detach, and turn off Firebug. (When in detached mode, the detach button will un-detach it.) Aside from that last button with the power icon, the other way to turn off Firebug is Shift+F12.
The interactions between the three shortcuts can be confusing.
If Firebug is off:
- F12: Turn it on and show the pane docked within the browser.
- Ctrl+F12: Turn it on and show the pane in a separate window.
- F12: Hide/Show the pane (whether it's docked or detached)
- Ctrl+F12: Switch between docked and detached (and show the pane if hidden)
- Shift+F12: Turn Firebug off (if it's detached, the separate window remains, just in a disabled state)
Got it? :)
Firebug is enabled on a per-site basis, which means if you turn it on and then switch to a different tab, it will still be off there (unless that tab is pointed at the same site). The settings will be remembered, so if you close a page while Firebug is on then visit it again in the future, Firebug will still be enabled for it.
You can enable it for all sites from the bug menu. You can also see how many bugs are active across the whole broswer by hovering over the bug icon, but only if it's on in your current tab.
Lastly, Firebug can only monitor activity when it's enabled, so if you want to study network activity or see JavaScript errors and log messages, you'll have to reload the page after enabling it the first time.
So... Many... Tabs...
There are seven tabs across the top of the Firebug pane. HTML, CSS, and DOM are always enabled. Console, Script, Net, and Cookies can be enabled or disabled to reduce performance overhead. You can turn them all on/off at once from the bug menu.
Speaking of the bug menu, now that the pane is open you can see yet another bug at the top left corner. If you click on it, you get another drop-down menu. I'll refer to it as the inner bug menu. Other than the "Firebug UI Location", which is identical to the outer bug menu, it has different options.
If you click the next icon over (the one with the mouse pointer over a rectangle), it will activate a mode that let's you click on part of the page to choose a DOM element to inspect. As you move the mouse over the page, the boxes of the DOM elements you pass over will be highlighted. If Firebug is off/hidden, you can save time by just right-clicking on an element you want to inspect and choose "Inspect Element with Firebug". That take us to our first panel of the day...
Diving Into The Panels
HTML
The HTML panel is the main reason I use Firebug. The left pane displays the DOM tree, and the right pane has four tabs (Style, Computed, Layout, DOM) for showing the details of the currently selected element. As you hover over the elements in the tree, the element on the page will be highlighted. When you click on an element in the tree pane, it becomes selected.
Turning our attention now to the right pane, the Style tab shows all parts of all loaded stylesheets that apply to the current element, in order of highest to lowest CSS specificity (I think). Lower-down lines are shown crossed out if they were overridden by higher-up lines. File names and numbers are referenced. Things are linked. Colors and images show up when you hover over them. It's great!
The Computed tab shows you the final computed value for many CSS properties. The Layout tab shows the box model and content/padding/border/margin sizes, and are also hoverable/clickable. The DOM tab shows the JavaScript properties of the current element, which can be very useful when debugging our apps.
We haven't gotten to Ember views/templates yet, but it's important to point out that since we'll be dynamically assembling the DOM in our application using views and templates (plus all of the <script> tags that Ember adds to implement bound properties), having a good tool to inspect the DOM structure we end up with after loading our app is essential.
Script
This is a full-featured debugger (and profiler!), similar to the one built-in to Firefox. Like the built-on one, Firebug's debugger behaves like most debuggers, so I'll just forward you to the tour and doc pages if you want more details.
As for pros/cons vs the built-in debugger, I really don't have enough experience yet with either to form an opinion. When I do, I'll post about it. In the meantime, would love to hear what insights the rest of you might have about this. Post about it in the comments!
DOM
The DOM panel is interesting. You start at the root of the DOM tree: the window object. You can inspect all of it's properties, click on values, etc. If you click on a child element, that becomes the new context, and your current DOM path gets represented along the top in breadcrumb form. If you refresh the page, it will remember where you were in the tree.
Network
The Network panel — like the Net messages in the Firefox Web Console — shows a log of all HTTP requests the browser makes and gives you access to all the information about them you could want.
Improvements over the Firefox Web Console:
- It's visually superior.
- Automatically includes the request/response bodies (you have to turn that on in Firefox's Web Console each session).
- Includes information about the local cache.
- Let's you filter requests based on resource type.
- Go hover over the timeline bars. Have a tissue handy for the drool.
Console
Like with the debugger, I don't have enough experience yet with the Firebug console to evaluate it's strength and weaknesses or compare/contrast it to Firefox's built-in Web Console. Again, if you have anything to share about this, post a comment!
 |
| Stolen from https://getfirebug.com/wiki/index.php/Console_Panel |
One problem I noticed was that the Firebug console doesn't always play nice with the built-in console with regards to logging. If both are open, sometimes console.log() messages from my code goes to both, and sometimes only to Firebug. If I manually type console.log in the command line of one of the consoles, it only outputs to that console. Lastly, I sometimes end up with this error in the built-in console:
"The Web Console logging API (console.log, console.info, console.warn, console.error) has been disabled by a script on this page."A few interesting things I noticed about the Firebug console:
- As I mentioned at the beginning of this post, the JavaScript helpers that Firefox adds to it's Web Console, such as pprint(), are not accessible here. In the case of keys(), you can fall back on JavaScript's built-in Object.keys(). (More on JavaScript tomorrow.)
- Firebug has the same $0 feature as Firefox, where the value is set by selecting an element to inspect. It also sets $1 to the previously selected element. The variables are not cross-referenceable, however. I checked: Firefox's $0 doesn't get set by Firebug's inspector, and vice versa.
- The command line (the input box along the bottom that you type JavaScript into) is expandable. Click the red up-arrow button at the bottom right corner to change the one-line box into a right pane when you want to write/edit multiple lines of JavaScript and test it as you go with the "Run" button.
- The docs also point out that the "Copy" button in the expanded command line pane is useful for writing bookmarklets. It copies the code to your clipboard and prepends it with javascript:, ready to be pasted directly into a bookmark URL.
Bookmarklets
A bookmarklet is a snippet of JavaScript code embedded in a link or bookmark such that when you click on it, it does something useful in the context of the current page. Here's a simple example:
<a href="javascript: {alert('hi!')};void(0);">click me</a>
click meThe javascript: protocol was created in order to be able to use JavaScript to dynamically generate a document to go to, and is intended to be embedded in the href attribute of a link since it's considered a valid URI. It can therefore also be bookmarked — either by right-clicking on it and selecting "Bookmark", or by dragging the link onto the Bookmarks Toolbar. Thus, bookmarklet.
If the return value of the JavaScript is a string, that string gets parsed and rendered as an HTML document as if clicking the link or bookmark had taken you to a new page. Example:
click me
In order to use a bookmarklet to run some code without going to a new document you must return an undefined value. The most common way of achieving this is wrapping the code in {...};void(0);, which you can see in the first example above.
I've known of bookmarklets for a while, though I'd only used them once many years ago to submit pages to delicious.com. After being reminded of them by the Firebug docs today, it occurred to me that since I'm now becoming a JavaScript programmer, I can start to write my own, and perhaps even use them to help with Ember development.
I haven't had time yet (obviously) to really explore the possibilities, but I wanted to come up with at least one simple but useful example to get the ball rolling. So, here's my first bookmarklet ever:
Em -v
If you click the link, it will pop up an alert box telling you if the jQuery, Handlebars, Ember, and Ember-Data libraries are loaded in the current page, as well as the version of each. If you'd like to be able to use it on any page, click and drag the link to your toolbar. Now you're always one click away from knowing.
I also added a new Bookmarklets page to the navbar on EmberNoob.com. I'll add any new ones I come up with there. Feel free to post your own in the comments and I'll add them to the page.
Next up: Debugging features in JavaScript, Handlebars, and Ember
Introduction to Firebug from Neil Lee on Vimeo.
No comments:
Post a Comment