Skip to main content
Ben Nadel at the jQuery Conference 2010 (Boston, MA) with: Alex Sexton
Ben Nadel at the jQuery Conference 2010 (Boston, MA) with: Alex Sexton ( @SlexAxton )

jQuery Selectors - The Firebug Plugin Inserts A Hidden DIV Element

Published in Comments (19)

Last night, I was testing out someone's jQuery queue() and dequeue() code and I had a bug that was just driving me crazy; no matter how simple I made my test, my queued callbacks kept firing twice. To give you some insight into how simple my code was, take a look at this demo:

<!DOCTYPE html>
	<title>Hidden FireBug DIV</title>
	<script type="text/javascript" src="jquery-1.4.2.js"></script>
	<script type="text/javascript">

		// When the DOM is ready, interact with DOM.

			// Get our testing DIV.
			var div = $( "div" );

			// Create and add a callback to your div's queue.
				function( next ){

					// Simply log that the callback has fired.
					console.log( "Queued item fired!" );


			// Initiate the dequeuing.
			div.dequeue( "testQueue" );



		Hidden FireBug DIV

		This is my defined div!


As you can see, there's almost nothing going on here; when the DOM is ready, I grab the one defined DIV element, queue up a single callback, and then initiate its dequeuing. I'd expect the single queued callback to execute and be done with it. When I run this code, however, I get the following console output in Firebug:

Firebug's Hidden DIV Causes Unexpected Behavior In jQuery Selectors.

As you can see, jQuery appears to be executing my queued callback twice.

This behavior had me stumped for a good 15 minutes. I tried everything from rewriting the entire demo to searching through the jQuery source code for a queuing bug. Then, finally, I had to the bright idea to double-check the jQuery collection on which I was acting. To do this, I went into the Firebug runtime command line and executed my jQuery selector:

$( "div" );

When I did this, I got the following output:

Firebug's Hidden DIV Causes Unexpected Behavior In jQuery Selectors.

As you can see, when we query the DOM for our "DIV" element, we get back our explicitly defined node plus a hidden one that is added by the Firebug plugin. What's odd is that I can't find that Firebug DIV anywhere in the markup. When I log its parent element, I get "HTML"; however, when I inspect the runtime markup, there is nothing but a HEAD and BODY tag contained within the HTML.

NOTE: This happens regardless of whether or not the Firebug console is actually open.

Normally, this would not be a problem since we very rarely query the DOM for an unqualified DIV element; however, when testing code, it's definitely going to be good to know that Firebug is adding its own hidden markup to the DOM tree.

Want to use code from this post? Check out the license.

Reader Comments



I use Chrome for a lot of stuff since it is so much nicer on RAM use and crash prevention. But for development, I just *love* Firebug :)


No problem - I was definitely banging my head against the wall for a few minutes there.


As far as I can tell from my understanding Firebug codebase.

Some nodes in the DOM are marked as hidden to Firebug UI (HTML panel, etc.). One example is this _firebugConsole, another is helper DIVs to visualize manual element picking for inspection.

Yes, it may interfere with your page/code in some rare cases. But there was probably no better way how to implement those features. Firebug guys are not code Firefox developers, so they just cannot simply add features/APIs they need for Firebug.


Not to mention that it probably helps them maintain the Firebug lite plugin to keep the features available for both the full firebug and for the lite at the same time.



Good point about the inspector DIVs as well; I never knew how they did that, but it makes sense. I'm not suggesting that Firebug change the way they do things - as you said, it's just a plugin, not a core Firefox feature. I'm just happy to know how it works so I can work around it.


I've had this happen before and it drove me a little nutty. (A client was reporting that a "promotion" wasn't added to their homepage, but their anti-virus software was rewriting the HTML.)

Here's what I do now:

Use the Web Developer Addon for Firefox, go to "View Source" and then "View Generated Source" and compare it with "View Source" results (or the actual source). It will allow you to determine if any markup is added or removed by other included third-party scripts, Firefox AddOns (not just Firebug; ie AdBlock, LinkAlert, etc) and anti-virus software proxies.


Plugins, Grease Monkey Scripts and other things can add to the dom as well. Unfortunately, you can't trust that your html hasn't been altered.


I've seen the div insert by the inspector feature so much... but this never complicated me...

i'm agree with ben nadel, i love firefox/firebug for development too...



Good thinking with the View Generated Source. I'm not sure I even knew that option existed. I think I may have used it before, but I always forget it.


I've definitely been on the "creating" end of GreaseMonkey scripts; but, I haven't used them in a while. If someone is gonna mess with the markup, there's only so much you can control.


I'll definitely check out the new FireBug. I love this tool; don't get me wrong - I'm not too concerned about the DIV. After all, I wouldn't normally query the DOM for unspecified tags.


Yeah, people have been telling me that Chrome dev tools are pretty good. I use Chrome a lot, but the dev tools just don't seem to be as easy to use. Maybe I just need to get over that learning curve.


Exactly - it's a rare case to ever query the DOM for simply, "div." Typically I am using a class or ID selector or a contextual selector.


I've used FBLite in IE for some success. I never thought of using in a browser that has its own development tools.


I was under the assumption that the Inspector did not show XHRs like Firebug does. Maybe it's in there, but I've never been able to find it in the inspector. The console in Firebug shows it clearly. That's really the only reason why I still occasionally use Firebug Lite in Chrome.




Yeah, I think it would be hard for a non-plugin to listen to HTTP requests. Unless there's an event you can bind to (which I don't think there is), I would think you'd have to be part of the core product/plugin-architecture to gain access to that.

I believe in love. I believe in compassion. I believe in human rights. I believe that we can afford to give more of these gifts to the world around us because it costs us nothing to be decent and kind and understanding. And, I want you to know that when you land on this site, you are accepted for who you are, no matter how you identify, what truths you live, or whatever kind of goofy shit makes you feel alive! Rock on with your bad self!
Ben Nadel