X11: Remove calls to XSelectInput

X11: Remove calls to XSelectInput

This CL removes all calls to XSelectInput, or XCreateWindow using
CWEventMask, from the browser process that uses the main X
display (ie, the one returned by gfx::GetXDisplay()).  Window event
selection will instead by managed by XWindowEventManager.

BUG=634084
Committed: https://crrev.com/6b2728b7cb80270903832d5f177613e03a8db009
Cr-Commit-Position: refs/heads/master@{#418634}

[Tom (Use chromium acct), 2016-09-07 22:45:24]

The CQ bit was checked by thomasanderson@google.com to run a CQ dry run

[commit-bot: I haz the power, 2016-09-07 22:45:59]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Tom (Use chromium acct), 2016-09-07 22:47:21]

thomasanderson@google.com changed reviewers:
+ derat@chromium.org, erg@chromium.org, sky@chromium.org

[Tom (Use chromium acct), 2016-09-07 22:47:22]

+erg for X11 stuff
+sky for OWNERS
+derat for FYI and review

[Tom (Use chromium acct), 2016-09-07 22:48:26]

Description was changed from

==========
X11: Remove calls to XSelectInput

This CL removes all calls to XSelectInput, or XCreateWindow using
CWOverrideRedirect, from the browser process that uses the main X
display (ie, the one returned by gfx::GetXDisplay()).  Window event
selection will instead by managed by XWindowEventManager.
==========

to

==========
X11: Remove calls to XSelectInput

This CL removes all calls to XSelectInput, or XCreateWindow using
CWEventMask, from the browser process that uses the main X
display (ie, the one returned by gfx::GetXDisplay()).  Window event
selection will instead by managed by XWindowEventManager.
==========

[Daniel Erat, 2016-09-07 22:58:36]

https://codereview.chromium.org/2319933002/diff/1/ui/aura/window_tree_host_x1...
File ui/aura/window_tree_host_x11.cc (right):

https://codereview.chromium.org/2319933002/diff/1/ui/aura/window_tree_host_x1...
ui/aura/window_tree_host_x11.cc:136: long event_mask = ButtonPressMask |
ButtonReleaseMask | FocusChangeMask |
mind moving this mask into a kEventMask constant in an anon namespace at the top
of the file, and having a second kInputEventMask constant as well? then
DisableInput can just use (kEventMask & ~kInputEventMask) and you don't need to
worry about someone updating the former but forgetting the latter.

