Hi, I will have a look. In the mean time can you provide output of chrome://gpu in both cases, i.e. just before good and just before bad. Thx.

As per comment # 1 attaching chrome://gpu for Both Good and Bad Builds

Deleted: chrome___gpuForBadBuild.pdf 92.9 KB

chrome___gpuForBadBuild.pdf 92.9 KB Download

Deleted: chrome___gpuForGoodBuild.pdf 90.9 KB

chrome___gpuForGoodBuild.pdf 90.9 KB Download

So I can confirm this is due to my patch, but indirectly.

Prior the patch the GL_VERSION string "3.3 (Core Profile) Mesa 10.1.3" was not parsed correctly. The Driver Vendor and Driver Version are extracted from this string. In "good" pdf you can see that "Driver Vendor" and "Driver Version" are empty. Whereas in "bad" pdf you can see that it is not empty and so parsed correctly. Which is what the CL is to.

Problem is that now that it is parsed correctly, then a gpu workaround is not applied, entry 173 in gpu_driver_bug_list_json.list. Because it hits the exception "driver_vendor": "Mesa". Result is that it now use a transparent visual.

At this point I think it could be a bug elsewhere in chromium or in mesa. I will try to reproduce it and with different drivers. But reverting the CL is not the right choice for now, it will just hide the real problem.

Quick update since the priority is level 1: I know what is the problem but I had not time to do a clean patch. The idea is to use a different X Visual depending on the ui::wm::WindowType of a DesktopWindowTreeHostX11.

So for TYPE_MENU we need to force using a 24 bits depth visual, but for TYPE_NORMAL or TYPE_DRAG we can use a 32 bits depth visual if available.

This require to improve ui::ChooseVisualForWindow to cache one visual per depth instead of one visual for all.

I plan to make a clean CL tomorrow.

Do you observe any Content Security Policy violations in the console of chrome://inspect/#apps when repeat the steps? 

Issue is reproducible on 54.0.2838.0 on Linux Ubuntu 14.04 as well using the following GPU configuration:

GL_VENDOR: Intel Open Source Technology Center
GL_RENDERER: Mesa DRI Intel(R) Ivybridge Desktop
GL_VERSION: 3.3 (Core Profile) Mesa 10.1.3

With respect to comment#5: No errors are seen in console of chrome://inspect/#apps. Only warning feedback.js:313 'webkitRequestAnimationFrame' is vendor-specific. Please use the standard 'requestAnimationFrame' instead. is seen.

I uploaded a patch here https://codereview.chromium.org/2268973004/

New patch is here https://codereview.chromium.org/2280433004/ . It has been lgtm already but I want to add some new tests first.

j.isorce@: Any update on this issue?

I am waiting for Sadrul's re-stamp because a the new test. He already reviewed it and made a few remarks that I addressed 1 week and 2 days ago. If it is urgent I can land it now, let me know. Otherwise let's wait one more day.

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

commit fa6da651020b236ab9dc8b4d9f1198dc1d1049ca
Author: j.isorce <j.isorce@samsung.com>
Date: Tue Sep 13 12:21:34 2016

Fix missing shadows for tooltip and menu

When using a transparent visual the window manager does not draw any
shadow by default (ex: 'Compiz' WM). Note that this default behavior
is WM dependent.

So the solution is to not use a transparent visual for any window
type which is not TYPE_DRAG and not TYPE_WINDOW.

Keep trying to use a transparent visual for type TYPE_DRAG or TYPE_WINDOW
because of  crbug.com/593256  and  crbug.com/369209 .

BUG= 640170 

R=piman@chromium.org, sadrul@chromium.org

TEST=python testing/xvfb.py ./out/build/ ./out/build/views_unittests --gtest_filter=*WidgetTest.Transparency*
./out/build/ui_base_unittests --gtest_filter=*ChooseVisualForWindow*

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

