* Output of `node_modules/.bin/electron --version`: 2.0.0
* Operating System (Platform and Version): Windows 10

**Expected Behavior**
When I disable a window twice via `setEnabled(false)`, I expect the second disable to have no effect.

**Actual behavior**
The second disable is "queued" up, such that I am forced to enable the window twice to get back to normal.

**To Reproduce**
In the electronquickstart repo, in main.js' `createWindow()`, add these lines:

    mainWindow.setEnabled(false);
    mainWindow.setEnabled(false);
    mainWindow.setEnabled(true);

The window will be disabled when launched. 

You see the same issue if you do it in reverse:

    mainWindow.setEnabled(true);
    mainWindow.setEnabled(false); // this doesn't actually disable it, because the window was enabled from the getgo

If this is expected behavior, can the [docs](https://github.com/electron/electron/blob/master/docs/api/browser-window.md#winsetenabledenable) be updated to explain this behavior.
atom/browser/native_window_views.cc
return GetNativeWindow()->GetHost()->GetAcceleratedWidget();
}
gfx::Rect NativeWindowViews::ContentBoundsToWindowBounds(
    const gfx::Rect& bounds) const {
  if (!has_frame())
    return bounds;
  gfx::Rect window_bounds(bounds);
#if defined(OS_WIN)
  HWND hwnd = GetAcceleratedWidget();
  gfx::Rect dpi_bounds = display::win::ScreenWin::DIPToScreenRect(hwnd, bounds);
  window_bounds = display::win::ScreenWin::ScreenToDIPRect(
      hwnd,
      widget()->non_client_view()->GetWindowBoundsForClientBounds(dpi_bounds));
#endif
  if (root_view_->HasMenu() && root_view_->IsMenuBarVisible()) {
    int menu_bar_height = root_view_->GetMenuBarHeight();
    window_bounds.set_y(window_bounds.y() - menu_bar_height);
    window_bounds.set_height(window_bounds.height() + menu_bar_height);
  }
  return window_bounds;
}
gfx::Rect NativeWindowViews::WindowBoundsToContentBounds(