Ben Nadel
On User Experience (UX) Design, JavaScript, ColdFusion, Node.js, Life, and Love.
I am the chief technical officer at InVision App, Inc - a prototyping and collaboration platform for designers, built by designers. I also rock out in JavaScript and ColdFusion 24x7.
Meanwhile on Twitter
Loading latest tweet...
Ben Nadel at Scotch On The Rock (SOTR) 2010 (London) with:

jQuery Selectors - The Firebug Plugin Inserts A Hidden DIV Element

By Ben Nadel on

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>
  • <html>
  • <head>
  • <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.
  • $(function(){
  •  
  • // Get our testing DIV.
  • var div = $( "div" );
  •  
  •  
  • // Create and add a callback to your div's queue.
  • div.queue(
  • "testQueue",
  • function( next ){
  •  
  • // Simply log that the callback has fired.
  • console.log( "Queued item fired!" );
  •  
  • }
  • );
  •  
  •  
  • // Initiate the dequeuing.
  • div.dequeue( "testQueue" );
  •  
  • });
  •  
  • </script>
  • </head>
  • <body>
  •  
  • <h1>
  • Hidden FireBug DIV
  • </h1>
  •  
  • <div>
  • This is my defined div!
  • </div>
  •  
  • </body>
  • </html>

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.



Reader Comments

@Ray,

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 :)

@Karol,

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

Reply to this Comment

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.

Reply to this Comment

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.

Reply to this Comment

@Antonin,

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.

Reply to this Comment

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.

Reply to this Comment

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.

Reply to this Comment

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...

Reply to this Comment

I've found Firebug Lite in Chrome to do the trick (for the times when the Inspector isn't getting it done).

Reply to this Comment

@James,

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.

@Joe,

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.

@John,

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.

@Franky,

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.

@Acaz,

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.

@Jyoseph,

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

Reply to this Comment

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.

Example: http://i55.tinypic.com/24v1ik9.png

Reply to this Comment

@Jyoseph,

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.

Reply to this Comment

Post A Comment

You — Get Out Of My Dreams, Get Into My Comments
Live in the Now
Oops!
Comment Etiquette: Please do not post spam. Please keep the comments on-topic. Please do not post unrelated questions or large chunks of code. And, above all, please be nice to each other - we're trying to have a good conversation here.