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

commit 8075b262cc3d1d5f4e178d70e3bc5cf1c4c861e5
Author: Francois Doray <fdoray@chromium.org>
Date: Thu Mar 29 21:06:16 2018

Increase the number of times that occlusion can be recomputed by aura::WindowOcclusionTracker.

A change to the window tree can cause occlusion to be computed. If
a WindowDelegate changes the window tree when it is notified that
the occlusion of its window changed, occlusion has to be computed
again.

The number of times that occlusion can be recomputed before it has to
be stable was previously set to 2. This CL increases it to 3 to support
this case:

  Shos tab's WebContents ->
    Compute occlusion (1) ->
    Show modal dialog's WebContents (WebContentsModalDialogManager) ->
    Compute occlusion (2) ->
    Show modal dialog's RenderWidgetHostViewAura ->
    Compute occlusion (3) !!

Once showing or hiding a WebContents no longer involves calling
Show()/Hide() on the aura::Window of a RenderWidgetHostViewAura,
the value can be changed back to 2.

Bug:  827268 
Change-Id: I58131b4c3b3dfa71db3075cad21b7f01ddf1b997
Reviewed-on: https://chromium-review.googlesource.com/986742
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Commit-Queue: François Doray <fdoray@chromium.org>
Cr-Commit-Position: refs/heads/master@{#546953}
[modify] https://crrev.com/8075b262cc3d1d5f4e178d70e3bc5cf1c4c861e5/ui/aura/window_occlusion_tracker.cc
[modify] https://crrev.com/8075b262cc3d1d5f4e178d70e3bc5cf1c4c861e5/ui/aura/window_occlusion_tracker_unittest.cc

Low priority work, not actively working on this.