[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]

> Please, reply to the list.

Apologies. 

> I hope, you used the full expression instead of ellipsis.

Yes, I doubt it would have "worked" otherwise (in the sense that the
link would not have been captured).

> 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.


Thanks, that works and is consistent with what I thought was happening
-- I was unsure of the syntax here. Yes, the "fix" I had before did
produce errors in the console, which presumably also displaced the
'org-protocol:...' string. Not sure what upgrade to the browser has
caused this string to be rendered now ...


> 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.


That extension looks useful -- though I am currently interested in
extracting only a certain amount of information from pages. But I take
your point about the security risk.

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 13/12/2024 01:47, Rehan Deen wrote:
>> I forgot about
>> "+new", so it should be with another variant of parenthesis:
>>       javascript:void(location.href='org-protocol:...)
> 
> Thanks, that works and is consistent with what I thought was happening

Thanks, so now it is known which way docs should be updated.

> Not sure what upgrade to the browser has
> caused this string to be rendered now ...

New behavior is more correct. It is consistent with <a 
href="javascript:..."> links and allows to generate a HTML document to 
display.

> That extension looks useful -- though I am currently interested in
> extracting only a certain amount of information from pages.

You may create your own extension. Unfortunately Firefox releases for 
users require signing of extensions. Chromium is more liberal, after 
enabling developer mode it is possible to install unpacked extensions. 
In Firefox it can be only temporary loaded for the current session.

Some people publish extension code, but not its signed package:
<https://github.com/Stebalien/org-capture-extension/>

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 --------------------