[modify] https://crrev.com/fa6da651020b236ab9dc8b4d9f1198dc1d1049ca/ui/base/BUILD.gn
[modify] https://crrev.com/fa6da651020b236ab9dc8b4d9f1198dc1d1049ca/ui/base/x/x11_util.cc
[add] https://crrev.com/fa6da651020b236ab9dc8b4d9f1198dc1d1049ca/ui/base/x/x11_util_unittest.cc
[modify] https://crrev.com/fa6da651020b236ab9dc8b4d9f1198dc1d1049ca/ui/views/BUILD.gn
[modify] https://crrev.com/fa6da651020b236ab9dc8b4d9f1198dc1d1049ca/ui/views/test/views_test_base.cc
[modify] https://crrev.com/fa6da651020b236ab9dc8b4d9f1198dc1d1049ca/ui/views/test/views_test_base.h
[modify] https://crrev.com/fa6da651020b236ab9dc8b4d9f1198dc1d1049ca/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc
[modify] https://crrev.com/fa6da651020b236ab9dc8b4d9f1198dc1d1049ca/ui/views/widget/widget_unittest.cc

Issue is still seen in 55.0.2861.0 dev of Ubuntu 14.04. Revision of 55.0.2861.0 --418732 is greater than fixed revision- 418221

@j.isorce: Please confirm which build contains the fix.

Deleted: Issue 640170.png 239 KB

	Issue 640170.png 239 KB View Download

Hi, I confirm that the tag you have used contain my fix so it should be working.

But I can only test the "overlay" case1 so when killing an extension. And I confirm that my patch fixes that case.

I cannot test the case2 "report an issue" because I can only build Chromium. If I try to build google chrome with the gn arg "is_chrome_branded = true", I get:
missing file chrome/browser/internal/transform_additional_modules_list.py

Can you confirm that case1 is working ? If yes but not case2 , please find another none working case that I can reproduce on Chromium. Or is there a way to enable that "report an issue" button from chrome://version for Chromium ?
Thx!

sc00335628@ please verify the above testcases mentioned.

This issue is marked as Release Block Stable, M54 early stable is scheduled on the first week of October, please plan a fix accordingly.

With response to comment#14: 

Case1- Worked fine. i.e; Killed an extension and reloaded. For those shadows are seen.

But Case-2 is not working fine. Issue is still seen with report an issue overlay.

Do not have any idea how to enable "report an issue" button for chromium.

Thnaks!
 

Hi, I hacked Chromium to open the "feedback" window (=case 2 above). And indeed it has TYPE_WINDOW. But it is a modal window.
So I made a fix to not use transparent visuals for that case too: https://codereview.chromium.org/2353783002/ .

I guess normal chrome browser windows do not get a shadow either? Is that what we want?

For the chrome browser windows the WM removes the shadow when "Use system title bar and borders" is disabled, for both 24 and 32 bits depth visuals.

The small attached patch enables the "report an issue/feedback" button and window on Chromium from the chrome://help page.

Deleted: 0001-chrome-enable-report-an-issue-button-and-feedback-wi.patch 2.3 KB

0001-chrome-enable-report-an-issue-button-and-feedback-wi.patch 2.3 KB Download

This issue is seen with some other overlays too.

Re-installed chrome latest 55.0.2873.0 dev >> Added https://chrome.google.com/webstore/detail/save-to-google-drive/gmbmikajjgmnabiglmofipeabaddhgne?utm_source=chrome-ntp-icon extension >> Right click on any link and select "Save link to Google Drive" and observe overlay.

Deleted: Expected_640170.png 127 KB

	Expected_640170.png 127 KB View Download

Deleted: Actual_640170.png 119 KB

	Actual_640170.png 119 KB View Download

This is marked as a stable blocker.  We're looking to ship that very soon, so please try to have this bug fixed no later than first week of October so that it can be merged to branch 2840 ASAP.

I think j.isorce@ is on vacation right now, so I'll take over this.

This CL is in the works, and I think it will fix the shadow issue:
https://codereview.chromium.org/2347383002/

I'll do a selective merge of just the part that fixes the shadows once it lands and the fix is verified.

Thanks for the fix. The CL is still under review, could you please expedite  the process.

Issue is still seen on the above specific GPU on Ubuntu 14.04 using 55.0.2976.0, seems the issue is yet to be committed in canary channel.Will verify once its available. 

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

commit 62ba78ffcdf525eb9ed640724e640fcf22fbbf87
Author: thomasanderson <thomasanderson@google.com>
Date: Sat Oct 01 02:03:42 2016

X11: Use a better visual for OpenGL

This CL delegates picking a transparent visual to the GPU
process.  Previously, the browser process did not have enough
information to decide which visual to use because it couldn't get
GL-specific visual information directly.  On Nvidia drivers,
picking the wrong transparent visual made the browser unusable.

Main changes introduced:
* Remove command line arguments window-depth, x11-visual-id, and
  disable_transparent_visuals.
* Remove driver bug DISABLE_TRANSPARENT_VISUALS
* GPU process picks an ARGB visual and a system visual (which may
  be different from the default visual) and sends it back in GPUInfo

BUG= 347333 , 369209 , 640170 , 640170 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

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

[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/content/browser/browser_main_loop.cc
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/content/browser/browser_main_loop.h
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/content/browser/gpu/gpu_internals_ui.cc
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/content/browser/gpu/gpu_process_host.cc
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/content/gpu/gpu_child_thread.cc
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/content/gpu/gpu_child_thread.h
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/content/gpu/gpu_main.cc
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/content/gpu/in_process_gpu_thread.cc
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/content/test/gpu/page_sets/gpu_process_tests.py
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/extensions/browser/api/app_window/app_window_apitest.cc
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/gpu/command_buffer/service/gl_context_virtual_unittest.cc
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/gpu/command_buffer/service/in_process_command_buffer.cc
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/gpu/config/gpu_driver_bug_list_json.cc
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/gpu/config/gpu_driver_bug_workaround_type.h
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/gpu/config/gpu_info.cc
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/gpu/config/gpu_info.h
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/gpu/config/gpu_info_collector.cc
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/gpu/ipc/common/gpu_info.mojom
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/gpu/ipc/common/gpu_info_struct_traits.cc
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/gpu/ipc/common/gpu_info_struct_traits.h
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/gpu/ipc/common/gpu_param_traits_macros.h
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/gpu/ipc/common/struct_traits_unittest.cc
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/gpu/ipc/service/gpu_channel_manager.cc
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/gpu/ipc/service/gpu_command_buffer_stub.cc
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/media/gpu/avda_picture_buffer_manager.cc
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/ui/base/BUILD.gn
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/ui/base/x/x11_util.cc
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/ui/base/x/x11_util_internal.h
[delete] https://crrev.com/69e8e7ecf033596588a92c65e0eb8e947fd7ec43/ui/base/x/x11_util_unittest.cc
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/ui/gfx/x/x11_switches.cc
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/ui/gfx/x/x11_switches.h
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/ui/gfx/x/x11_types.h
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/ui/gl/BUILD.gn
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/ui/gl/DEPS
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/ui/gl/gl_context.cc
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/ui/gl/gl_share_group.cc
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/ui/gl/gl_share_group.h
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/ui/gl/gl_surface.cc
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/ui/gl/gl_surface.h
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/ui/gl/gl_surface_egl.cc
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/ui/gl/gl_surface_glx.cc
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/ui/gl/gl_surface_glx.h
[add] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/ui/gl/gl_visual_picker_glx.cc
[add] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/ui/gl/gl_visual_picker_glx.h
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/ui/views/test/views_test_base.cc
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/ui/views/widget/desktop_aura/desktop_drag_drop_client_aurax11.cc
[modify] https://crrev.com/62ba78ffcdf525eb9ed640724e640fcf22fbbf87/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc

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

commit 47138793372b148d80ad28d13580ba44d35daf16
Author: thomasanderson <thomasanderson@google.com>
Date: Mon Oct 03 21:00:08 2016

X11: Fix broken DCHECK when no transparent visual is available

BUG= 347333 ,  369209 ,  640170 

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

[modify] https://crrev.com/47138793372b148d80ad28d13580ba44d35daf16/ui/base/x/x11_util.cc

Thanks for the fix, we will verify in today's canary. If all looks good, please request a merge to M54 ASAP.

ligimole@ Have you verified the fix?

I wouldn't be comfortable merging all of #12, #26, and #27 this late in.  Can we just disable transparent visuals on Mesa drivers and merge that to M54?

Checked the issue on 55.0.2882.0.

Case-1 mentioned in comment#14 is not working fine now[Still Reproducible]. Shadows are missing for killed extension overlays.

Case-2: Works fine. i.e; Now shadows are seen for feedback overlay. and 

Steps mentioned in comment#21 also works fine.

Deleted: Actual in 55.0.2882.0 223 KB

Actual in 55.0.2882.0 223 KB Download

thomasanderson@: Could you please take a look at C#30, Case-1.

Hi Thomas, I found that case-1 is created with "ToastContentsView::CreateWidget".
It has opacity views::Widget::InitParams::TRANSLUCENT_WINDOW for some reasons. Changing it to OPAQUE_WINDOW or INFER_OPACITY fixes the problem but not sure this is actually wanted on all cases. See file ui/message_center/views/toast_contents_view.cc .

#32 Thanks for the tip, please see https://codereview.chromium.org/2398203002/

ligimole@, I'd like to merge this into M54, do I need approval?
https://codereview.chromium.org/2399213003/

[Automated comment] DEPS changes referenced in bugdroid comments, needs manual review.

Approving for M54, the change https://codereview.chromium.org/2399213003/ looks very safe, and this is pretty visible.

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

commit 053bcc32b18fd80155ddc54d97fe98bea2c1b7a5
Author: thomasanderson <thomasanderson@google.com>
Date: Fri Oct 07 23:29:02 2016

Linux Aura: Fix shadows on frameless windows

https://codereview.chromium.org/2153373002 fixed an issue with detecting Mesa
drivers on Linux.  Transparent visuals were only enabled on Mesa, so that CL
exposed an existing problem of opaque windows being rendered without drop
shadows.  This CL restores the previous behavior for 54 without reverting that
CL, and without having to pull in the large CLs that actually fixed this issue
on master.

NOTRY=true
NOPRESUBMIT=true

BUG= 640170 

Review-Url: https://codereview.chromium.org/2399213003
Cr-Commit-Position: refs/branch-heads/2840@{#689}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/053bcc32b18fd80155ddc54d97fe98bea2c1b7a5/content/browser/browser_main_loop.cc

Removing the RBS label, since its already verified in canary.

Checked this issue[Comment #30] on 54.0.2840.59 beta and is working fine.

I can still reproduce this issue with notifications on ToT Linux.

Screenshot attached.

Deleted: notification-shadow.png 12.1 KB

	notification-shadow.png 12.1 KB View Download

This issue[Case-1 of comment#30] is still reproducible in  55.0.2883.28 beta and 56.0.2900.0 dev too.

@thomasanderson: Please confirm the issue

#41
Yes, shadows on notifications are still broken

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

commit 053bcc32b18fd80155ddc54d97fe98bea2c1b7a5
Author: thomasanderson <thomasanderson@google.com>
Date: Fri Oct 07 23:29:02 2016

Linux Aura: Fix shadows on frameless windows

https://codereview.chromium.org/2153373002 fixed an issue with detecting Mesa
drivers on Linux.  Transparent visuals were only enabled on Mesa, so that CL
exposed an existing problem of opaque windows being rendered without drop
shadows.  This CL restores the previous behavior for 54 without reverting that
CL, and without having to pull in the large CLs that actually fixed this issue
on master.

NOTRY=true
NOPRESUBMIT=true

BUG= 640170 

Review-Url: https://codereview.chromium.org/2399213003
Cr-Commit-Position: refs/branch-heads/2840@{#689}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/053bcc32b18fd80155ddc54d97fe98bea2c1b7a5/content/browser/browser_main_loop.cc

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

commit a6214bca4ab92af916ff7f5a3f53bc5f2635fa91
Author: thomasanderson <thomasanderson@chromium.org>
Date: Mon Nov 28 21:35:39 2016

Linux Aura: Fix overlay shadows on notifications

>Linux Aura got support for translucent windows in CL:
>https://chromium.googlesource.com/chromium/src.git/+/62ba78ffcdf525eb9ed640724e640fcf22fbbf87
>
>Some Chrome widgets used a TRANSLUCENT_WINDOW opacity for widgets that
>fade in or out, but that don't actually have an alpha mask.  This was
>to support a limitation on MS Windows where windows must be
>translucent to fade.
>
>However, most Linux window managers only draw shadows on opaque
>windows: that is, windows that do not have an alpha channel.  Windows
>that fade in or out may still have shadows since opacity is set as a
>property of the toplevel window.
>
>Therefore, the solution is to use INFER_OPACITY for fading widgets so
>it will work across platforms.  TRANSLUCENT_WINDOW should only be used
>on widgets that have alpha masks.
>
>BUG= 640170 
>
>R=sky@chromium.org
>
>patch from issue 2398203002 at patchset 40001
>(http://crrev.com/2398203002#ps40001)
>

NOPRESUBMIT=true
NOTRY=true
BUG= 640170 
TBR=sky@chromium.org

Review-Url: https://codereview.chromium.org/2540463002
Cr-Commit-Position: refs/branch-heads/2924@{#130}
Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059}

[modify] https://crrev.com/a6214bca4ab92af916ff7f5a3f53bc5f2635fa91/ui/message_center/views/toast_contents_view.cc
[modify] https://crrev.com/a6214bca4ab92af916ff7f5a3f53bc5f2635fa91/ui/views/widget/widget.h

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

commit 59c8df38a1f3f087e58f3318233c2f4bc01af0d9
Author: thomasanderson <thomasanderson@chromium.org>
Date: Mon Nov 28 21:40:00 2016

Linux Aura: Fix overlay shadows on notifications

>Linux Aura got support for translucent windows in CL:
>https://chromium.googlesource.com/chromium/src.git/+/62ba78ffcdf525eb9ed640724e640fcf22fbbf87
>
>Some Chrome widgets used a TRANSLUCENT_WINDOW opacity for widgets that
>fade in or out, but that don't actually have an alpha mask.  This was
>to support a limitation on MS Windows where windows must be
>translucent to fade.
>
>However, most Linux window managers only draw shadows on opaque
>windows: that is, windows that do not have an alpha channel.  Windows
>that fade in or out may still have shadows since opacity is set as a
>property of the toplevel window.
>
>Therefore, the solution is to use INFER_OPACITY for fading widgets so
>it will work across platforms.  TRANSLUCENT_WINDOW should only be used
>on widgets that have alpha masks.
>
>BUG= 640170 
>
>R=sky@chromium.org
>
>patch from issue 2398203002 at patchset 40001
>(http://crrev.com/2398203002#ps40001)
>

NOTRY=true
NOPRESUBMIT=true
BUG= 640170 
TBR=sky@chromium.org

Review-Url: https://codereview.chromium.org/2537603002
Cr-Commit-Position: refs/branch-heads/2883@{#670}
Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768}

[modify] https://crrev.com/59c8df38a1f3f087e58f3318233c2f4bc01af0d9/ui/message_center/views/toast_contents_view.cc
[modify] https://crrev.com/59c8df38a1f3f087e58f3318233c2f4bc01af0d9/ui/views/widget/widget.h

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

commit e35682c33f0e363b498b04d816c86bb16d1f5014
Author: thomasanderson <thomasanderson@google.com>
Date: Mon Nov 28 22:40:36 2016

Linux Aura: Fix overlay shadows on notifications

Linux Aura got support for translucent windows in CL:
https://chromium.googlesource.com/chromium/src.git/+/62ba78ffcdf525eb9ed640724e640fcf22fbbf87

Some Chrome widgets used a TRANSLUCENT_WINDOW opacity for widgets that fade in
or out, but that don't actually have an alpha mask.  This was to support a
limitation on MS Windows where windows must be translucent to fade.

However, most Linux window managers only draw shadows on opaque windows: that is,
windows that do not have an alpha channel.  Windows that fade in or out may still
have shadows since opacity is set as a property of the toplevel window.

Therefore, the solution is to use INFER_OPACITY for fading widgets so it will
work across platforms.  TRANSLUCENT_WINDOW should only be used on widgets that
have alpha masks.

BUG= 640170 

R=sky@chromium.org

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

[modify] https://crrev.com/e35682c33f0e363b498b04d816c86bb16d1f5014/ui/message_center/views/toast_contents_view.cc
[modify] https://crrev.com/e35682c33f0e363b498b04d816c86bb16d1f5014/ui/views/widget/widget.h

Should be fixed on ToT and M56 and M55.  Can anyone verify?

Verified the issue on Ubuntu 14.04 using chrome latest Dev M55-55.0.2883.70 by following steps mentioned in the original comment. Observed the overlay is displayed as expected even after reinstalling the chrome. Hence adding TE-Verified label.

Deleted: 640170.ogv 10.7 MB

	640170.ogv 10.7 MB View Download

Checked the issue on 56.0.2924.10 dev by reinstalling/upgrading with all cases mentioned and is no longer reproducible.

Hence adding TE-Verified labels