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
Consider a Notification with an action such as "Delete", to indicate to the app that the subject message of the Notification should be deleted.
With an implementation that uses registered protocols, the "Delete" action is delivered to Electron via the app.on("open-url", handler) listener.
When Electron receives an "open-url" event, it is automatically activated (i.e. gets focus, and is made frontmost), which is not necessarily desired (such as when the user wishes to "Delete" and thus ignore the message).
Proposed Solution
When Electron receives an "open-url" event, do not automatically activate the app (i.e. focusing it and making it frontmost).
To activate the app, app.focus({ steal: true }) can be called manually.
Since this would be a breaking change of the behavior of the "open-url" event handler, I propose implementation of a new method on app to "switch on or off" this new behavior. As in, something akin:
app.dontAutoFocusAppOnOpenUrl(true);
Alternatives Considered
The problem can be abstracted as follows: "How can Electron receive a message from another application or the OS, and handle that message without automatically being activated?"
Listening for second instance invocations of the app from the OS with app.on("second-instance", handler) provides a solution to this problem. However, this approach would require the invoker to construct a CLI-based command to spawn a new shell, in which a new instance of the app is spawned, only to deliver a message payload to the running instance's app.on("second-instance", handler) handler.
Another solution is via an embedded web server running as a utility process. This approach, however, is not feasible due a couple edge cases, one of which is: the need to register a listening port that does not persist upon app restart.
Additional Information
No response
The text was updated successfully, but these errors were encountered:
Preflight Checklist
Problem Description
Consider a Notification with an action such as "Delete", to indicate to the app that the subject message of the Notification should be deleted.
With an implementation that uses registered protocols, the "Delete" action is delivered to Electron via the app.on("open-url", handler) listener.
When Electron receives an "open-url" event, it is automatically activated (i.e. gets focus, and is made frontmost), which is not necessarily desired (such as when the user wishes to "Delete" and thus ignore the message).
Proposed Solution
When Electron receives an "open-url" event, do not automatically activate the app (i.e. focusing it and making it frontmost).
To activate the app,
app.focus({ steal: true })
can be called manually.Since this would be a breaking change of the behavior of the "open-url" event handler, I propose implementation of a new method on
app
to "switch on or off" this new behavior. As in, something akin:Alternatives Considered
The problem can be abstracted as follows: "How can Electron receive a message from another application or the OS, and handle that message without automatically being activated?"
Listening for second instance invocations of the app from the OS with
app.on("second-instance", handler)
provides a solution to this problem. However, this approach would require the invoker to construct a CLI-based command to spawn a new shell, in which a new instance of the app is spawned, only to deliver a message payload to the running instance'sapp.on("second-instance", handler)
handler.Another solution is via an embedded web server running as a utility process. This approach, however, is not feasible due a couple edge cases, one of which is: the need to register a listening port that does not persist upon app restart.
Additional Information
No response
The text was updated successfully, but these errors were encountered: