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

[PATCH] org-protocol: Add void() to bookmarklets

[Max Nikulin]

[-- Attachment #1: Type: text/plain, Size: 335 bytes --]

On 13/12/2024 01:47, Rehan Deen wrote:
>>       javascript:void(location.href='org-protocol:...)
>>
>> The idea is to discard a string returned by the assignment operator.
[...]
> Thanks, that works and is consistent with what I thought was happening

A patch updating org-protocol.el comments, docstrings, and the manual is 
attached.

[-- Attachment #2: 0001-org-protocol-Add-void-to-bookmarklets.patch --]
[-- Type: text/x-patch, Size: 7684 bytes --]

From 84de1aec4532d36d24002ad2dcbc67993ff5c3c4 Mon Sep 17 00:00:00 2001
From: Max Nikulin <manikulin@gmail.com>
Date: Mon, 16 Dec 2024 21:46:49 +0700
Subject: [PATCH] org-protocol: Add void() to bookmarklets

* doc/org-manual.org (The store-link protocol):
(The capture protocol, The open-source protocol):
* lisp/org-protocol.el (org-protocol-store-link):
(org-protocol-capture, org-protocol-open-source): Update javascript:
bookmarklets to discard assigned value.

Firefox-133 may treat expression value as document content to render.

Reported by: Rehan Deen.  [BUG] Org-protocol bookmarklets in Firefox
behaving badly after recent upgrade.  Thu, 12 Dec 2024 13:42:34 +0530.
Link: <https://list.orgmode.org/87pllx7219.fsf@gmail.com>
---
 doc/org-manual.org   | 20 ++++++++++----------
 lisp/org-protocol.el | 34 +++++++++++++++++-----------------
 2 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 0f6d6a067..10900f738 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -21318,15 +21318,15 @@ *** The ~store-link~ protocol
 name, e.g., =Org: store-link= and enter this as /Location/:
 
 #+begin_example
-javascript:location.href='org-protocol://store-link?' +
-      new URLSearchParams({url:location.href, title:document.title});
+javascript:void(location.href='org-protocol://store-link?' +
+      new URLSearchParams({url:location.href, title:document.title}));
 #+end_example
 
 Title is an optional parameter.  Another expression was recommended earlier:
 
 #+begin_example
-javascript:location.href='org-protocol://store-link?url='+
-      encodeURIComponent(location.href);
+javascript:void(location.href='org-protocol://store-link?url='+
+      encodeURIComponent(location.href));
 #+end_example
 
 The latter form is compatible with older Org versions from 9.0 to 9.4.
@@ -21347,19 +21347,19 @@ *** The ~capture~ protocol
 =Org: capture=, and enter this as =Location=:
 
 #+begin_example
-javascript:location.href='org-protocol://capture?' +
+javascript:void(location.href='org-protocol://capture?' +
       new URLSearchParams({
             template: 'x', url: window.location.href,
-            title: document.title, body: window.getSelection()});
+            title: document.title, body: window.getSelection()}));
 #+end_example
 
 You might have seen another expression:
 
 #+begin_example
-javascript:location.href='org-protocol://capture?template=x'+
+javascript:void(location.href='org-protocol://capture?template=x'+
       '&url='+encodeURIComponent(window.location.href)+
       '&title='+encodeURIComponent(document.title)+
-      '&body='+encodeURIComponent(window.getSelection());
+      '&body='+encodeURIComponent(window.getSelection()));
 #+end_example
 
 It is a bit more cluttered than the former one, but it is compatible
@@ -21391,8 +21391,8 @@ *** The ~open-source~ protocol
 a bookmark with the following location:
 
 #+begin_example
-javascript:location.href='org-protocol://open-source?&url='+
-      encodeURIComponent(location.href)
+javascript:void(location.href='org-protocol://open-source?&url='+
+      encodeURIComponent(location.href))
 #+end_example
 
 #+vindex: org-protocol-project-alist
diff --git a/lisp/org-protocol.el b/lisp/org-protocol.el
index 85c9a0cc5..c9ef10f31 100644
--- a/lisp/org-protocol.el
+++ b/lisp/org-protocol.el
@@ -97,19 +97,19 @@ ;;; Commentary:
 ;; You may use the same bookmark URL for all those standard handlers and just
 ;; adjust the sub-protocol used:
 ;;
-;;     javascript:location.href='org-protocol://sub-protocol?'+
+;;     javascript:void(location.href='org-protocol://sub-protocol?'+
 ;;           new URLSearchParams({
 ;;                 url: location.href,
 ;;                 title: document.title,
-;;                 body: window.getSelection()})
+;;                 body: window.getSelection()}))
 ;;
 ;; Alternatively use the following expression that encodes space as \"%20\"
 ;; instead of \"+\", so it is compatible with Org versions from 9.0 to 9.4:
 ;;