https://codereview.chromium.org/2319933002/diff/1/ui/aura/window_tree_host_x1...
ui/aura/window_tree_host_x11.cc:477: xwindow_events_.reset(event_selector);
xwindow_events_.reset(new ui::XScopedEventSelector(...);

https://codereview.chromium.org/2319933002/diff/1/ui/aura/window_tree_host_x11.h
File ui/aura/window_tree_host_x11.h (right):

https://codereview.chromium.org/2319933002/diff/1/ui/aura/window_tree_host_x1...
ui/aura/window_tree_host_x11.h:56: void DisableInput();
nit: please add a brief comment describing what this does

[Tom (Use chromium acct), 2016-09-07 23:31:17]

https://codereview.chromium.org/2319933002/diff/1/ui/aura/window_tree_host_x1...
File ui/aura/window_tree_host_x11.cc (right):

https://codereview.chromium.org/2319933002/diff/1/ui/aura/window_tree_host_x1...
ui/aura/window_tree_host_x11.cc:477: xwindow_events_.reset(event_selector);
On 2016/09/07 22:58:36, Daniel Erat wrote:
> xwindow_events_.reset(new ui::XScopedEventSelector(...);

Done.

https://codereview.chromium.org/2319933002/diff/1/ui/aura/window_tree_host_x11.h
File ui/aura/window_tree_host_x11.h (right):

https://codereview.chromium.org/2319933002/diff/1/ui/aura/window_tree_host_x1...
ui/aura/window_tree_host_x11.h:56: void DisableInput();
On 2016/09/07 22:58:36, Daniel Erat wrote:
> nit: please add a brief comment describing what this does

Done.

[Daniel Erat, 2016-09-07 23:36:16]

https://codereview.chromium.org/2319933002/diff/20001/ui/aura/window_tree_hos...
File ui/aura/window_tree_host_x11.cc (right):

https://codereview.chromium.org/2319933002/diff/20001/ui/aura/window_tree_hos...
ui/aura/window_tree_host_x11.cc:477: xwindow_events_.reset(
is there a risk that we can miss some events between the point where the old
selector is destroyed and the new one is created? if so, it might be safer to
put the new selector in a local unique_ptr first and use .swap().

[sadrul, 2016-09-08 00:09:18]

sadrul@chromium.org changed reviewers:
+ sadrul@chromium.org

[sadrul, 2016-09-08 00:09:20]

https://codereview.chromium.org/2319933002/diff/20001/ui/aura/window_tree_hos...
File ui/aura/window_tree_host_x11.h (right):

https://codereview.chromium.org/2319933002/diff/20001/ui/aura/window_tree_hos...
ui/aura/window_tree_host_x11.h:57: void DisableInput();
Why do we want this?

[sadrul, 2016-09-08 00:09:38]

Can you add a BUG=?

[Tom (Use chromium acct), 2016-09-08 00:20:45]

Description was changed from

==========
X11: Remove calls to XSelectInput

This CL removes all calls to XSelectInput, or XCreateWindow using
CWEventMask, from the browser process that uses the main X
display (ie, the one returned by gfx::GetXDisplay()).  Window event
selection will instead by managed by XWindowEventManager.
==========

to

==========
X11: Remove calls to XSelectInput

This CL removes all calls to XSelectInput, or XCreateWindow using
CWEventMask, from the browser process that uses the main X
display (ie, the one returned by gfx::GetXDisplay()).  Window event
selection will instead by managed by XWindowEventManager.

BUG=634084
==========

[Daniel Erat, 2016-09-08 03:05:51]

https://codereview.chromium.org/2319933002/diff/20001/ui/aura/window_tree_hos...
File ui/aura/window_tree_host_x11.h (right):

https://codereview.chromium.org/2319933002/diff/20001/ui/aura/window_tree_hos...
ui/aura/window_tree_host_x11.h:57: void DisableInput();
On 2016/09/08 00:09:19, sadrul wrote:
> Why do we want this?

it looks like it's used by ash/display/mirror_window_controller.cc (i don't have
any knowledge about that code, though).

[Tom (Use chromium acct), 2016-09-08 17:15:15]

https://codereview.chromium.org/2319933002/diff/20001/ui/aura/window_tree_hos...
File ui/aura/window_tree_host_x11.cc (right):

https://codereview.chromium.org/2319933002/diff/20001/ui/aura/window_tree_hos...
ui/aura/window_tree_host_x11.cc:477: xwindow_events_.reset(
On 2016/09/07 23:36:16, Daniel Erat wrote:
> is there a risk that we can miss some events between the point where the old
> selector is destroyed and the new one is created? if so, it might be safer to
> put the new selector in a local unique_ptr first and use .swap().

The new XScopedEventSelector gets created before the old one is destroyed by the
reset(), so I don't think there's any possibility of losing events here.

[Daniel Erat, 2016-09-08 18:11:28]

lgtm if others are happy

https://codereview.chromium.org/2319933002/diff/20001/ui/aura/window_tree_hos...
File ui/aura/window_tree_host_x11.cc (right):

https://codereview.chromium.org/2319933002/diff/20001/ui/aura/window_tree_hos...
ui/aura/window_tree_host_x11.cc:477: xwindow_events_.reset(
On 2016/09/08 17:15:15, Tom Anderson wrote:
> On 2016/09/07 23:36:16, Daniel Erat wrote:
> > is there a risk that we can miss some events between the point where the old
> > selector is destroyed and the new one is created? if so, it might be safer
to
> > put the new selector in a local unique_ptr first and use .swap().
> 
> The new XScopedEventSelector gets created before the old one is destroyed by
the
> reset(), so I don't think there's any possibility of losing events here.

oh, duh. yes. :-)

[Elliot Glaysher, 2016-09-08 19:08:10]

owners lgtm

[Tom (Use chromium acct), 2016-09-09 02:18:31]

sky@ PTAL

[sky, 2016-09-09 15:26:46]

Rubber stamp LGTM

[Tom (Use chromium acct), 2016-09-09 23:00:56]

The CQ bit was checked by thomasanderson@google.com to run a CQ dry run

[commit-bot: I haz the power, 2016-09-09 23:01:17]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-10 00:39:46]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-10 00:39:47]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Tom (Use chromium acct), 2016-09-12 17:15:18]

