* 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
widget()->CenterWindow(GetSize());
}
void NativeWindowViews::Invalidate() {
  widget()->SchedulePaintInRect(gfx::Rect(GetBounds().size()));
}
void NativeWindowViews::SetTitle(const std::string& title) {
  title_ = title;
  widget()->UpdateWindowTitle();
}
std::string NativeWindowViews::GetTitle() {
  return title_;
}
void NativeWindowViews::FlashFrame(bool flash) {
#if defined(OS_WIN)
  
  if (!flash) {
    FLASHWINFO fwi;
    fwi.cbSize = sizeof(fwi);
    fwi.hwnd = GetAcceleratedWidget();
    fwi.dwFlags = FLASHW_STOP;
    fwi.uCount = 0;
    FlashWindowEx(&fwi);
    return;
  }
#endif
  widget()->FlashFrame(flash);
}
void NativeWindowViews::SetSkipTaskbar(bool skip) {