forge icon indicating copy to clipboard operation
forge copied to clipboard

bug: closing the last tiled window on secondary screen crashes forge (workspace on primary)

Open mipmip opened this issue 3 years ago • 12 comments

Whan I do this a lot of strange stuff happens and the shell get restarted sort. After a few times I'm forced to restart the gnome session.

mipmip avatar Sep 24 '21 10:09 mipmip

Thanks for the report @mipmip - I believe this is due to Forge tracking modal dialogs. Can you provide the last window that you closed? And does it show like a Confirm Exit dialog?

jmmaranan avatar Sep 24 '21 12:09 jmmaranan

The steps to reproduce...

  1. make sure I'm in tiled mode :)
  2. start two alacritty windows on my primary screen
  3. start a alacritty window on my secondary screen
  4. close the alacritty window on my secondary screen

It can be any application I happens with Firefox, or evolution.

See the video....

https://user-images.githubusercontent.com/658612/134676759-03f9f4c1-b951-4847-960e-c515a6565c76.mp4

mipmip avatar Sep 24 '21 12:09 mipmip

Thanks again for the additional info. I can replicate this when the Workspace on Primary is enabled. The other issue I mentioned about Modal Dialogs is a different issue (does not matter if workspace on primary or not) but also produces the same crash.

image

jmmaranan avatar Sep 24 '21 14:09 jmmaranan

@mipmip - added a fix for it. You can check it out from the branch: fix-ws-closing-on-primary, then make dev. Use make uninstall to remove the development version. I think you have to revisit this link: https://extensions.gnome.org/extension/4481/forge/ to get the release version again once I publish and is approved.

jmmaranan avatar Sep 24 '21 14:09 jmmaranan

Sorry, this does not fix the problem for my situation. This is my workspace configuration... It happens when I close the last window on the secondary monitor.

Screenshot from 2021-09-27 11-29-21

mipmip avatar Sep 27 '21 09:09 mipmip

I tried to use the same configuration as yours and able to replicate it. Though it is the same fix from #51. I will leave this ticket open and go ahead with the PR as it might affecting some other users.

jmmaranan avatar Sep 27 '21 21:09 jmmaranan

Here is reproduction and testing in 40 - issue manifesting on the 0:09-0:12 mark after closing Files. Then I applied the patch from main branch after.

https://user-images.githubusercontent.com/348125/134998997-d8f185eb-156f-4676-bc88-7efd9fa9166a.mp4

jmmaranan avatar Sep 27 '21 23:09 jmmaranan

I see you merged the fix. I'll dive into the issue later when I have more time. I'm new to Gnome but I like to get dirty hands.

mipmip avatar Sep 29 '21 09:09 mipmip

I'm sorry - I do not think I have a fix for your issue yet - since I can easily get that other one in for other users (just updating the delay before the workspace event triggers updating the tree) - not until we can resolve / replicate your ticket on both our sides I will not close this.

jmmaranan avatar Sep 29 '21 19:09 jmmaranan

One thing I can think of to help is probably exposing the delay (maybe it is hardware sensitive) for that same change I mentioned as an option (maybe a slider in milliseconds) in prefs.js

jmmaranan avatar Sep 29 '21 19:09 jmmaranan

Just an update - I am now seeing this randomly even with the fix from the other day. But still not sure why it is happening.

jmmaranan avatar Oct 04 '21 00:10 jmmaranan

Hi @mipmip - just checking in again. Are you still seeing this? I spent a couple of days on gnome 40 and 41, I do not see this happening anymore. I am not sure what I did to fix it though :)

jmmaranan avatar Nov 05 '21 13:11 jmmaranan