Issue metadata
Sign in to add a comment
|
If protocol-activated while minimized, Chromium renders as a blank window
Reported by
msiem...@microsoft.com,
Dec 13
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3639.0 Safari/537.36 Steps to reproduce the problem: 1. Set Chromium as the default web browser. 2. Launch Chromium and minimize its window. 3. Click on a hyperlink from an external application (e.g. a mail client) or directly run "www.netflix.com" from the Windows Run box (invoked via WIN+R). What is the expected behavior? What went wrong? Chromium window appears totally blank. DesktopWindowTreeHostWin toggles the window and compositor visibility when the window is minimized, but never toggles them back in this scenario because the protocol activation does not result in a WM_SYSCOMMAND getting sent to the window. Issue fixes itself if user minimizes the blank window and then restores it via the Windows taskbar. Did this work before? N/A Chrome version: 73.0.3639.0 Channel: dev OS Version: 10.0 Flash Version: (Disabled) Regression originated from this change: https://chromium-review.googlesource.com/c/chromium/src/+/1326621 A potential fix is to utilize WM_SIZE messages instead of WM_SYSCOMMAND to detect when HandleWindowMinimizedOrRestored should be invoked.
,
Dec 13
,
Dec 17
I put up a potential fix here: https://chromium-review.googlesource.com/c/chromium/src/+/1380343
,
Dec 18
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ec91bf64648b8b49a30d156a770f1ea89e69126b commit ec91bf64648b8b49a30d156a770f1ea89e69126b Author: Matt Siembor <msiembor@microsoft.com> Date: Tue Dec 18 19:02:50 2018 Fix visibility when activated from minimized HWNDMessageHandler was utilizing WM_SYSCOMMAND to determine when a window was being minimized or restored, but that window message is not guaranteed to arrive in all cases; for example, when the window is restored programmatically during a protocol activation scenario. This change alters how window minimized and restored state transitions are detected by utilizing more fundamental WM_SIZE messages. Added a test that validates expected behavior regardless of how the underlying window was minimized or restored. Bug: 914645 Change-Id: Ie775192a357f12921ec3ec6d7d3576c04270d4f0 Reviewed-on: https://chromium-review.googlesource.com/c/1380343 Reviewed-by: Scott Violet <sky@chromium.org> Commit-Queue: Scott Violet <sky@chromium.org> Cr-Commit-Position: refs/heads/master@{#617581} [modify] https://crrev.com/ec91bf64648b8b49a30d156a770f1ea89e69126b/AUTHORS [modify] https://crrev.com/ec91bf64648b8b49a30d156a770f1ea89e69126b/ui/views/widget/widget_hwnd_utils.cc [modify] https://crrev.com/ec91bf64648b8b49a30d156a770f1ea89e69126b/ui/views/widget/widget_hwnd_utils.h [modify] https://crrev.com/ec91bf64648b8b49a30d156a770f1ea89e69126b/ui/views/widget/widget_interactive_uitest.cc [modify] https://crrev.com/ec91bf64648b8b49a30d156a770f1ea89e69126b/ui/views/win/hwnd_message_handler.cc [modify] https://crrev.com/ec91bf64648b8b49a30d156a770f1ea89e69126b/ui/views/win/hwnd_message_handler.h
,
Dec 20
I am reproducing this issue using Chrome 72.0.3626.28 beta on Windows 10 v.1809. Will it be fixed for Chrome 72?
,
Dec 20
Requesting approval to merge this fix into M72. This also fixes crbug.com/914753 . I've tested the latest canary build and verified that the latter is fixed.
,
Dec 20
This bug requires manual review: M72 has already been promoted to the beta branch, so this requires manual review Please contact the milestone owner if you have questions. Owners: govind@(Android), kariahda@(iOS), djmm@(ChromeOS), abdulsyed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 26
Is this well tested and verified in Canary? Are we sure this is a safe merge to M72 and won't introduce any new regressions?
,
Dec 26
I tested it in canary, and it fixed this issue, and crbug.com/914753 . I believe it's relatively safe, though I'm not a module owner. The safest fix is to revert https://chromium-review.googlesource.com/c/chromium/src/+/1326621 on the M72 branch - that cl only affects code that's used for the native windows occlusion calculation feature, which is experiment controlled, and the experiment is only turned on for canary+dev. That CL caused another regression, crbug.com/912514 , which I have a proposed fix for, which would also need to be landed for M72, if the original CL wasn't reverted for M72.
,
Jan 3
thank you davidbienvenu@ +sky@ for his thoughts on the merge as well
,
Jan 7
I vote for revert on M72 as well.
,
Jan 7
Thx, sky@. I don't have commit privileges so I think I'll need someone else to do the revert. What's needed in the way of approvals?
,
Jan 7
Approving revert for https://chromium-review.googlesource.com/c/chromium/src/+/1326621 on M72 branch, 3626
,
Jan 8
I'm not aware of UI in gerrit that would make it trivial to revert only on the branch. I think you'll need to sync to the branch, revert locally, and the submit a patch from that. The alternative is to revert on trunk, and then merge that (there is UI in gerrit to merge the revert to a branch), but I'm not sure if the revert would cleanly apply on the branch now.
,
Jan 8
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f56eaea9df29c1f60cddbab4658c85f0a55375c8 Commit: f56eaea9df29c1f60cddbab4658c85f0a55375c8 Author: pbos@chromium.org Commiter: pbos@chromium.org Date: 2019-01-08 20:14:00 +0000 UTC Revert "Fix re-register win events when restoring minimized window." This reverts commit 04f0abb991b6ff444114dd775141fbbc04ad1403. TBR=sky@chromium.org Bug: 914645 Fix re-register win events when restoring minimized window. If there are no visible app windows, restoring app window wasn't re-registering events because OnWindowVisiblityChanged notification wasn't generated for root window. Add unit test for going from visible to hidden to occluded. Bug: 813093 Change-Id: I883dc5cc14f7f6c57d6d02f7cb996fedfb747dbc Reviewed-on: https://chromium-review.googlesource.com/c/1326621 Commit-Queue: David Bienvenu <davidbienvenu@chromium.org> Reviewed-by: Scott Violet <sky@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#611322} Reviewed-on: https://chromium-review.googlesource.com/c/1401386 Reviewed-by: Peter Boström <pbos@chromium.org> Cr-Commit-Position: refs/branch-heads/3626@{#613} Cr-Branched-From: d897fb137fbaaa9355c0c93124cc048824eb1e65-refs/heads/master@{#612437}
,
Jan 8
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f56eaea9df29c1f60cddbab4658c85f0a55375c8 commit f56eaea9df29c1f60cddbab4658c85f0a55375c8 Author: Peter Boström <pbos@chromium.org> Date: Tue Jan 08 20:14:00 2019 Revert "Fix re-register win events when restoring minimized window." This reverts commit 04f0abb991b6ff444114dd775141fbbc04ad1403. TBR=sky@chromium.org Bug: 914645 Fix re-register win events when restoring minimized window. If there are no visible app windows, restoring app window wasn't re-registering events because OnWindowVisiblityChanged notification wasn't generated for root window. Add unit test for going from visible to hidden to occluded. Bug: 813093 Change-Id: I883dc5cc14f7f6c57d6d02f7cb996fedfb747dbc Reviewed-on: https://chromium-review.googlesource.com/c/1326621 Commit-Queue: David Bienvenu <davidbienvenu@chromium.org> Reviewed-by: Scott Violet <sky@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#611322} Reviewed-on: https://chromium-review.googlesource.com/c/1401386 Reviewed-by: Peter Boström <pbos@chromium.org> Cr-Commit-Position: refs/branch-heads/3626@{#613} Cr-Branched-From: d897fb137fbaaa9355c0c93124cc048824eb1e65-refs/heads/master@{#612437} [modify] https://crrev.com/f56eaea9df29c1f60cddbab4658c85f0a55375c8/ui/aura/native_window_occlusion_tracker_win.cc [modify] https://crrev.com/f56eaea9df29c1f60cddbab4658c85f0a55375c8/ui/aura/native_window_occlusion_tracker_win.h [modify] https://crrev.com/f56eaea9df29c1f60cddbab4658c85f0a55375c8/ui/aura/native_window_occlusion_tracker_win_interactive_test.cc [modify] https://crrev.com/f56eaea9df29c1f60cddbab4658c85f0a55375c8/ui/views/widget/desktop_aura/desktop_window_tree_host_win.cc [modify] https://crrev.com/f56eaea9df29c1f60cddbab4658c85f0a55375c8/ui/views/widget/desktop_aura/desktop_window_tree_host_win.h [modify] https://crrev.com/f56eaea9df29c1f60cddbab4658c85f0a55375c8/ui/views/widget/native_widget_delegate.h [modify] https://crrev.com/f56eaea9df29c1f60cddbab4658c85f0a55375c8/ui/views/widget/widget.cc [modify] https://crrev.com/f56eaea9df29c1f60cddbab4658c85f0a55375c8/ui/views/widget/widget.h [modify] https://crrev.com/f56eaea9df29c1f60cddbab4658c85f0a55375c8/ui/views/win/hwnd_message_handler.cc [modify] https://crrev.com/f56eaea9df29c1f60cddbab4658c85f0a55375c8/ui/views/win/hwnd_message_handler_delegate.h
,
Jan 18
(4 days ago)
Issue 918804 has been merged into this issue. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by rafael.c...@microsoft.com
, Dec 13