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

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:

> 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

[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

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