Re: [BUG] org-manual: Using bookmarklet for org-capture is no longer reliable

[Max Nikulin]

On 02/02/2023 21:17, Ihor Radchenko wrote:
> Max Nikulin writes:
>
> > > Would it be reasonable to make org-protocol raise Emacs frame on
> > > failure?
> >
> > Raising frame may help if window manager allows to do it. In some cases
> > the only possibility for a window is to request attention. Creating new
> > frame may be more reliable. Window manager may still take measures
> > against focus stealing. I have heard that such feature exist, but I am
> > unsure concerning severity of such policy.
>
> That's usually up to user.

I would not be so sure for windows. Even on Linux Org should be ready 
for any user configuration of window manager.

> > However I was writing a more annoying issue. Firefox may quietly swallow
> > attempt to launch external protocol handler. Even no message is spitted
> > to console like in the case of unknown protocol or throttling due to
> > multiple attempts during short interval of time. Emacs is completely
> > unaware of capture attempt in such case.
>
> Can Firefox extensions use DBUS?

Browser extensions are isolated as much as possible. It is assumed that 
they communicate with web sites. They may communicate with a native 
messaging application however. It must be installed and configured in 
addition to the extension. This native host application may use D-BUS, 
but it may invoke emacsclient directly. E.g. I use 
https://github.com/maxnikulin/linkremark extension with 
https://github.com/maxnikulin/burl native messaging helper.

I have not checked state of affairs recently, but when I tried native 
messaging applications were unavailable for browsers shipped as snap or 
flatpack packages (due to additional level of isolation). At least some 
related Firefox bugs have not closed yet.

So in practice it is possible to get it working in both cases: external 
protocol handlers and native messaging helper. I would call any approach 
"rock solid" currently.