Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Invisible menu on Linux #12275

Closed
alespergl opened this issue Mar 14, 2018 · 11 comments
Closed

Invisible menu on Linux #12275

alespergl opened this issue Mar 14, 2018 · 11 comments
Assignees
@ckerr
Labels
2-0-x 3-0-x 4-2-x 8-x-y bug 🪲 platform/linux

Comments

@alespergl
Copy link
Contributor

  • Electron version: 2.0.0-beta.3
  • Operating system: Ubuntu 16.04.04 LTS

Expected behavior

App menu should be visible

Actual behavior

App menu is invisible

How to reproduce

  • Run electron
  • Observe that the app menu is invisible. It is still possible to open submenus.

screenshot from 2018-03-14 17-01-18
@bpasero
Copy link
Contributor

bpasero commented Mar 14, 2018

@alespergl I do not see that. Just installed a fresh Ubuntu 16.04 LTS running via Parallels on macOS:

image

@ckerr ckerr self-assigned this Mar 14, 2018
@ckerr
Copy link
Member

ckerr commented Mar 14, 2018

Interesting! I'm not seeing this in 17.10. I'll see if I can reproduce the behavior in 16.04 LTS.

menu-ubuntu-17 10-radiance-theme

@ckerr
Copy link
Member

ckerr commented Mar 14, 2018 •
edited
Loading

Huzzah, it's repeatable:

I'm seeing this behavior when running in the Adwaita-dark theme. Inspiration by @bjornharrtell's comment at microsoft/vscode#45542 (comment)

@alespergl
Copy link
Contributor Author

LibreOffice had the same issue.
https://bugs.documentfoundation.org/show_bug.cgi?id=101471

They seem to have patched it with
https://cgit.freedesktop.org/libreoffice/core/commit/?id=72eb18e520ea8165a6a20958a1551f55e5e14cab