-;;     location.href='org-protocol://sub-protocol?url='+
+;;     javascript:void(location.href='org-protocol://sub-protocol?url='+
 ;;           encodeURIComponent(location.href)+'&title='+
 ;;           encodeURIComponent(document.title)+'&body='+
-;;           encodeURIComponent(window.getSelection())
+;;           encodeURIComponent(window.getSelection()))
 ;;
 ;; The handler for the sub-protocol \"capture\" detects an optional template
 ;; char that, if present, triggers the use of a special template.
@@ -436,15 +436,15 @@ (defun org-protocol-store-link (fname)
 
 The location for a browser's bookmark may look like this:
 
-  javascript:location.href = \\='org-protocol://store-link?\\=' +
-       new URLSearchParams({url:location.href, title:document.title});
+  javascript:void(location.href = \\='org-protocol://store-link?\\=' +
+       new URLSearchParams({url:location.href, title:document.title}));
 
 or to keep compatibility with Org versions from 9.0 to 9.4 it may be:
 
-  javascript:location.href = \\
+  javascript:void(location.href = \\
       \\='org-protocol://store-link?url=\\=' + \\
       encodeURIComponent(location.href) + \\='&title=\\=' + \\
-      encodeURIComponent(document.title);
+      encodeURIComponent(document.title));
 
 Don't use `escape()'!  Use `encodeURIComponent()' instead.  The
 title of the page could contain slashes and the location
@@ -478,24 +478,24 @@ (defun org-protocol-capture (info)
 This function detects an URL, title and optional text, separated
 by `/'.  The location for a browser's bookmark looks like this:
 
-  javascript:location.href = \\='org-protocol://capture?\\=' +
+  javascript:void(location.href = \\='org-protocol://capture?\\=' +
         new URLSearchParams({
               url: location.href,
               title: document.title,
-              body: window.getSelection()})
+              body: window.getSelection()}))
 
 or to keep compatibility with Org versions from 9.0 to 9.4:
 
-  javascript:location.href = \\='org-protocol://capture?url=\\='+ \\
+  javascript:void(location.href = \\='org-protocol://capture?url=\\='+ \\
         encodeURIComponent(location.href) + \\='&title=\\=' + \\
         encodeURIComponent(document.title) + \\='&body=\\=' + \\
-        encodeURIComponent(window.getSelection())
+        encodeURIComponent(window.getSelection()))
 
 By default, it uses the character `org-protocol-default-template-key',
 which should be associated with a template in `org-capture-templates'.
 You may specify the template with a template= query parameter, like this:
 
-  javascript:location.href = \\='org-protocol://capture?template=b\\='+ ...
+  javascript:void(location.href = \\='org-protocol://capture?template=b\\='+ ...)
 
 Now template ?b will be used."
   (let* ((parts
@@ -555,14 +555,14 @@ (defun org-protocol-open-source (fname)
 
 The location for a browser's bookmark should look like this:
 
-  javascript:location.href = \\='org-protocol://open-source?\\=' +
-        new URLSearchParams({url: location.href})
+  javascript:void(location.href = \\='org-protocol://open-source?\\=' +
+        new URLSearchParams({url: location.href}))
 
 or if you prefer to keep compatibility with older Org versions (9.0 to 9.4),
 consider the following expression:
 
-  javascript:location.href = \\='org-protocol://open-source?url=\\=' + \\
-        encodeURIComponent(location.href)"
+  javascript:void(location.href = \\='org-protocol://open-source?url=\\=' + \\
+        encodeURIComponent(location.href)")
   ;; As we enter this function for a match on our protocol, the return value
   ;; defaults to nil.
   (let (;; (result nil)
-- 
2.39.5

Re: [PATCH] org-protocol: Add void() to bookmarklets

[Max Nikulin]

On 16/12/2024 23:01, Max Nikulin wrote:
> A patch updating org-protocol.el comments, docstrings, and the manual is 
> attached.

Should ORG-NEWS be updated as well?

Re: [PATCH] org-protocol: Add void() to bookmarklets

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

> On 16/12/2024 23:01, Max Nikulin wrote:
>> A patch updating org-protocol.el comments, docstrings, and the manual is 
>> attached.
>
> Should ORG-NEWS be updated as well?

Yes, I think. In announcement section.
This is one of the cases when we want people to consider changing their
usual configs.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [PATCH] org-protocol: Add void() to bookmarklets

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

> A patch updating org-protocol.el comments, docstrings, and the manual is 
> attached.

Thanks!

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

Another variant from reddit is

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

https://old.reddit.com/r/emacs/comments/1h7ws1i/the_orgprotocol_bookmarklet_opens_a_blank_page/

Do you still prefer yours? I know close to nothing about JS.

Also, will the change work in older browsers? In non-Firefox?

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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