You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I agree to follow the Code of Conduct that this project adheres to.
I have searched the issue tracker for a feature request that matches the one I want to file, without success.
Problem Description
Electron's shell.openPath() currently has an inconsistent behavior on macOS vs. Linux/Windows. The symptom is most evident with an external app that may take a long time to launch, such as with the Zui Electron app I help support where the problem can be observed with Wireshark that can take a long time to open large pcap files.
This first video reproduces the ideal behavior on Linux (and the behavior is much the same on Windows). First a user starts to open a large pcap in Wireshark, and we can see it slowly making progress on opening it by observing its filling "thermometer" and increasing counters at the bottom of the window. While Wireshark is in the middle of this long open, the user clicks to open pcap data from within the Zui app, which triggers a call to Electron's shell.openPath() that leads to attempting to open the pcap file in Wireshark. As shown here, the behavior on Linux (and Windows) is "non-blocking" such that a separate instance of the Wireshark app opens up while the first instance continues its long open.
Linux.mp4
The second video reproduces the less-desirable behavior on macOS. After repeating the same repro steps, we see that on macOS the open behavior is "blocking" such that focus simply jumps to the Wireshark that was already in the middle of its long open. The user effectively has to wait for the "long open" to complete before their separate pcap can open successfully in that single instance of Wireshark.
macOS.mp4
Proposed Solution
It seems it would be useful to offer an option to request the "non-blocking" shell.openPath() behavior on macOS so the user could see consistent behavior across all of Linux, Windows, and macOS. Based our research, it seems that this can be achieved by having Electron's shell.openPath() perform the equivalent of open -n on macOS (-n described as "Open a new instance of the application(s) even if one is already running" per the man page) rather than plain open.
Alternatives Considered
We worked around this problem for a while by creating a fork of this open project and modifying it to call open -n on macOS. However, as sometimes happens with forked/hacked code, the fork fell into disrepair over time and we've gone back to following the advice of that project's README and using Electron's shell.openPath(). However, that means just accepting the blocking behavior on macOS.
Additional Information
No response
The text was updated successfully, but these errors were encountered:
Preflight Checklist
Problem Description
Electron's shell.openPath() currently has an inconsistent behavior on macOS vs. Linux/Windows. The symptom is most evident with an external app that may take a long time to launch, such as with the Zui Electron app I help support where the problem can be observed with Wireshark that can take a long time to open large pcap files.
This first video reproduces the ideal behavior on Linux (and the behavior is much the same on Windows). First a user starts to open a large pcap in Wireshark, and we can see it slowly making progress on opening it by observing its filling "thermometer" and increasing counters at the bottom of the window. While Wireshark is in the middle of this long open, the user clicks to open pcap data from within the Zui app, which triggers a call to Electron's
shell.openPath()
that leads to attempting to open the pcap file in Wireshark. As shown here, the behavior on Linux (and Windows) is "non-blocking" such that a separate instance of the Wireshark app opens up while the first instance continues its long open.Linux.mp4
The second video reproduces the less-desirable behavior on macOS. After repeating the same repro steps, we see that on macOS the open behavior is "blocking" such that focus simply jumps to the Wireshark that was already in the middle of its long open. The user effectively has to wait for the "long open" to complete before their separate pcap can open successfully in that single instance of Wireshark.
macOS.mp4
Proposed Solution
It seems it would be useful to offer an option to request the "non-blocking"
shell.openPath()
behavior on macOS so the user could see consistent behavior across all of Linux, Windows, and macOS. Based our research, it seems that this can be achieved by having Electron'sshell.openPath()
perform the equivalent ofopen -n
on macOS (-n
described as "Open a new instance of the application(s) even if one is already running" per theman
page) rather than plainopen
.Alternatives Considered
We worked around this problem for a while by creating a fork of this
open
project and modifying it to callopen -n
on macOS. However, as sometimes happens with forked/hacked code, the fork fell into disrepair over time and we've gone back to following the advice of that project's README and using Electron'sshell.openPath()
. However, that means just accepting the blocking behavior on macOS.Additional Information
No response
The text was updated successfully, but these errors were encountered: