Selenium 2 and the Django debug toolbar

One issue when using Selenium 2 with the Django debug toolbar is that Firefox on Windows attempts to use native code to mimic the user behavior. This process allows Selenium to model the way your users interact with your web app.  When you signal a click on an element, the first thing that happens is the element is first scrolled (element.ScrollToView()) before triggering the focus (via element.focus()).  For native implementations, Selenium also provides the X/Y coordinate of the element (using getClientRect() to get the absolute top/left positions) and then half the height/width of the element rather than just creating a trigger event on the actual element. If you're curious about the native implementation behavior, the code can be found in firefox-driver/js/utils.js and firefox-driver/extension/components/wrappedElement.js. You can download the Selenium source code from http://seleniumhq.org/download/source.html.

With Selenium 2's WebDriver implementation the screen that is opened will overlap the Django debug toolbar, causing your clicks to misfire if you have an element that is covering it. If you inspect the window.activeElement, you'll notice the focus is on the Django toolbar rather than the actual element you intended to click. You may notice this issue during your own testing since Selenium opens up a smaller window (1024px) and provides ample room for the toolbar to render without conflicting with your icons.

http://code.google.com/p/selenium/wiki/NativeEventsOnLinux

WebDriver offers user emulation via Javascript on all platforms, but on Windows "native events" are used. Specifically, sending keys to Firefox on Windows involves generating the Windows-specific events to make Firefox think it received user input. The same should be possible on Linux. As on Windows, it should be possible to run more than one instance of the Firefox driver at a time without the two interfering with each other. The final requirement, which is what makes native events on every platform challenging, is that the browser should not require focus in order to work properly --- it's useful to read email while the tests are running.

http://groups.google.com/group/webdriver/browse_thread/thread/34360a2dd3d8d214?pli=1

One way would be to use the 'djdt' cookie to disable the showing of the debug toolbar panel when your page loads, but Selenium v2.02b3 has a bug in using the add_cookie.  If you are using the Django debug toolbar with your app, you will be unable to set the 'djdt' cookie to be 'True' to prevent the toolbar from being rendered.

http://code.google.com/p/selenium/issues/detail?id=1526

The temporary solution appears to be to disable the Django toolbar, or to execute hide() on the toolbar.  You can also issue a window.resizeTo() to enlarge the width of the browser, but this command does not appear to work on SauceLabs.

selenium_browser = webdriver.Remote(desired_capabilities=current_env,command_executor="http://myhost:80/wd/hub"

selenium.execute_script('window.resizeTo(1600,768)'
selenium_browser.execute_script('$("#djDebug, #djShowToolBar, #djDebugToolbarHandle").hide();')

One other approach is to set the DEBUG_TOOLBAR_CONFIG inside your settings.py file (or put some logic to detect the requesting IP address inside INTERNAL_IPS)

DEBUG_TOOLBAR_CONFIG['SHOW_TOOLBAR_CALLBACK'] = lambda request: False