[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: [PATCH] org-protocol: Add void() to bookmarklets

[Max Nikulin]

On 22/12/2024 19:42, Ihor Radchenko wrote:
> Max Nikulin writes:
> 
>> -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);

If you think that ";void(0)" variant is less prone to errors then I may 
update my patch. I have no idea if balanced void(...) parenthesis around 
the whole expressions would cause more user mistakes. Otherwise both 
variants are equivalent.

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

I can not figure out why it did not work without user's 
~/.local/share/applications/org-protocol.org. The only guess is that 
firefox might be confused by complex Exec entry in emacsclient.desktop. 
So I am curious if /usr/share/applications/emacsclient.desktop has 
org-protocol in MimeType (Emacs >= 29.2) and if a copy of 
emacsclient.desktop in ~/.local/share/application changes behavior in 
the absence of custom org-protocol.desktop.

I have never used bookmarklets, so I am unsure concerning behavior in 
earlier Firefox versions. Unfortunately security-related bugs are 
non-public yet, so I have not idea what has been changed. (I am not 
motivated to search for related commits.)

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

<https://en.wikipedia.org/wiki/Bookmarklet>
page has a citation that "void" appeared in JavaScript namely for 
bookmarklets and it happened in the previous century.

";undefined" instead of ";void(0)" suffix might be an issue in old 
browsers since "undefined" was added to JS ~10 years ago. I do not 
expect any problem with "void" despite I have used it only in workaround 
for a browser bug.

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

My idea is to fix existing examples in place, perhaps with a small 
remark on update reason.

Maybe experienced users of bookmarklets are aware of the "void" trick 
and provided examples were enough for them.

I consider the change as a minor fix that does not deserves loud 
announcement, especially taking into account that browsers discourages 
protocol handlers launched on behalf of web pages nowadays.

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

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

>> Another variant from reddit is
>> 
>> javascript:location.href='org-protocol://store-link?'+new URLSearchParams({url:location.href, title:document.title}); void(0);
>
> If you think that ";void(0)" variant is less prone to errors then I may 
> update my patch. I have no idea if balanced void(...) parenthesis around 
> the whole expressions would cause more user mistakes. Otherwise both 
> variants are equivalent.

Then, no need to change your variant.

>>> 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.
>
> My idea is to fix existing examples in place, perhaps with a small 
> remark on update reason.

Sure.

> Maybe experienced users of bookmarklets are aware of the "void" trick 
> and provided examples were enough for them.

The news are aiming at non-experienced users in this case.

> I consider the change as a minor fix that does not deserves loud 
> announcement, especially taking into account that browsers discourages 
> protocol handlers launched on behalf of web pages nowadays.

It is indeed minor. However, ORG-NEWS is not about minor or major, but about
answering a question: "should some users update their configuration?" or
"should some users consider changing the existing workflow?".

In this case, it is a good idea for users of the previously suggested
bookmarklet to update to the new version. This way, they will be less
likely to meet breakage one day when they decide to upgrade 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: [PATCH v2] org-protocol: Add void() to bookmarklets

[Max Nikulin]

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

On 24/12/2024 21:23, Ihor Radchenko wrote:
> Max Nikulin writes:
>>>
>>> javascript:location.href='org-protocol://store-link?'+new URLSearchParams({url:location.href, title:document.title}); void(0);
>>
>> If you think that ";void(0)" variant is less prone to errors then I may
>> update my patch. I have no idea if balanced void(...) parenthesis around
>> the whole expressions would cause more user mistakes. Otherwise both
>> variants are equivalent.
> 
> Then, no need to change your variant.

I changed the patch to trailing ";void(0)" and I have found a typo in 
first variant of the patch.

>>>> Should ORG-NEWS be updated as well?

I have realized that an example in ORG-NEWS is incomplete and so it does 
not require update.

>> I consider the change as a minor fix that does not deserves loud
>> announcement, especially taking into account that browsers discourages
>> protocol handlers launched on behalf of web pages nowadays.
[...]
> In this case, it is a good idea for users of the previously suggested
> bookmarklet to update to the new version. This way, they will be less
> likely to meet breakage one day when they decide to upgrade Firefox.

Users do not decide when they update a major browser. Security fixes 
arrive at least once a month or even more often. This particular change 
has been backported to the ESR channel, so it is too late to notify 
users through ORG-NEWS.

I have had a look into Firefox bug tracker. Behavior in respect to 
external protocol handlers has changed during a couple of years. Some of 
latest issues are not public.

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

From 6e5eb4c0aedd2ab90df6f6772ded355ccb9195a4 Mon Sep 17 00:00:00 2001
From: Max Nikulin <manikulin@gmail.com>
Date: Mon, 16 Dec 2024 21:46:49 +0700
Subject: [PATCH v2] org-protocol: Add void(0) 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 and Firefox-128.5 ESR does not discard value assigned to
window.location anymore and use it as document content to render instead.

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   |  9 +++++----
 lisp/org-protocol.el | 21 +++++++++++----------
 2 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 1b3c33f96..2d5fd57b3 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -21327,14 +21327,14 @@ *** The ~store-link~ protocol
 
 #+begin_example
 javascript:location.href='org-protocol://store-link?' +
-      new URLSearchParams({url:location.href, title:document.title});
+      new URLSearchParams({url:location.href, title:document.title});void(0);
 #+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);
+      encodeURIComponent(location.href);void(0);
 #+end_example
 
 The latter form is compatible with older Org versions from 9.0 to 9.4.
@@ -21359,6 +21359,7 @@ *** The ~capture~ protocol
       new URLSearchParams({
             template: 'x', url: window.location.href,
             title: document.title, body: window.getSelection()});
+      void(0);
 #+end_example
 
 You might have seen another expression:
@@ -21367,7 +21368,7 @@ *** The ~capture~ protocol
 javascript:location.href='org-protocol://capture?template=x'+
       '&url='+encodeURIComponent(window.location.href)+
       '&title='+encodeURIComponent(document.title)+
-      '&body='+encodeURIComponent(window.getSelection());
+      '&body='+encodeURIComponent(window.getSelection());void(0);
 #+end_example
 
 It is a bit more cluttered than the former one, but it is compatible
@@ -21400,7 +21401,7 @@ *** The ~open-source~ protocol
 
 #+begin_example
 javascript:location.href='org-protocol://open-source?&url='+
-      encodeURIComponent(location.href)
+      encodeURIComponent(location.href);void(0)
 #+end_example
 
 #+vindex: org-protocol-project-alist
diff --git a/lisp/org-protocol.el b/lisp/org-protocol.el
index 85c9a0cc5..1d3bb7e71 100644
--- a/lisp/org-protocol.el
+++ b/lisp/org-protocol.el
@@ -101,15 +101,15 @@ ;;; Commentary:
 ;;           new URLSearchParams({
 ;;                 url: location.href,
 ;;                 title: document.title,
-;;                 body: window.getSelection()})
+;;                 body: window.getSelection()});void(0)
 ;;
 ;; 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:location.href='org-protocol://sub-protocol?url='+
 ;;           encodeURIComponent(location.href)+'&title='+
 ;;           encodeURIComponent(document.title)+'&body='+
-;;           encodeURIComponent(window.getSelection())
+;;           encodeURIComponent(window.getSelection());void(0)
 ;;
 ;; The handler for the sub-protocol \"capture\" detects an optional template
 ;; char that, if present, triggers the use of a special template.
@@ -437,14 +437,14 @@ (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});
+       new URLSearchParams({url:location.href, title:document.title});void(0);
 
 or to keep compatibility with Org versions from 9.0 to 9.4 it may be:
 
   javascript:location.href = \\
       \\='org-protocol://store-link?url=\\=' + \\
       encodeURIComponent(location.href) + \\='&title=\\=' + \\
-      encodeURIComponent(document.title);
+      encodeURIComponent(document.title);void(0);
 
 Don't use `escape()'!  Use `encodeURIComponent()' instead.  The
 title of the page could contain slashes and the location
@@ -482,20 +482,21 @@ (defun org-protocol-capture (info)
         new URLSearchParams({
               url: location.href,
               title: document.title,
-              body: window.getSelection()})
+              body: window.getSelection()});void(0)
 
 or to keep compatibility with Org versions from 9.0 to 9.4:
 
   javascript:location.href = \\='org-protocol://capture?url=\\='+ \\
         encodeURIComponent(location.href) + \\='&title=\\=' + \\
         encodeURIComponent(document.title) + \\='&body=\\=' + \\
-        encodeURIComponent(window.getSelection())
+        encodeURIComponent(window.getSelection());void(0)
 
 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:location.href
+        = \\='org-protocol://capture?template=b\\='+ ...;void(0)
 
 Now template ?b will be used."
   (let* ((parts
@@ -556,13 +557,13 @@ (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})
+        new URLSearchParams({url: location.href});void(0)
 
 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)"
+        encodeURIComponent(location.href);void(0)"
   ;; 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 v2] org-protocol: Add void() to bookmarklets

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

>> Then, no need to change your variant.
>
> I changed the patch to trailing ";void(0)" and I have found a typo in 
> first variant of the patch.

Applied, onto bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=9729c60eb4

I also added an entry to ORG-NEWS:
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=0af98b8411

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

[PATCH] etc/ORG-NEWS: Clarify org-protocol bookmarklet issue

[Max Nikulin]

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

On 28/12/2024 01:13, Ihor Radchenko wrote:
> Max Nikulin writes:
> 
> I also added an entry to ORG-NEWS:
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=0af98b8411

I do not like "spawn empty page". See the attachment for another variant 
of wording.

[-- Attachment #2: 0001-etc-ORG-NEWS-Clarify-org-protocol-bookmarklet-issue.patch --]
[-- Type: text/x-patch, Size: 1262 bytes --]

From 61323321eaf0821aadb6fabf53ba4d8d8312e62a Mon Sep 17 00:00:00 2001
From: Max Nikulin <manikulin@gmail.com>
Date: Sat, 28 Dec 2024 22:45:06 +0700
Subject: [PATCH] etc/ORG-NEWS: Clarify org-protocol bookmarklet issue

---
 etc/ORG-NEWS | 13 +++++--------
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index d26813c98..03e2693e1 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -20,14 +20,11 @@ Please send Org bug reports to mailto:emacs-orgmode@gnu.org.
 
 *** You may need to update =org-protocol= bookmarklets for browsers
 
-In Firefox-133, Firefox-128.5 ESR, and later, javascript bookmarklets
-may spawn empty page.  We have updated the manual with new
-bookmarklets that do not have such problem.
-
-TL;DR: ~void(0);~ needs to be added to the bookmarklets, so that they
-do not return anything.
-
-Example:
+In Firefox-133, Firefox-128.5 ESR, provided javascript
+bookmarklet examples replace current web page with =org-protocol= URL.
+It is necessary to reload the page to restore original content.
+We have updated bookmarklets in the manual appending ~;void(0)~
+to explicitly discard expression value, for example
 
 #+begin_example
 javascript:location.href='org-protocol://store-link?url='+
-- 
2.39.5

Re: [PATCH] etc/ORG-NEWS: Clarify org-protocol bookmarklet issue

[Ihor Radchenko]

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

Max Nikulin <manikulin@gmail.com> writes:

>> I also added an entry to ORG-NEWS:
>> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=0af98b8411
>
> I do not like "spawn empty page". See the attachment for another variant 
> of wording.

You modified more than just "spawn empty page".
What about the attached?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-etc-ORG-NEWS-Improve-wording.patch --]
[-- Type: text/x-patch, Size: 1287 bytes --]

From 9425bf11ca4d56d55dbc1a37eeeb76ba90dc680d Mon Sep 17 00:00:00 2001
Message-ID: <9425bf11ca4d56d55dbc1a37eeeb76ba90dc680d.1735405057.git.yantar92@posteo.net>
From: Ihor Radchenko <yantar92@posteo.net>
Date: Sat, 28 Dec 2024 17:56:48 +0100
Subject: [PATCH] etc/ORG-NEWS: Improve wording

* etc/ORG-NEWS (You may need to update =org-protocol= bookmarklets for browsers):
Clairfy what exactly happens when old bookmarklets are used.
---
 etc/ORG-NEWS | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index a56e105481..81b2d401e4 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -20,9 +20,10 @@ Please send Org bug reports to mailto:emacs-orgmode@gnu.org.
 
 *** You may need to update =org-protocol= bookmarklets for browsers
 
-In Firefox-133, Firefox-128.5 ESR, and later, javascript bookmarklets
-may spawn empty page.  We have updated the manual with new
-bookmarklets that do not have such problem.
+In Firefox-133, and Firefox-128.5 ESR the previously suggested
+javascript bookmarklets replace current page with bookmarklet URL
+text.  We have updated the manual with new bookmarklets that do not
+have such problem.
 
 TL;DR: ~void(0);~ needs to be added to the bookmarklets, so that they
 do not return anything.
-- 
2.47.1


[-- Attachment #3: Type: text/plain, Size: 223 bytes --]


-- 
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] etc/ORG-NEWS: Clarify org-protocol bookmarklet issue

[Max Nikulin]

On 28/12/2024 23:58, Ihor Radchenko wrote:
> Max Nikulin writes:
>> I do not like "spawn empty page". See the attachment for another variant
>> of wording.
> 
> You modified more than just "spawn empty page".

It was the trigger.

> What about the attached?

After "TL;DR" I expect more verbose explanation, however if you prefer 
your variant then I would not insist on further polishing.

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

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

Have you considered reporting a bug to Firefox?

I have tried year old versions of Chromium and Firefox and have realized 
that e.g. javascript:a="test" consistently replaces document content. 
Chromium still discards expression value in the case of assignment to 
"location". So the change is specific to Firefox (including ESR channel) 
and perhaps an unintentional side effect of another fix, likely a 
security one.

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

So Firefox and Chromium behavior content scripts has diverged. Chromium 
asks permission on behalf of the current web page while Firefox treats 
as the add-on permission. Likely it is a result of
<https://bugzilla.mozilla.org/1792138>
"(CVE-2023-25729) Extensions are not prompted before opening external 
schemes, leading to security issues"

Treatment of external protocol handlers is rather inconsistent in 
browsers and it is unstable.

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]

Max Nikulin <manikulin@gmail.com> writes:
> Have you considered reporting a bug to Firefox?
>
> I have tried year old versions of Chromium and Firefox and have
> realized that e.g. javascript:a="test" consistently replaces document
> content. Chromium still discards expression value in the case of
> assignment to "location". So the change is specific to Firefox
> (including ESR channel) and perhaps an unintentional side effect of
> another fix, likely a security one.

I am not sure what I could add as my knowledge of what constitues
correct browser behavior is limited. Feel free to do so on my behalf.



>> 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).
>
> So Firefox and Chromium behavior content scripts has diverged.
> Chromium asks permission on behalf of the current web page while
> Firefox treats as the add-on permission. Likely it is a result of
> <https://bugzilla.mozilla.org/1792138>
> "(CVE-2023-25729) Extensions are not prompted before opening external
> schemes, leading to security issues"
>
> Treatment of external protocol handlers is rather inconsistent in
> browsers and it is unstable.

Not sure what to say or do about this, but thanks for letting me know. I
suppose it means that we should expect some further disruptive behavior
to extensions (not just the insecure bookmarklets) using Org-protocol,
but as you indicate it sounds like it is a wider problem.

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 28/12/2024 20:55, Rehan Deen wrote:
> Max Nikulin writes:
>>> 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).
>>
>> So Firefox and Chromium behavior content scripts has diverged.
>> Chromium asks permission on behalf of the current web page while
>> Firefox treats as the add-on permission. Likely it is a result of
>> <https://bugzilla.mozilla.org/1792138>
>> "(CVE-2023-25729) Extensions are not prompted before opening external
>> schemes, leading to security issues"
[...]
> I suppose it means that we should expect some further disruptive behavior
> to extensions (not just the insecure bookmarklets) using Org-protocol,
> but as you indicate it sounds like it is a wider problem.

I like that Firefox associate the external handler permission with the 
add-on. I am against granting permission to web sites. I do not think 
that Chromium will follow. Since content scripts working with page 
elements, they will likely be afraid that page JavaScript may fool 
content script trying to inject something malicious into external 
protocol URL.

There is extension API that allows to launch external protocol handler 
without content scripts. However there are still some corner cases.