[Feature Request]: Allow handler in app.on("open-url", handler) to choose whether to activate the app or not

[safris]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• 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