ckerr added a commit that referenced this issue Mar 15, 2018
@ckerr
Better GTK+ Menu color support
2a21850 
 * Fix 'invisible menu' issue (#12275)

 * Now updates menu text color when focus changes!

 * Better caching of colors when system theme changes

 * Removed all GTK+ deprecation warnings from menubar
@ckerr ckerr mentioned this issue Mar 15, 2018
Merged
ckerr added a commit that referenced this issue Mar 16, 2018
@ckerr
Better GTK+ Menu color support (#12300)
558ef73 
* Better GTK+ Menu color support

 * Fix 'invisible menu' issue (#12275)

 * Now updates menu text color when focus changes!

 * Better caching of colors when system theme changes

 * Removed all GTK+ deprecation warnings from menubar

* Don't highlight menu text on mouseover in GTK+

* Fix textColor declaration scope error

* Simplify FocusManager connection management a bit

* Make the linter happy

* Decouple MenuBar view recoloring from rebuilding

This way we don't need to rebuild the subview each time a recolor
is needed, e.g. when window focus changes or the system theme changes

* Don't iterate child views if we don't need to

* Move variable declaration outside of a loop

* More efficient iteration of MenuBar children

* Cleaner MenuButton bounds testing

* Fix oops

* Add a nullptr check in MenuBar::GetItemCount()

* Simplify iteration in MenuBar::RebuildChildren()

* Make the linter happy

* Fix signed-unsigned comparison

* Remove declarations of nonexistent methods

* Make SubmenuButton accessor const

* Cleaner accelerator iteration

* Windows fixes
ckerr pushed a commit that referenced this issue Mar 17, 2018
@trop @ckerr
Backport (2-0-x) - Better GTK+ Menu color support (#12331)
706f0c4 
* Better GTK+ Menu color support

 * Fix 'invisible menu' issue (#12275)

 * Now updates menu text color when focus changes!

 * Better caching of colors when system theme changes

 * Removed all GTK+ deprecation warnings from menubar

* Don't highlight menu text on mouseover in GTK+

* Fix textColor declaration scope error

* Simplify FocusManager connection management a bit

* Make the linter happy

* Decouple MenuBar view recoloring from rebuilding

This way we don't need to rebuild the subview each time a recolor
is needed, e.g. when window focus changes or the system theme changes

* Don't iterate child views if we don't need to

* Move variable declaration outside of a loop

* More efficient iteration of MenuBar children

* Cleaner MenuButton bounds testing

* Fix oops

* Add a nullptr check in MenuBar::GetItemCount()

* Simplify iteration in MenuBar::RebuildChildren()

* Make the linter happy

* Fix signed-unsigned comparison

* Remove declarations of nonexistent methods

* Make SubmenuButton accessor const

* Cleaner accelerator iteration

* Windows fixes
@alexeykuzmin
Copy link
Contributor

It seems like the fix has been merged to the 2-0-x branch.

sethlu pushed a commit to sethlu/electron that referenced this issue May 3, 2018
@ckerr @sethlu
Better GTK+ Menu color support (electron#12300)
2c28388 
* Better GTK+ Menu color support

 * Fix 'invisible menu' issue (electron#12275)

 * Now updates menu text color when focus changes!

 * Better caching of colors when system theme changes

 * Removed all GTK+ deprecation warnings from menubar

* Don't highlight menu text on mouseover in GTK+

* Fix textColor declaration scope error

* Simplify FocusManager connection management a bit

* Make the linter happy

* Decouple MenuBar view recoloring from rebuilding

This way we don't need to rebuild the subview each time a recolor
is needed, e.g. when window focus changes or the system theme changes

* Don't iterate child views if we don't need to

* Move variable declaration outside of a loop

* More efficient iteration of MenuBar children

* Cleaner MenuButton bounds testing

* Fix oops

* Add a nullptr check in MenuBar::GetItemCount()

* Simplify iteration in MenuBar::RebuildChildren()

* Make the linter happy

* Fix signed-unsigned comparison

* Remove declarations of nonexistent methods

* Make SubmenuButton accessor const

* Cleaner accelerator iteration

* Windows fixes
@jainsuchita
Copy link

screenshot from 2018-11-19 16-48-59

Electron Version - 4.0.0-beta.6
Operating system: Ubuntu 18.10

Guys, I am still facing the issue.
Any update on this?

@digimezzo digimezzo mentioned this issue Nov 20, 2018
Open
@ckerr
Copy link
Member

ckerr commented Jan 24, 2019

According to Trish at Slack QA, this is still reproducible in both Electron 3 & 4.

@ckerr ckerr reopened this Jan 24, 2019
@electron-triage
Copy link

Thank you for taking the time to report this issue and helping to make Electron better.

The version of Electron you reported this on has been superseded by newer releases.

If you're still experiencing this issue in Electron 6.x.y or later, please add a comment specifying the version you're testing with and any other new information that a maintainer trying to reproduce the issue should know.

I'm setting the blocked/need-info label for the above reasons. This issue will be closed 7 days from now if there is no response.

Thanks in advance! Your help is appreciated.

@electron-triage electron-triage added the blocked/need-info ❌ Cannot proceed without more information label Feb 19, 2020
@johnosbb
Copy link

Still observable on Ubuntu 16.04 running electron version
electron --version = v8.0.1
run electron or any electron based application. No menus are shown.

@johnosbb
Copy link

I am new to Electron, but I can try to debug this on my system if someone has some suggestions on where to look initially.

@electron-triage electron-triage added 8-x-y and removed blocked/need-info ❌ Cannot proceed without more information labels Feb 26, 2020
@electron-triage
Copy link

The Electron version reported on this issue is no longer supported. See our supported versions documentation.

If this is still reproducible on a supported version, please open a new issue with any other new information that a maintainer should know.

Thank you for taking the time to report this issue and helping to make Electron better! Your help is appreciated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ckerr ckerr

Labels
2-0-x 3-0-x 4-2-x 8-x-y bug 🪲 platform/linux
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
8 participants
@ckerr @alexeykuzmin @bpasero @sofianguy @jainsuchita @johnosbb @alespergl @electron-triage