Issue metadata
Sign in to add a comment
|
Options menu entries are invisible unless highlighted (by mouse hover).
Reported by
saurabh....@gmail.com,
Sep 27
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36 Steps to reproduce the problem: 1. Open Options Menu by clicking 3 dots. 2. Entries are invisible. Only shortcuts are visible. 3. Hover over entries to highlight and make entry visible. What is the expected behavior? 1. Open Options Menu by clicking 3 dots. 2. Menu entries are visible. What went wrong? I don't remember if I tried opening Options Menu after upgrading to Mojave (my Chrome updated at the same time), so not sure if it worked before. Could probably be as a result of switching between Dark and Light theme in macOS Mojave. Tried changing chrome themes and it's unaffected. Tried restarting Chrome as well. [Attached video showing this] Did this work before? Yes Last stable version. Chrome version: 69.0.3497.100 Channel: stable OS Version: OS X 10.14.0 Flash Version: I tried to find it in the existing issues, but didn't find any open bugs. I am sorry if it's a duplicate.
,
Sep 27
,
Sep 27
,
Sep 28
saurabh.shrivastava54@ Thanks for the issue. Tested this issue on Mac OS 10.13.3 on the reported version 69.0.3497.100 and the latest Canary 71.0.3563.0 and unable to reproduce the issue by following the below steps. 1. Launched Chrome and clicked on the wrench menu. 2. Could observe that the menu is displayed as expected and no issues are observed. Attached is the screen cast for reference. Looks like this issue is related to Mac Mojave. Hence adding label 'Proj-MacMojave' and requesting the appropriate team to look into the issue and help in further triaging. Thanks..
,
Sep 28
Since I can still reproduce the issue, if you need any more information (logs etc.), I'll be happy to share.
,
Sep 28
mac triage: over to lgrey@ - I thought we opted out of dark mode in M69?
,
Sep 28
ellyjo...@ Chrome appears dark due to a theme. See comment #3 to see the same without any theme. Also, regarding dark mode. The top bar that appears on fullscreen with traffic lights (see https://bugs.chromium.org/p/chromium/issues/detail?id=850873) is dark during dark mode (irrespective of any theme) is dark.
,
Sep 28
Re c#8 the theme should be irrelevant. This issue came up before we disabled system dark mode, since in system dark mode, the font color was being set to light in that menu but... .. per c#7 we *did* disable dark mode, and I can't repro this on 10.14.0/69.0.3497.100 saurabh.shrivastava54@gmail.com, can you attach your /Applications/Google\ Chrome.app/Contents/Info.plist ? (you can type "open /Applications/Google\ Chrome.app/Contents/" into Terminal to see it)
,
Sep 28
Thanks! Everything looks as expected there, so I'm still puzzled. Is there anything unique or unusual about your system, or have you made any kind of customizations beyond turning on dark mode? Does switching back to light mode fix it? If so, is it immediate or does it require a restart? Does it still happen if using a guest Chrome profile?
,
Sep 28
> or have you made any kind of customizations beyond turning on dark mode I think we're onto something. I tired using only dark menu and dock. So, I followed : https://www.tekrevue.com/tip/only-dark-menu-bar-dock-mojave/ and did `defaults write -g NSRequiresAquaSystemAppearance -bool Yes` But, I reversed it almost immediately (and restarted) `defaults write -g NSRequiresAquaSystemAppearance -bool No`. So, we're _ideally_ back to everything as it should be. Secondly, Subpixel antialiasing for text in macOS Mojave has been disabled permanently. This made text illegible on my external displays. So, to enable font smoothening I have done `defaults write -g CGFontRenderingFontSmoothingDisabled -bool FALSE` That's about it. > Does switching back to light mode fix it? Yes, it does. > If so, is it immediate or does it require a restart? Immediate. > Does it still happen if using a guest Chrome profile? Yes.
,
Sep 28
Thanks! `defaults write -g NSRequiresAquaSystemAppearance -bool No`. is the issue. Unfortunately, this overrides our temporary dark mode opt-out (as well as any other application's). The font problem is Issue 858861 which should be fixed on Canary tomorrow.
,
Sep 28
So, how do I make it have the default behavior?
,
Sep 28
You would need to unset that global defaults setting. I'm not sure what the syntax would be, but I would start with `man defaults`
,
Sep 28
lgrey@ Thank you for the pointers! :) I realised I could define those properties per app. So, I turned NSRequiresAquaSystemAppearance specifically for Chrome right now (I believe that's your temporary dark mode opt-out). `defaults write com.google.Chrome NSRequiresAquaSystemAppearance -bool Yes` Also, I found out that while (/Applications/Google\ Chrome.app/Contents/Info.plist) had NSRequiresAquaSystemAppearance flag, the preference one ( /Users/saurabhshri/Library/Preferences/com.google.Chrome.plist) had been missing due to me turning it off globally probably? Anyway, I am golden for now. Maybe this issue could be merged to the main one where things around temporary opt-out are being tracked? |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 Deleted