The CQ bit was checked by thomasanderson@google.com

[Tom (Use chromium acct), 2016-09-12 17:15:18]

The patchset sent to the CQ was uploaded after l-g-t-m from erg@chromium.org,
derat@chromium.org, sky@chromium.org
Link to the patchset: https://codereview.chromium.org/2319933002/#ps60001
(title: "Fix RemoveMask")

[commit-bot: I haz the power, 2016-09-12 17:15:38]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-12 17:18:18]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-12 17:18:20]

Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Tom (Use chromium acct), 2016-09-12 17:21:48]

The CQ bit was checked by thomasanderson@google.com

[Tom (Use chromium acct), 2016-09-12 17:21:48]

The patchset sent to the CQ was uploaded after l-g-t-m from erg@chromium.org,
derat@chromium.org, sky@chromium.org
Link to the patchset: https://codereview.chromium.org/2319933002/#ps80001
(title: "Rebase")

[commit-bot: I haz the power, 2016-09-12 17:22:33]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-12 17:25:29]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-12 17:25:30]

Try jobs failed on following builders:
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Tom (Use chromium acct), 2016-09-12 18:12:29]

Patchset #5 (id:80001) has been deleted

[Tom (Use chromium acct), 2016-09-12 18:12:38]

Patchset #5 (id:100001) has been deleted

[Tom (Use chromium acct), 2016-09-12 18:15:24]

Patchset #4 (id:60001) has been deleted

[Tom (Use chromium acct), 2016-09-12 20:15:54]

The CQ bit was checked by thomasanderson@google.com to run a CQ dry run

[commit-bot: I haz the power, 2016-09-12 20:16:22]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-12 22:00:16]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-12 22:00:17]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Tom (Use chromium acct), 2016-09-13 19:47:20]

The CQ bit was checked by thomasanderson@google.com to run a CQ dry run

[commit-bot: I haz the power, 2016-09-13 19:48:04]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Tom (Use chromium acct), 2016-09-13 19:53:11]

derat@ please take another look.

Some tests were failing because aura::Env was getting destroyed after every
base::Singleton.  This meant some XScopedEventSelectors had a longer lifetime
than XWindowEventManager.  I decided just to get rid of XWindowEventManager
which actually simplified the code.

[commit-bot: I haz the power, 2016-09-13 21:05:46]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-13 21:05:48]

Dry run: This issue passed the CQ dry run.

[Daniel Erat, 2016-09-13 22:12:50]

On 2016/09/13 19:53:11, Tom Anderson wrote:
> derat@ please take another look.
> 
> Some tests were failing because aura::Env was getting destroyed after every
> base::Singleton.  This meant some XScopedEventSelectors had a longer lifetime
> than XWindowEventManager.  I decided just to get rid of XWindowEventManager
> which actually simplified the code.

making sure i understand the issue: so aura::Env was persisting longer than the
XWindowEventManager singleton, and aura::Env owned XScopedEventSelectors that
were outliving XWEM?

if you want to keep XWindowEventManager, you could probably make it hand out
weak_ptrs to XScopedEventSelectors, so they could check if it was still valid
before calling into it. i think i have a preference for doing that vs. keeping
all the logic in XScopedEventSelector with arbitrary instances updating the mask
on creation or destruction (even if you move the map into a singleton to get
around the no-non-POD-static-variables rule).

[Daniel Erat, 2016-09-13 22:15:36]

