[BUG] Org-protocol bookmarklets in Firefox behaving badly after recent upgrade [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.4/lisp/org/)]

[BUG] Org-protocol bookmarklets in Firefox behaving badly after recent upgrade [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.4/lisp/org/)]

[Rehan Deen]

Hello all,

After upgrading Firefox to version 133.0-1 on Manjaro Linux, I find that
that my Org-protocol bookmarklets in Firefox are not working properly.

Namely, after I click on them to capture a link or some text, the
information is copied appropriately but the browser switches from
displaying the webpage to displaying an almost blank page with just the
text of an Org-protocol link.

E.g. when using the following bookmarklet

    javascript:location.href='org-protocol://store-link?'+new
    URLSearchParams({url:location.href, title:document.title});

on the webpage https://orgmode.org/, Emacs is able to capture the link
and title ("Org mode for GNU Emacs") as desired, but the browser
displays a blank page with the following text:

    org-protocol://store-link?url=https%3A%2F%2Forgmode.org%2F&title=Org+mode+for+GNU+Emacs

I have to hit refresh to redisplay the original webpage.

The same occurs for more complicated bookmarklets involving Org capture
templates, as well as Org-roam-protocol bookmarklets, but I think the
basic issue arises from Org alone.

I have continued to use the same `org-protocol.desktop` file to handle
these links:

    [Desktop Entry]
    Name=org-protocol
    Exec=emacsclient -n %u
    Type=Application
    Terminal=false
    Categories=System;
    MimeType=x-scheme-handler/org-protocol;

I know that Emacs 29.2 introduced a new `emacsclient.desktop` file that
handles Org-protocol links, but copying it from
`/usr/share/applications` to `~/.local/share/applications/`,
renaming/removing the old `emacsclient.desktop` and
`org-protocol.desktop` files, and running

    update-desktop-database ~/.local/share/applications/

does not resolve the problem.

Interestingly, the `org-capture` extension for Firefox from
https://github.com/sprig/org-capture-extension continues to work without
producing this issue (i.e. the link is captured and the webpage
continues to be displayed properly).

------------------------------------------------------------------------



Emacs  : GNU Emacs 29.4 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.43, cairo version 1.18.2)
 of 2024-12-06
Package: Org mode version 9.6.15 (release_9.6.15 @ /usr/share/emacs/29.4/lisp/org/)

 

Re: [BUG] Org-protocol bookmarklets in Firefox behaving badly after recent upgrade [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.4/lisp/org/)]

[Max Nikulin]

On 12/12/2024 15:12, Rehan Deen wrote:
>      javascript:location.href='org-protocol://store-link?'+new
>      URLSearchParams({url:location.href, title:document.title});

Try to add "(void)"
javascript:(void)location.href='org-protocol:...

However bookmarklets are unsafe, you have to allow *web page* to launch 
a handler. In the case of an extension this permission may be given to 
the extension (but sprig/org-capture-extension still use the unsafe way).

> but copying it from
> `/usr/share/applications` to `~/.local/share/applications/`,

It should not be necessary. It should be enough to remove your own 
association. In some cases the -display="$DISPLAY" trick is important.

> Interestingly, the `org-capture` extension for Firefox from
> https://github.com/sprig/org-capture-extension continues to work without
> producing this issue

It executes its code in another context.

Re: [BUG] Org-protocol bookmarklets in Firefox behaving badly after recent upgrade [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.4/lisp/org/)]

[Max Nikulin]

Please, reply to the list.

On 12/12/2024 17:34, Max Nikulin wrote:
> On 12/12/2024 15:12, Rehan Deen wrote:
>>      javascript:location.href='org-protocol://store-link?'+new
>>      URLSearchParams({url:location.href, title:document.title});
> 
> Try to add "(void)"
> javascript:(void)location.href='org-protocol:...

I hope, you used the full expression instead of ellipsis. I forgot about 
"+new", so it should be with another variant of parenthesis:

     javascript:void(location.href='org-protocol:...)

The idea is to discard a string returned by the assignment operator.

Try to open web developer tools [F12] and switch to console. You might 
notice some error messages.

> However bookmarklets are unsafe, you have to allow *web page* to launch 
> a handler. In the case of an extension this permission may be given to 
> the extension (but sprig/org-capture-extension still use the unsafe way).

You may try
https://github.com/vifon/org-protocol-for-firefox/
that uses another method to launch external protocol handler.

Personally I am interested in extracting as much page metadata as 
possible, so bookmarklets and simple extensions is not an option.

In future, I hope, it is better to avoid org-protocol.el hack with an 
advice and rely on the new `server-eval-args-left' feature.

Re: [BUG] Org-protocol bookmarklets in Firefox behaving badly after recent upgrade [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.4/lisp/org/)]

[Rehan Deen]

-------------------- Start of forwarded message --------------------
From: Rehan Deen <rehan.deen@gmail.com>
To: Max Nikulin <manikulin@gmail.com>
Subject: Re: [BUG] Org-protocol bookmarklets in Firefox behaving badly after
 recent upgrade [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.4/lisp/org/)]


> Try to add "(void)"
> javascript:(void)location.href='org-protocol:...>

Thanks. I don't know much JavaScript so I didn't think to look at
something like that.

I tried it as you've described, but it does not work at all -- i.e.
nothing is even captured.

I've also tried:

    javascript:(void);location.href='org-protocol:...>
    javascript:void;location.href='org-protocol:...>
    javascript:(void 0)location.href='org-protocol:...> 
    javascript:void (0)location.href='org-protocol:...> 
    javascript:"void 0"location.href='org-protocol:...> 

None of which worked at all either.

The following variations do capture the link:

    javascript:(void 0);location.href='org-protocol:...> 
    javascript:void 0;location.href='org-protocol:...> 
    javascript:"void 0";location.href='org-protocol:...>
    javascript:void (0);location.href='org-protocol:...> 

but they all still display the problem of the browser switching to a
near blank page with the Org-protocol link.

However, I find that the following both seem to work:

    javascript:location.href='org-protocol://store-link?'+new
    URLSearchParams({url:location.href,title:document.title});
    location.event.preventDefault();

and

    javascript:location.href='org-protocol://store-link?'+new
    URLSearchParams({url:location.href,title:document.title});
    location.class("hoveronly");

(As found in
https://stackoverflow.com/questions/3498492/javascriptvoid0-vs-return-false-vs-preventdefault
and
https://stackoverflow.com/questions/61265408/href-javascriptvoid0-v-s-href-onclick-return-false?noredirect=1&lq=1)

There's probably a cleaner way to "disable the link on click" that
someone who is more experienced in JS than me can say.


> However bookmarklets are unsafe, you have to allow *web page* to
> launch a handler. In the case of an extension this permission may be
> given to the extension (but sprig/org-capture-extension still use the
> unsafe way).


Thanks for the warning. I am not sure how to implement this safely,
though perhaps this should be an issue raised in the Worg documentation,
e.g. in https://orgmode.org/worg/org-contrib/org-protocol.html
-------------------- End of forwarded message --------------------