* 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
public:
  NativeWindowClientView(views::Widget* widget,
                         views::View* root_view,
                         NativeWindowViews* window)
      : views::ClientView(widget, root_view), window_(window) {}
  ~NativeWindowClientView() override = default;
  bool CanClose() override {
    window_->NotifyWindowCloseButtonClicked();
    return false;
  }
 private:
  NativeWindowViews* window_;
  DISALLOW_COPY_AND_ASSIGN(NativeWindowClientView);
};
}  
NativeWindowViews::NativeWindowViews(const mate::Dictionary& options,
                                     NativeWindow* parent)
    : NativeWindow(options, parent),
      root_view_(new RootView(this)),
      keyboard_event_handler_(new views::UnhandledKeyboardEventHandler) {
  options.Get(options::kTitle, &title_);
  bool menu_bar_autohide;
  if (options.Get(options::kAutoHideMenuBar, &menu_bar_autohide))