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

Tray icon unresponsive #1522

Closed
ghost opened this issue May 23, 2020 · 9 comments
Closed

Tray icon unresponsive #1522

ghost opened this issue May 23, 2020 · 9 comments
Labels
area/linux Linux effort/hours Estimated to take one or several hours exp/expert Having worked on the specific codebase is important help wanted Seeking public contribution on this issue kind/bug A bug in existing code (including security flaws) need/analysis Needs further analysis before proceeding P1 High: Likely tackled by core team if no one steps up

Comments

@ghost
Copy link

ghost commented May 23, 2020 •
edited by ghost
Loading

  • OS: Ubuntu 20.04, fresh install, updated
  • Version of IPFS Desktop 0.11.4 (snap)

Describe the bug
The icon tray does not respond to click event

Expected behavior
Context menu should appear

Additional context
Tested on a newly installed ubuntu 20.04, all updated, Gnome 3.36.2
@ghost ghost added the need/triage Needs initial labeling and prioritization label May 23, 2020
@jayschwa jayschwa mentioned this issue May 26, 2020
Closed
@jayschwa
Copy link

Possible upstream issue: electron/electron#21576

@jayschwa
Copy link

jayschwa commented Jun 8, 2020

A fix has allegedly been merged into Electron (and backported to older release branches). electron/electron#23674

@jayschwa
Copy link

I experience this issue only when using the snap package. The tray icon menu works when using the Debian package.

@Azulan
Copy link

Azulan commented Jul 22, 2020 •
edited
Loading

I also have the same issue using the snap package on Xubuntu 20.04. This also creates a situation in which I cannot exit the application once I start it. Closing the window has no effect and the notification icon is useless. Please include a way to exit and terminate that doesn't rely on the icon.

@jessicaschilling
Copy link
Contributor

@lidel and/or @rafaelramalho19 - FYI, thanks!

@SvenMeyer
Copy link

System : Manjaro / Arch Linux + cinnamon
Version : ipfs-desktop 0.11.3-1 (from AUR)

During the last weeks I had strange router chrashes and freeze-ups, spent hours with ISP support, but only after I installed "Net Activity Viewer", I realized that there were still 3 IPFS destops, ~30 ipfs processes running, and 300 open network connections made by IPFS (so it looks like the cheap ISP router could not handle the amount of netcwork connections - of which I was not aware all the time.)
I haven't seen a tray icon for a week, and if I re-started ipfs-desktop, I just got another process running with no way to close all ipfs processes and network connections ...

Looks like the whole "tray icon issue" is a mess and maintainer of the Arch Linux AUR package already submitted a pull request.
develar/app-builder#29

@lidel
Copy link
Member

lidel commented Jul 31, 2020 •
edited
Loading

Correct, Electron team broke tray support by merging Chromium changes, then backed out of them, in the meantime some distros and desktop environments introduced workaround and patches, some did not, tray icon UX and DX in Linux ecosystem is beyond bad right now.

We are tracking this already in #1153 (comment)

However, I believe the current issue is about separate problem:

  • "starting ipfs-desktop more than once (via icon or cli) spawns more than one daemon"

I believe Desktop should detect its already running, and show WebUI instead of spawning new instance. I vaguely remember us fixing that in the past, but perhaps the fix was not generic enough?

If a Linux user has bandwidth for investigating this, PR or some guidance would be appreciated 🙏

@lidel lidel added area/linux Linux effort/hours Estimated to take one or several hours need/analysis Needs further analysis before proceeding P1 High: Likely tackled by core team if no one steps up exp/expert Having worked on the specific codebase is important help wanted Seeking public contribution on this issue kind/bug A bug in existing code (including security flaws) and removed need/triage Needs initial labeling and prioritization labels Jul 31, 2020
@SvenMeyer
Copy link

SvenMeyer commented Aug 20, 2020 •
edited
Loading

I my case it would already help if I could stop the daemon from running / re-starting using the tray icon menu.
#1611

@jessicaschilling jessicaschilling mentioned this issue Aug 20, 2020
Closed
@lidel
Copy link
Member

lidel commented Oct 12, 2020

This should be fixed in v0.13.2.
If there are any new issues with tray, please open a new issue.

@lidel lidel closed this as completed Oct 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area/linux Linux effort/hours Estimated to take one or several hours exp/expert Having worked on the specific codebase is important help wanted Seeking public contribution on this issue kind/bug A bug in existing code (including security flaws) need/analysis Needs further analysis before proceeding P1 High: Likely tackled by core team if no one steps up
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@SvenMeyer @lidel @jayschwa @Azulan @jessicaschilling