Issue metadata
Sign in to add a comment
|
Maximized Chrome does not start with maximized window decorations
Reported by
ivan@ludios.org,
Sep 9
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.81 Safari/537.36 Steps to reproduce the problem: 1. Start google-chrome or google-chrome-unstable (70.0.3538.9) on a Linux with xfce4 (tested: Debian 9.5, xfce 4.12.1) 2. Maximize the window and wait a bit 3. Quit Chrome and start Chrome (repeat 2-3 until Chrome actually remembers to start maximized) 4. Observe that even though Chrome covers the screen, Chrome's window decorations do not reflect the maximized state, showing the unmaximized window decorations (taller tab strip) One can then "really" maximize the window by moving it away from the top, then double-clicking the tab bar. What is the expected behavior? What went wrong? Maximized window did not start with maximized window decorations (shorter tab bar) Did this work before? Yes 68 Chrome version: 69.0.3497.81 Channel: stable OS Version: Debian 9.5 Flash Version: This affects both the GTK and Classic themes. I can repro this with a clean profile.
,
Sep 10
ivan@ Thanks for the issue. Tested this issue on Ubuntu 14.04 on the reported version 69.0.3497.81 and unable to reproduce the issue by following the below steps. 1. Launched google-chrome (69.0.3497.81) and the window launched in Maximized state. 2. Quit chrome and re-launched Chrome. 3. Could observe that Chrome re-launches by covering the screen and Chrome's window decorations reflect the maximized state. As this issue is reported on Debian 9.5, adding 'TE-NeedsTriageFromHYD' label and requesting InHouse team to look into the issue and help in further triaging. Thanks..
,
Sep 10
Bisect results: You are probably looking for a change made after 571551 (known good), but no later than 571556 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/1a4c4c2b5ed9eedb38f2441f880d6e01120e49b1..5419eec07c54da283ff617102091b7b5728735a8 so it must be https://chromium.googlesource.com/chromium/src/+/270b2bfa01f4eadfe6f25673767a3357158e0ef9
,
Sep 10
To clarify the buggy behavior: with xfce4 on Debian 9.5, after that change, Chrome _never_ starts with the maximized window decorations here (tested on both a 96 dpi and 165 dpi desktop).
,
Sep 11
As per comment #3, assigning it to suspect CL owner thomasanderson@
,
Sep 11
Able to reproduce the issue.
,
Sep 12
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d83ba0d6bbac37dff3db86b6698073e9e9744b37 commit d83ba0d6bbac37dff3db86b6698073e9e9744b37 Author: Tom Anderson <thomasanderson@chromium.org> Date: Wed Sep 12 16:57:11 2018 [X11] Atomically set the horizontal and vertical maximized state The EWMH spec implements maximized windows with two window state atoms: _NET_WM_STATE_MAXIMIZED_{VERT,HORZ}. This gives windows flexibility to be only horizontally maximized or only vertically maximized, but the common case is to set both atoms. Some window managers like xfwm4 do not implement "only horizontal" or "only vertical" maximized states, so it will ignore requests to set these states individually. Instead, apps must set both atoms atomically to maximize the window. Window state atoms are set in pairs. In some cases, Chromium used to maximize windows by setting (_NET_WM_STATE_MAXIMIZED_VERT, None) (_NET_WM_STATE_MAXIMIZED_HORZ, None). This CL changes the request to (_NET_WM_STATE_MAXIMIZED_VERT, _NET_WM_STATE_MAXIMIZED_HORZ). [1] https://specifications.freedesktop.org/wm-spec/1.3/ar01s05.html#idm140238712324208 BUG= 882258 R=sky Change-Id: Id6f4668c4a372dd2f58adc56c9a257168ae37555 Reviewed-on: https://chromium-review.googlesource.com/1220714 Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org> Commit-Queue: Thomas Anderson <thomasanderson@chromium.org> Cr-Commit-Position: refs/heads/master@{#590724} [modify] https://crrev.com/d83ba0d6bbac37dff3db86b6698073e9e9744b37/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc [modify] https://crrev.com/d83ba0d6bbac37dff3db86b6698073e9e9744b37/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.h
,
Sep 13
I am also observing this issue with xfce on ubuntu.
,
Sep 14
I have also noticed this in MacOS (Chrome, Version 69.0.3497.92 (Official Build) (64-bit)) and in ChromeOS (69 Beta) using the API to open new windows:
To Reproduce:
```
return new Promise((resolve, reject) => {
chrome.windows.create({
state: 'maximized',
incognito: true
}, (thisWindow) => {
const tab = thisWindow.tabs[0]
resolve(tab)
})
})
```
Workaround
```
return new Promise((resolve, reject) => {
chrome.windows.create({
state: 'normal',
focused: true,
incognito: true
}, (thisWindow) => {
const tab = thisWindow.tabs[0]
resolve(tab)
})
})
```
,
Sep 14
Since TE doesn't able to repro this issue. ivan@ Could you please verify this fix in dev #71.0.3551.3 and let us know your observations.
,
Sep 14
I just tested 71.0.3553.0 on Debian 9.5 and it is maximized on start. Thanks for the fix! Note for other testers: there's another bug (?) that can superficially resemble this one: Chrome needs to be running for at least a few seconds to remember to start maximized next time.
,
Sep 14
> Note for other testers: there's another bug (?) that can superficially resemble this one: Chrome needs to be running for at least a few seconds to remember to start maximized next time. Working on that one right now. I'll close this bug once that's fixed.
,
Sep 19
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d4d1506d47713470d7b3acad4da9a7f3181fbae0 commit d4d1506d47713470d7b3acad4da9a7f3181fbae0 Author: Tom Anderson <thomasanderson@chromium.org> Date: Wed Sep 19 22:14:03 2018 [X11] Don't clear WM state bits when a window is unmapped _NET_WM_STATE holds the window state which may be eg: maximized, fullscreen, minimized, etc. In shutdown, Chrome queries this state so that it can restore browser windows to the correct state on the next launch. The problem is that Chrome queries this state (hundreds of times, in fact) after the window has already gone away. The EWMH spec requires window managers to delete the _NET_WM_STATE property when a window is unmapped [1], so the state that Chrome was getting was invalid. This CL saves the state when a window becomes unmapped, and includes some small cleanups. [1] https://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#idm140130317598336 BUG= 882258 R=sky Change-Id: Iacc43563cd54ade77ac83a580ed24434b6802c91 Reviewed-on: https://chromium-review.googlesource.com/1226645 Commit-Queue: Thomas Anderson <thomasanderson@chromium.org> Reviewed-by: Scott Violet <sky@chromium.org> Cr-Commit-Position: refs/heads/master@{#592570} [modify] https://crrev.com/d4d1506d47713470d7b3acad4da9a7f3181fbae0/chrome/browser/ui/libgtkui/gtk_ui.cc [modify] https://crrev.com/d4d1506d47713470d7b3acad4da9a7f3181fbae0/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc [modify] https://crrev.com/d4d1506d47713470d7b3acad4da9a7f3181fbae0/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.h
,
Sep 19
Requesting merge for d83ba0d6bbac37dff3db86b6698073e9e9744b37 and d4d1506d47713470d7b3acad4da9a7f3181fbae0
,
Sep 20
This bug requires manual review: M70 has already been promoted to the beta branch, so this requires manual review Please contact the milestone owner if you have questions. Owners: benmason@(Android), kariahda@(iOS), geohsu@(ChromeOS), abdulsyed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 21
,
Sep 21
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1a58d4ea4163afd30e85b7784223595a4766e512 commit 1a58d4ea4163afd30e85b7784223595a4766e512 Author: Tarun Bansal <tbansal@chromium.org> Date: Fri Sep 21 21:11:49 2018 Revert "[X11] Don't clear WM state bits when a window is unmapped" This reverts commit d4d1506d47713470d7b3acad4da9a7f3181fbae0. Reason for revert: Hitting the DCHECK on Chromium startup. crbug.com/888087 Original change's description: > [X11] Don't clear WM state bits when a window is unmapped > > _NET_WM_STATE holds the window state which may be eg: maximized, fullscreen, > minimized, etc. In shutdown, Chrome queries this state so that it can restore > browser windows to the correct state on the next launch. The problem is that > Chrome queries this state (hundreds of times, in fact) after the window has > already gone away. The EWMH spec requires window managers to delete the > _NET_WM_STATE property when a window is unmapped [1], so the state that Chrome > was getting was invalid. > > This CL saves the state when a window becomes unmapped, and includes some small > cleanups. > > [1] https://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#idm140130317598336 > > BUG= 882258 > R=sky > > Change-Id: Iacc43563cd54ade77ac83a580ed24434b6802c91 > Reviewed-on: https://chromium-review.googlesource.com/1226645 > Commit-Queue: Thomas Anderson <thomasanderson@chromium.org> > Reviewed-by: Scott Violet <sky@chromium.org> > Cr-Commit-Position: refs/heads/master@{#592570} TBR=sky@chromium.org,thomasanderson@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: 882258 , 888087 Change-Id: Iac2776b33ec366235e233878dcdbfd8530e2ea0b Reviewed-on: https://chromium-review.googlesource.com/1239355 Commit-Queue: Tarun Bansal <tbansal@chromium.org> Commit-Queue: Thomas Anderson <thomasanderson@chromium.org> Reviewed-by: Thomas Anderson <thomasanderson@chromium.org> Reviewed-by: Tarun Bansal <tbansal@chromium.org> Cr-Commit-Position: refs/heads/master@{#593331} [modify] https://crrev.com/1a58d4ea4163afd30e85b7784223595a4766e512/chrome/browser/ui/libgtkui/gtk_ui.cc [modify] https://crrev.com/1a58d4ea4163afd30e85b7784223595a4766e512/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc [modify] https://crrev.com/1a58d4ea4163afd30e85b7784223595a4766e512/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.h
,
Sep 21
,
Sep 24
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/02370c73936726c387f74cfbd5796f1667ae8a65 commit 02370c73936726c387f74cfbd5796f1667ae8a65 Author: Tom Anderson <thomasanderson@chromium.org> Date: Mon Sep 24 22:15:28 2018 Reland "[X11] Don't clear WM state bits when a window is unmapped" This is a reland of d4d1506d47713470d7b3acad4da9a7f3181fbae0 Original change's description: > [X11] Don't clear WM state bits when a window is unmapped > > _NET_WM_STATE holds the window state which may be eg: maximized, fullscreen, > minimized, etc. In shutdown, Chrome queries this state so that it can restore > browser windows to the correct state on the next launch. The problem is that > Chrome queries this state (hundreds of times, in fact) after the window has > already gone away. The EWMH spec requires window managers to delete the > _NET_WM_STATE property when a window is unmapped [1], so the state that Chrome > was getting was invalid. > > This CL saves the state when a window becomes unmapped, and includes some small > cleanups. > > [1] https://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#idm140130317598336 > > BUG= 882258 > R=sky > > Change-Id: Iacc43563cd54ade77ac83a580ed24434b6802c91 > Reviewed-on: https://chromium-review.googlesource.com/1226645 > Commit-Queue: Thomas Anderson <thomasanderson@chromium.org> > Reviewed-by: Scott Violet <sky@chromium.org> > Cr-Commit-Position: refs/heads/master@{#592570} Bug: 882258 Change-Id: I0b68e0d386949f3fe458381a640af7358b7c2269 Reviewed-on: https://chromium-review.googlesource.com/1239252 Commit-Queue: Thomas Anderson <thomasanderson@chromium.org> Reviewed-by: Scott Violet <sky@chromium.org> Cr-Commit-Position: refs/heads/master@{#593711} [modify] https://crrev.com/02370c73936726c387f74cfbd5796f1667ae8a65/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc [modify] https://crrev.com/02370c73936726c387f74cfbd5796f1667ae8a65/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.h
,
Sep 24
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1a8e44ac04c94771ff8f054ba2400bab8d201374 commit 1a8e44ac04c94771ff8f054ba2400bab8d201374 Author: Tom Anderson <thomasanderson@chromium.org> Date: Mon Sep 24 22:53:55 2018 [Merge to M70] [X11] Atomically set the horizontal and vertical maximized state > The EWMH spec implements maximized windows with two window state atoms: > _NET_WM_STATE_MAXIMIZED_{VERT,HORZ}. This gives windows flexibility to be only > horizontally maximized or only vertically maximized, but the common case is to > set both atoms. Some window managers like xfwm4 do not implement "only > horizontal" or "only vertical" maximized states, so it will ignore requests to > set these states individually. Instead, apps must set both atoms atomically to > maximize the window. > > Window state atoms are set in pairs. In some cases, Chromium used to maximize > windows by setting > (_NET_WM_STATE_MAXIMIZED_VERT, None) > (_NET_WM_STATE_MAXIMIZED_HORZ, None). > This CL changes the request to > (_NET_WM_STATE_MAXIMIZED_VERT, _NET_WM_STATE_MAXIMIZED_HORZ). > > [1] https://specifications.freedesktop.org/wm-spec/1.3/ar01s05.html#idm140238712324208 > > BUG= 882258 > R=sky > > Change-Id: Id6f4668c4a372dd2f58adc56c9a257168ae37555 > Reviewed-on: https://chromium-review.googlesource.com/1220714 > Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org> > Commit-Queue: Thomas Anderson <thomasanderson@chromium.org> > Cr-Commit-Position: refs/heads/master@{#590724} BUG= 882258 TBR=sky NOTRY=true NOPRESUBMIT=true NOTREECHECKS=true Change-Id: I4226b76547da413441b9a4ff324ee692d0f55597 Reviewed-on: https://chromium-review.googlesource.com/1241953 Reviewed-by: Thomas Anderson <thomasanderson@chromium.org> Cr-Commit-Position: refs/branch-heads/3538@{#629} Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811} [modify] https://crrev.com/1a8e44ac04c94771ff8f054ba2400bab8d201374/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc [modify] https://crrev.com/1a8e44ac04c94771ff8f054ba2400bab8d201374/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.h
,
Sep 24
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1a8e44ac04c94771ff8f054ba2400bab8d201374 Commit: 1a8e44ac04c94771ff8f054ba2400bab8d201374 Author: thomasanderson@chromium.org Commiter: thomasanderson@chromium.org Date: 2018-09-24 22:53:55 +0000 UTC [Merge to M70] [X11] Atomically set the horizontal and vertical maximized state > The EWMH spec implements maximized windows with two window state atoms: > _NET_WM_STATE_MAXIMIZED_{VERT,HORZ}. This gives windows flexibility to be only > horizontally maximized or only vertically maximized, but the common case is to > set both atoms. Some window managers like xfwm4 do not implement "only > horizontal" or "only vertical" maximized states, so it will ignore requests to > set these states individually. Instead, apps must set both atoms atomically to > maximize the window. > > Window state atoms are set in pairs. In some cases, Chromium used to maximize > windows by setting > (_NET_WM_STATE_MAXIMIZED_VERT, None) > (_NET_WM_STATE_MAXIMIZED_HORZ, None). > This CL changes the request to > (_NET_WM_STATE_MAXIMIZED_VERT, _NET_WM_STATE_MAXIMIZED_HORZ). > > [1] https://specifications.freedesktop.org/wm-spec/1.3/ar01s05.html#idm140238712324208 > > BUG= 882258 > R=sky > > Change-Id: Id6f4668c4a372dd2f58adc56c9a257168ae37555 > Reviewed-on: https://chromium-review.googlesource.com/1220714 > Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org> > Commit-Queue: Thomas Anderson <thomasanderson@chromium.org> > Cr-Commit-Position: refs/heads/master@{#590724} BUG= 882258 TBR=sky NOTRY=true NOPRESUBMIT=true NOTREECHECKS=true Change-Id: I4226b76547da413441b9a4ff324ee692d0f55597 Reviewed-on: https://chromium-review.googlesource.com/1241953 Reviewed-by: Thomas Anderson <thomasanderson@chromium.org> Cr-Commit-Position: refs/branch-heads/3538@{#629} Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}
,
Sep 24
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1c82639f9f784c04843f22f3511f7ab68e5ec6c0 commit 1c82639f9f784c04843f22f3511f7ab68e5ec6c0 Author: Tom Anderson <thomasanderson@chromium.org> Date: Mon Sep 24 22:59:34 2018 [Merge to M70] Reland "[X11] Don't clear WM state bits when a window is unmapped" > This is a reland of d4d1506d47713470d7b3acad4da9a7f3181fbae0 > > Original change's description: > > [X11] Don't clear WM state bits when a window is unmapped > > > > _NET_WM_STATE holds the window state which may be eg: maximized, fullscreen, > > minimized, etc. In shutdown, Chrome queries this state so that it can restore > > browser windows to the correct state on the next launch. The problem is that > > Chrome queries this state (hundreds of times, in fact) after the window has > > already gone away. The EWMH spec requires window managers to delete the > > _NET_WM_STATE property when a window is unmapped [1], so the state that Chrome > > was getting was invalid. > > > > This CL saves the state when a window becomes unmapped, and includes some small > > cleanups. > > > > [1] https://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#idm140130317598336 > > > > BUG= 882258 > > R=sky > > > > Change-Id: Iacc43563cd54ade77ac83a580ed24434b6802c91 > > Reviewed-on: https://chromium-review.googlesource.com/1226645 > > Commit-Queue: Thomas Anderson <thomasanderson@chromium.org> > > Reviewed-by: Scott Violet <sky@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#592570} > > Bug: 882258 > Change-Id: I0b68e0d386949f3fe458381a640af7358b7c2269 > Reviewed-on: https://chromium-review.googlesource.com/1239252 > Commit-Queue: Thomas Anderson <thomasanderson@chromium.org> > Reviewed-by: Scott Violet <sky@chromium.org> > Cr-Commit-Position: refs/heads/master@{#593711} BUG= 882258 TBR=sky NOTRY=true NOPRESUBMIT=true NOTREECHECKS=true Change-Id: Ied0cc78db1c38fcd0582443470f1d38149174a0e Reviewed-on: https://chromium-review.googlesource.com/1241974 Reviewed-by: Thomas Anderson <thomasanderson@chromium.org> Cr-Commit-Position: refs/branch-heads/3538@{#631} Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811} [modify] https://crrev.com/1c82639f9f784c04843f22f3511f7ab68e5ec6c0/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc [modify] https://crrev.com/1c82639f9f784c04843f22f3511f7ab68e5ec6c0/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.h
,
Sep 24
,
Sep 24
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1c82639f9f784c04843f22f3511f7ab68e5ec6c0 Commit: 1c82639f9f784c04843f22f3511f7ab68e5ec6c0 Author: thomasanderson@chromium.org Commiter: thomasanderson@chromium.org Date: 2018-09-24 22:59:34 +0000 UTC [Merge to M70] Reland "[X11] Don't clear WM state bits when a window is unmapped" > This is a reland of d4d1506d47713470d7b3acad4da9a7f3181fbae0 > > Original change's description: > > [X11] Don't clear WM state bits when a window is unmapped > > > > _NET_WM_STATE holds the window state which may be eg: maximized, fullscreen, > > minimized, etc. In shutdown, Chrome queries this state so that it can restore > > browser windows to the correct state on the next launch. The problem is that > > Chrome queries this state (hundreds of times, in fact) after the window has > > already gone away. The EWMH spec requires window managers to delete the > > _NET_WM_STATE property when a window is unmapped [1], so the state that Chrome > > was getting was invalid. > > > > This CL saves the state when a window becomes unmapped, and includes some small > > cleanups. > > > > [1] https://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#idm140130317598336 > > > > BUG= 882258 > > R=sky > > > > Change-Id: Iacc43563cd54ade77ac83a580ed24434b6802c91 > > Reviewed-on: https://chromium-review.googlesource.com/1226645 > > Commit-Queue: Thomas Anderson <thomasanderson@chromium.org> > > Reviewed-by: Scott Violet <sky@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#592570} > > Bug: 882258 > Change-Id: I0b68e0d386949f3fe458381a640af7358b7c2269 > Reviewed-on: https://chromium-review.googlesource.com/1239252 > Commit-Queue: Thomas Anderson <thomasanderson@chromium.org> > Reviewed-by: Scott Violet <sky@chromium.org> > Cr-Commit-Position: refs/heads/master@{#593711} BUG= 882258 TBR=sky NOTRY=true NOPRESUBMIT=true NOTREECHECKS=true Change-Id: Ied0cc78db1c38fcd0582443470f1d38149174a0e Reviewed-on: https://chromium-review.googlesource.com/1241974 Reviewed-by: Thomas Anderson <thomasanderson@chromium.org> Cr-Commit-Position: refs/branch-heads/3538@{#631} Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811} |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by krajshree@chromium.org
, Sep 10