(i don't know why rietveld decided to not include my comment.)

https://codereview.chromium.org/2319933002/diff/140001/ui/base/x/x11_scoped_e...
File ui/base/x/x11_scoped_event_selector.cc (right):

https://codereview.chromium.org/2319933002/diff/140001/ui/base/x/x11_scoped_e...
ui/base/x/x11_scoped_event_selector.cc:17: std::map<XID,
std::unique_ptr<XScopedEventSelector::MultiMask>>
this isn't allowed, unfortunately: static variables must be POD types:
https://google.github.io/styleguide/cppguide.html#Static_and_Global_Variables

[Tom (Use chromium acct), 2016-09-14 01:09:40]

The CQ bit was checked by thomasanderson@google.com to run a CQ dry run

[Tom (Use chromium acct), 2016-09-14 01:10:02]

The CQ bit was unchecked by thomasanderson@google.com

[commit-bot: I haz the power, 2016-09-14 01:10:10]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Tom (Use chromium acct), 2016-09-14 01:11:21]

The CQ bit was checked by thomasanderson@google.com to run a CQ dry run

[commit-bot: I haz the power, 2016-09-14 01:11:57]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Tom (Use chromium acct), 2016-09-14 01:14:23]

No idea why it says "D" on ui/base/x/x11_window_event_manager.*, but the deltas
are still there

On 2016/09/13 22:12:50, Daniel Erat wrote:
> On 2016/09/13 19:53:11, Tom Anderson wrote:
> > derat@ please take another look.
> > 
> > Some tests were failing because aura::Env was getting destroyed after every
> > base::Singleton.  This meant some XScopedEventSelectors had a longer
lifetime
> > than XWindowEventManager.  I decided just to get rid of XWindowEventManager
> > which actually simplified the code.
> 
> making sure i understand the issue: so aura::Env was persisting longer than
the
> XWindowEventManager singleton, and aura::Env owned XScopedEventSelectors that
> were outliving XWEM?
> 

Yes, that's right

> if you want to keep XWindowEventManager, you could probably make it hand out
> weak_ptrs to XScopedEventSelectors, so they could check if it was still valid
> before calling into it. i think i have a preference for doing that vs. keeping
> all the logic in XScopedEventSelector with arbitrary instances updating the
mask
> on creation or destruction (even if you move the map into a singleton to get
> around the no-non-POD-static-variables rule).

Done.  I'm not sure if you meant std::weak_ptr or base::WeakPtr.  I tried the
former and it didn't really work, but the base version seemed to fit the
requirements well.

[commit-bot: I haz the power, 2016-09-14 03:41:34]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-14 03:41:35]

Dry run: This issue passed the CQ dry run.

[Daniel Erat, 2016-09-14 04:56:10]

thanks, this approach looks good! i mostly just have comments about comments.

https://codereview.chromium.org/2319933002/diff/160001/ui/base/x/x11_window_e...
File ui/base/x/x11_window_event_manager.cc (right):

https://codereview.chromium.org/2319933002/diff/160001/ui/base/x/x11_window_e...
ui/base/x/x11_window_event_manager.cc:79: for (const auto& mask_pair :
mask_map_)
i'd recommend adding a comment here like:

  // Clear events still requested by not-yet-deleted XScopedEventSelectors.

https://codereview.chromium.org/2319933002/diff/160001/ui/base/x/x11_window_e...
File ui/base/x/x11_window_event_manager.h (right):

https://codereview.chromium.org/2319933002/diff/160001/ui/base/x/x11_window_e...
ui/base/x/x11_window_event_manager.h:60: // Called whenever the mask
corresponding to window |xid| might have changed.
maybe add "Helper method called by SelectEvents and DeselectEvents whenever
..."?

https://codereview.chromium.org/2319933002/diff/160001/ui/base/x/x11_window_e...
ui/base/x/x11_window_event_manager.h:61: // Updates the event mask with respect
to the server, if necessary.
change this sentence to "Calls ChangeEventMask if necessary."?

