-
Notifications
You must be signed in to change notification settings - Fork 864
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.
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
IPFS Desktop menu in corrupt state ? #1513
Comments
@rafaelramalho19 and/or @lidel -- can you please look into this? |
@rafaelramalho19 either this is a generic bug in our code or a quirk of Electron on macOS. Some tips for when you have time to take a look:
|
@lidel Isn't this the modal we use to skip the "Do not disturb" mode? Maybe it's blocking all the options from being selectable since it's probably waiting for user input to continue... Need to look into this 🤔 |
I can confirm the dialog freezes everything happening in the ipfs-desktop system tray menu. But I'm not able to reproduce that awkward state @Gozala was reporting. What do you prefer about this?
|
Just dumping some old knowledge here: macOS allows us to show dialogs without showing the dock icon so it can be an hassle to find the dialogs! We're, by default, showing the dock when showing dialogs. @Gozala did you notice if the dock icon of IPFS Desktop was shown at that moment? I think the same happened to me and Molly. However, I did not notice the dock icon. If I did, I wouldn't have force killed IPFS Desktop 😞 -- Idea: maybe the logic behind hiding the dock is wrong because I'm not sure if a dialog is counted for the active windows. But anyways, that shouldn't be a problem because we only call that after receiving the response from the dialog: https://github.com/ipfs-shipyard/ipfs-desktop/blob/master/src/dialogs/dialog.js#L42 We're using |
@hacdias Tried out your suggestion but it's still locking the process until the dialog is dealt with 😢 |
Well, I don't think that the "inactive" state is bad: if a dialog is opened, then it's because user action is required that depends on the current context. If the menu could be changed, things could break. The only worry I have is the corrupt state in the beginning of the post I've never seen before. But so far no one reproduced it. |
Agree with assesment from #1513 (comment), assuming no longer an issue. |
Describe the bug
Menu appears in some corrupt state and every item is disabled
Web UI seems to work fine
Additional context
I did see update notification this morning. Which I suspect might be related
Logs
combined log for last couple of days
error log for this month
The text was updated successfully, but these errors were encountered: