Re: Debugging firefox extension (Re: idea for capture anywhere in x)

[Max Nikulin]

On 17/11/2022 10:16, Samuel Wales wrote:
> On 11/16/22, Max Nikulin wrote:
> > Since recently we were discussing desktop notifications and temporary
> > rising emacs window, I am unsure if capture indication is related to the
> > firefox extension, notification daemon, or emacs.
>
> my brain is not connecting the first part of your sentence with the
> second part [this has to do with my brain, not your english],

I was writing about notify-send (or d-bus function) called in the case 
of successful capture and notification-daemon or dunst:
Samuel Wales. Re: desktop notifications (Re: idea for capture anywhere 
in x) Wed, 26 Oct 2022 01:07:18 -0700. 
https://list.orgmode.org/CAJcAo8sp3dyUT0b8=3T1YeiQZzmDYS9Zah_6+LdczWHicnVX=w@mail.gmail.com

I am unsure if your managed to add such feature to your configuration.

> but i
> have been assuming that it is the firefox org-capture extension saying
> "i sent the request".

Check browser console for warnings and try to call emacsclient with some 
org-protocol: URI from xterm or another terminal application (I would 
avoid Emacs shell buffers for such tests).

> pop up emacs frame for a fraction of a second, which then, in elisp,
> pops back down again.

To raise and lower an existing window perhaps something like wmctrl, 
xdotool or fluxbox-remote should be used.

Remaining withing Emacs I would consider temporary creating a new frame 
and dismissing it. I am unsure concerning focus stealing protection in 
window managers that may hide such window.

A simple command that might be a substitute to notification windows:

    zenity --timeout 1 --info --title 'Title' --text 'Text'

There are a number of dialog tools similar to zenity: lightweight or 
integrated with desktop environments. I have no idea which one you may 
have installed and if it has timeout feature or sleep&kill workaround 
should be used instead.

However I believe that not running some notification daemon may cause 
problems with various application.

> > More robust approach is a native messaging application that is a bridge
> > between sandboxed firefox extension and emacs. It makes setup more
> > complicated however and no simple org-protocol extensions use this
> > approach.
>
> not sure i understand what native or sandboxed mean here or why, and
> whether org-protocol is needed or if you are saying that there might
> be a non-simple-to-install extension for it or so.

Browsers create sandboxes for web pages and extensions to isolate them 
from host system. There is an API that allows communication of an add-on 
with particular helper application running on host system:
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging

A dedicated naive messaging helper allows to check emacsclient exit code 
or stdout. The price is more complicated configuration. Of course, an 
extension should support such communication protocol.