https://codereview.chromium.org/2319933002/diff/160001/ui/base/x/x11_window_e...
ui/base/x/x11_window_event_manager.h:64: // Updates the event mask of |xid| to
|new_mask|, regardless of any
i was confused by this comment because it didn't make it clear that this is the
method that actually asks the X server to update the selected events (vs. e.g.
updating mask_map_, which it doesn't do). maybe this could instead be something
like "Asks the X server to set |xid|'s event mask to |new_mask|". renaming it to
SetEventMask also seems a bit clearer to me, but your call.

https://codereview.chromium.org/2319933002/diff/160001/ui/base/x/x11_window_e...
ui/base/x/x11_window_event_manager.h:66: void ChangeEventMask(XID xid, uint32_t
new_mask);
this method doesn't need to access any members, does it? if that's correct,
please make it be a standalone function in an anonymous namespace in the .cc
file.

[Tom (Use chromium acct), 2016-09-14 17:50:34]

The CQ bit was checked by thomasanderson@google.com to run a CQ dry run

[commit-bot: I haz the power, 2016-09-14 17:51:02]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Tom (Use chromium acct), 2016-09-14 17:51:08]

https://codereview.chromium.org/2319933002/diff/160001/ui/base/x/x11_window_e...
File ui/base/x/x11_window_event_manager.cc (right):

https://codereview.chromium.org/2319933002/diff/160001/ui/base/x/x11_window_e...
ui/base/x/x11_window_event_manager.cc:79: for (const auto& mask_pair :
mask_map_)
On 2016/09/14 04:56:09, Daniel Erat wrote:
> i'd recommend adding a comment here like:
> 
>   // Clear events still requested by not-yet-deleted XScopedEventSelectors.

Done.

https://codereview.chromium.org/2319933002/diff/160001/ui/base/x/x11_window_e...
File ui/base/x/x11_window_event_manager.h (right):

https://codereview.chromium.org/2319933002/diff/160001/ui/base/x/x11_window_e...
ui/base/x/x11_window_event_manager.h:60: // Called whenever the mask
corresponding to window |xid| might have changed.
On 2016/09/14 04:56:10, Daniel Erat wrote:
> maybe add "Helper method called by SelectEvents and DeselectEvents whenever
> ..."?

Done.

https://codereview.chromium.org/2319933002/diff/160001/ui/base/x/x11_window_e...
ui/base/x/x11_window_event_manager.h:61: // Updates the event mask with respect
to the server, if necessary.
On 2016/09/14 04:56:10, Daniel Erat wrote:
> change this sentence to "Calls ChangeEventMask if necessary."?

Done.

https://codereview.chromium.org/2319933002/diff/160001/ui/base/x/x11_window_e...
ui/base/x/x11_window_event_manager.h:64: // Updates the event mask of |xid| to
|new_mask|, regardless of any
On 2016/09/14 04:56:10, Daniel Erat wrote:
> i was confused by this comment because it didn't make it clear that this is
the
> method that actually asks the X server to update the selected events (vs. e.g.
> updating mask_map_, which it doesn't do). maybe this could instead be
something
> like "Asks the X server to set |xid|'s event mask to |new_mask|". renaming it
to
> SetEventMask also seems a bit clearer to me, but your call.

Done.

https://codereview.chromium.org/2319933002/diff/160001/ui/base/x/x11_window_e...
ui/base/x/x11_window_event_manager.h:66: void ChangeEventMask(XID xid, uint32_t
new_mask);
On 2016/09/14 04:56:10, Daniel Erat wrote:
> this method doesn't need to access any members, does it? if that's correct,
> please make it be a standalone function in an anonymous namespace in the .cc
> file.

Done.

[Daniel Erat, 2016-09-14 17:54:10]

thanks! lgtm with more comment nits

https://codereview.chromium.org/2319933002/diff/180001/ui/base/x/x11_window_e...
File ui/base/x/x11_window_event_manager.cc (right):

https://codereview.chromium.org/2319933002/diff/180001/ui/base/x/x11_window_e...
ui/base/x/x11_window_event_manager.cc:18: // Asks the X server to set |xid|'s
event mask to |new_mask|
nit: add trailing period

https://codereview.chromium.org/2319933002/diff/180001/ui/base/x/x11_window_e...
File ui/base/x/x11_window_event_manager.h (right):

https://codereview.chromium.org/2319933002/diff/180001/ui/base/x/x11_window_e...
ui/base/x/x11_window_event_manager.h:61: // corresponding to window |xid| might
have changed.  Calls ChangeEventMask if
nit: s/ChangeEventMask/SetEventMask/

[Tom (Use chromium acct), 2016-09-14 18:00:43]

thanks derat@

going to upload this patch set if the bots are happy

https://codereview.chromium.org/2319933002/diff/180001/ui/base/x/x11_window_e...
File ui/base/x/x11_window_event_manager.cc (right):

https://codereview.chromium.org/2319933002/diff/180001/ui/base/x/x11_window_e...
ui/base/x/x11_window_event_manager.cc:18: // Asks the X server to set |xid|'s
event mask to |new_mask|
On 2016/09/14 17:54:10, Daniel Erat wrote:
> nit: add trailing period

Done.

https://codereview.chromium.org/2319933002/diff/180001/ui/base/x/x11_window_e...
File ui/base/x/x11_window_event_manager.h (right):

https://codereview.chromium.org/2319933002/diff/180001/ui/base/x/x11_window_e...
ui/base/x/x11_window_event_manager.h:61: // corresponding to window |xid| might
have changed.  Calls ChangeEventMask if
On 2016/09/14 17:54:10, Daniel Erat wrote:
> nit: s/ChangeEventMask/SetEventMask/

Done.

[Tom (Use chromium acct), 2016-09-14 18:00:59]

The CQ bit was checked by thomasanderson@google.com to run a CQ dry run

[commit-bot: I haz the power, 2016-09-14 18:01:23]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-14 18:58:58]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-14 18:59:00]

Dry run: This issue passed the CQ dry run.

[Tom (Use chromium acct), 2016-09-14 19:03:00]

The CQ bit was checked by thomasanderson@google.com

[Tom (Use chromium acct), 2016-09-14 19:03:01]

The patchset sent to the CQ was uploaded after l-g-t-m from erg@chromium.org,
sky@chromium.org, derat@chromium.org
Link to the patchset: https://codereview.chromium.org/2319933002/#ps200001
(title: "Comments")

[commit-bot: I haz the power, 2016-09-14 19:03:48]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-14 19:13:17]

Description was changed from

==========
X11: Remove calls to XSelectInput

This CL removes all calls to XSelectInput, or XCreateWindow using
CWEventMask, from the browser process that uses the main X
display (ie, the one returned by gfx::GetXDisplay()).  Window event
selection will instead by managed by XWindowEventManager.

BUG=634084
==========

to

==========
X11: Remove calls to XSelectInput

This CL removes all calls to XSelectInput, or XCreateWindow using
CWEventMask, from the browser process that uses the main X
display (ie, the one returned by gfx::GetXDisplay()).  Window event
selection will instead by managed by XWindowEventManager.

BUG=634084
==========

[commit-bot: I haz the power, 2016-09-14 19:13:19]

Committed patchset #8 (id:200001)

[commit-bot: I haz the power, 2016-09-14 19:16:27]

Description was changed from

==========
X11: Remove calls to XSelectInput

This CL removes all calls to XSelectInput, or XCreateWindow using
CWEventMask, from the browser process that uses the main X
display (ie, the one returned by gfx::GetXDisplay()).  Window event
selection will instead by managed by XWindowEventManager.

BUG=634084
==========

to

==========
X11: Remove calls to XSelectInput

This CL removes all calls to XSelectInput, or XCreateWindow using
CWEventMask, from the browser process that uses the main X
display (ie, the one returned by gfx::GetXDisplay()).  Window event
selection will instead by managed by XWindowEventManager.

BUG=634084

Committed: https://crrev.com/6b2728b7cb80270903832d5f177613e03a8db009
Cr-Commit-Position: refs/heads/master@{#418634}
==========

[commit-bot: I haz the power, 2016-09-14 19:16:29]

Patchset 8 (id:??) landed as
https://crrev.com/6b2728b7cb80270903832d5f177613e03a8db009
Cr-Commit-Position: refs/heads/master@{#418634}