The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/72dc016bf78ba8512d9fb2c372eef8575510e710

commit 72dc016bf78ba8512d9fb2c372eef8575510e710
Author: dmurph <dmurph@chromium.org>
Date: Sat Sep 10 02:04:58 2016

Revert of Refactor X11ForeignWindowManager (patchset #8 id:130001 of https://codereview.chromium.org/2313033002/ )

Reason for revert:
Broke the build!

BUG= 645713 

Original issue's description:
> This CL renames XForeignWindowManager to XWindowEventManager since it will be
> used on local windows now.  Get rid of OnWindowDestroyed since this will be
> used by the XWindowCache for windows other than top-level windows as well.
> Finally, refactor the old Request implementation to use a Mask instead.
>
> This is needed by the XWindowCache which will select events on all windows, and
> therefore needs to know which masks we've already selected on Chrome windows.
>
> This will be the first in the line of 3 CLs.
> 1. Refactor X11ForeignWindowManager
> 2. Update Chrome code to use the XWindowManager instead of calling XSelectInput
> manually
> 3. Add a PRESUBMIT check to make sure CWEventMask, XSelectInput, or
> XCB_CW_EVENT_MASK is not added to new code.
>
> BUG= 634084 
>
> Committed: https://crrev.com/5c04e8aa6732cca81e518dacf06c48398426b415
> Cr-Commit-Position: refs/heads/master@{#417793}

TBR=erg@chromium.org,derat@chromium.org,thestig@chromium.org,thomasanderson@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 634084 

Review-Url: https://codereview.chromium.org/2326223002
Cr-Commit-Position: refs/heads/master@{#417798}

[modify] https://crrev.com/72dc016bf78ba8512d9fb2c372eef8575510e710/chrome/installer/linux/debian/expected_deps_ia32
[modify] https://crrev.com/72dc016bf78ba8512d9fb2c372eef8575510e710/chrome/installer/linux/debian/expected_deps_x64
[modify] https://crrev.com/72dc016bf78ba8512d9fb2c372eef8575510e710/chrome/installer/linux/rpm/expected_deps_i386
[modify] https://crrev.com/72dc016bf78ba8512d9fb2c372eef8575510e710/chrome/installer/linux/rpm/expected_deps_x86_64
[modify] https://crrev.com/72dc016bf78ba8512d9fb2c372eef8575510e710/ui/base/x/BUILD.gn
[modify] https://crrev.com/72dc016bf78ba8512d9fb2c372eef8575510e710/ui/base/x/selection_owner.cc
[modify] https://crrev.com/72dc016bf78ba8512d9fb2c372eef8575510e710/ui/base/x/selection_owner.h
[add] https://crrev.com/72dc016bf78ba8512d9fb2c372eef8575510e710/ui/base/x/x11_foreign_window_manager.cc
[add] https://crrev.com/72dc016bf78ba8512d9fb2c372eef8575510e710/ui/base/x/x11_foreign_window_manager.h
[delete] https://crrev.com/42300d9b64aa9eb133f236dd5a281bcd302bfc2a/ui/base/x/x11_window_event_manager.cc
[delete] https://crrev.com/42300d9b64aa9eb133f236dd5a281bcd302bfc2a/ui/base/x/x11_window_event_manager.h
[modify] https://crrev.com/72dc016bf78ba8512d9fb2c372eef8575510e710/ui/views/widget/desktop_aura/desktop_drag_drop_client_aurax11.cc
[modify] https://crrev.com/72dc016bf78ba8512d9fb2c372eef8575510e710/ui/views/widget/desktop_aura/x11_desktop_handler.cc

Please be specific, because the red build on https://build.chromium.org/p/chromium/builders/Win will eventually roll off the screen as new builds finish, and new red builds can appear. We are talking about https://build.chromium.org/p/chromium/builders/Win/builds/46961 right?

The compile log says:

FAILED: gen/v8/snapshot.cc snapshot_blob.bin 

and the reverted CL is Linux only. None of the "x11" files ever gets built on Windows.

This happened during my sheriff shift today as well:
https://uberchromegw.corp.google.com/i/chromium/builders/Win%20x64/builds/4166

[29298/44669] ACTION //v8:run_mksnapshot(//build/toolchain/win:x64)
FAILED: gen/v8/snapshot.cc snapshot_blob.bin 
C:/b/depot_tools/python276_bin/python.exe ../../v8/tools/run.py ./mksnapshot --startup_src gen/v8/snapshot.cc --random-seed 314159265 --startup_blob snapshot_blob.bin

The next build went green without any revert or fix going in (AFAICT).
It seems important to fix and get proper testing on this since it closes the tree (and Windows is the slowest platform to build at).

dmurph@: I assume you don't plan to work more on this since it's arguably not your CL's fault.

Looks like something might have made v8 snapshot generation on windows a bit flaky (crashing?). But the two rolls on the two errors are different and the flake didn't show up again.

It'd be nice to monitor how often this really happens. Another pity is that the output of mksnapshot seems to get swallowed (if there was any).

Labeling this for our stability sheriff triage.

Is there anything that still needs doing here?