Subject: bug#71579: 30.0.50; Mailto URI handler emacsclient doesn't show unless there's a visible frame

From: Björn Bidar <[email-masked]>
Date: Mon, 10 Mar 2025 13:14:37 +0200

Eli Zaretskii <[email-masked]> writes:

>> From: Björn Bidar <[email-masked]>
>> Cc: Eli Zaretskii <[email-masked]>,  [email-masked]
>> Date: Sun, 09 Mar 2025 07:41:31 +0200
>> 
>> 
>> Eli Zaretskii <[email-masked]> writes:
>> 
>> >> From: Björn Bidar <[email-masked]>
>> >> Date: Sat, 08 Mar 2025 14:14:11 +0200
>> >> 
>> >> 
>> >> I'm not sure if this is worth a bug report but while testing I noticed
>> >> that using the emacsclient mailto handler opens a buffer in any frame no
>> >> matter if there is a visible frame or not on the current virtual
>> >> desktop.
>> >> 
>> >> Is this a bug or intended? 
>> >
>> > I don't understand what you mean.  How can a buffer be shown in a
>> > frame that is not visible?  And what do you mean by "any frame"?
>> 
>> By visible I mean that it is not present on the current virtual desktop.
>> Lets say the user has a frame on desktop 1 but is on  desktop 2.
>> Now they open a mailto link and the link will be opened in the frame on
>> desktop one despite them being on desktop 2.
>> 
>> With in any frame I mean any frame without filtering out those which are
>> currently not visible on the users screen.
>
> I'm not familiar with the notion of "desktop" in the context of
> emacsclient.  emacsclient either uses an existing frame or (if invoked
> with -c, or if there's no existing frame) creates a new one.  is what
> you see consistent with what I say?  Is what you see consistent with
> what happens when you invoke emacsclient with a name of a file, not
> mailto URI, and leave all the other command-line options of
> emacsclient unaltered?  If there's a difference, please describe how
> emacsclient behaves differently compared to the other use cases.

No there's no difference in the behaviour.  I'm not sure if in this
context emacsclient is the deciding the factor as the function that is
called in Emacsclient can decide how to open the new buffer.

The no visible frame on the current "desktop" is just one example.
If there is no frame open at all no new frame will be opened ether.