Chrome on macOS does not set top Chrome to material design (refresh) until 2nd launch
Reported by
t...@synthist.net,
Sep 10
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.81 Safari/537.36 Steps to reproduce the problem: 1. Install Chrome 69.0.3497.81 on macOS. 2. rm '~/Library/Application Support/Google/Chrome' to force the creation of a fresh profile. 3. Launch Chrome What is the expected behavior? material design "refresh" - the equivalent of setting top-chrome-md flag to "refresh" would be the default, even on a completely fresh profile. This is currently the case on Windows. What went wrong? If I view the top-chrome-md flag via chrome://flags/#top-chrome-md, it shows "default" in the state of the top-chrome-md flag, however the tabs are still visibly using the "normal" setting. Did this work before? N/A Chrome version: 69.0.3497.81 Channel: stable OS Version: OS X 10.13.6 Flash Version: If I quit Chrome and then relaunch it, it loads the refresh design, so this seems to be behaviour only visible on the first launch of a clean profile.
,
Sep 10
For what it's worth, I also tried setting --top-chrome-md=material-refresh but this didn't have an effect. It looks to me like perhaps this isn't enough though.
,
Sep 10
,
Sep 10
Confirmed by launching with a clean --user-data-dir Conjecturing (will look more) that we're picking up the MD refresh flag, but not MacViews.
,
Sep 10
Thank you! I attempted to also set the MagViews flag as part of debugging this but I couldn't really tell whether I was doing it right or whether that's even possible via command-line switches.
,
Sep 10
This is a known behavior due to the way we're releasing Material Refresh to Mac on M69. Because of the release setup on M69, Chrome needs network access and 1 restart to launch with the Material Refresh UI specifically on Mac. When M70 rolls around, Chrome will always launch with Material Refresh on Mac, even with a clean profile. If this is causing an issue for you, we're happy to hear about it, otherwise this bug will be WontFixed tomorrow. Thanks!
,
Sep 10
Thanks for your quick response. I suspected that potentially there was some additional bootstrapping required. The use case is for us to provide the new UI for Chrome 69 Selenium-based tests on Sauce Labs. Can you see any potential workaround that we might be able to set the new UI on the first launch? For example, any additional default user-data-dir contents or preferences that we could special-case for just version 69?
,
Sep 10
Does --enable-features=ViewsBrowserWindows work for you?
,
Sep 10
Yep, you'll want to do what lgrey@ suggests in #8.
,
Sep 10
That worked perfectly. Thank you! Feel free to WontFix this if this is otherwise working as expected for M69.
,
Sep 10
Good to know that #8 worked. Proceeding to WontFix as this is the expected behavior for M69. Thanks!
,
Sep 29
|
||||
►
Sign in to add a comment |
||||
Comment 1 by susan.boorgula@chromium.org
, Sep 10