[-- Attachment #1: Type: text/plain, Size: 754 bytes --] Hello, I've just upgraded to Kubuntu 22.04. Firefox is no longer instsallable via apt so I chose flatpak over snap. Now when I C-c C-o (org-open-at-point) on a URL, Firefox comes to the foreground, but nothing else happens. The page does not load. If I 'xdg-open URL' then the URL loads, so the system outside of emacs does interact correctly with the flatpak app. Can anyone advise how to get Org (or emacs) to play well with 3rd-party flatpak'd apps? /grumble - I get that these new installation methods are solving a dependency problem, but it feels like a step backward. I can't drag-and-drop images onto some apps, icons appear as generic X11 rather than the app icon in the task switcher, etc. Oh well. I guess this is progress. Thanks, -k. [-- Attachment #2: Type: text/html, Size: 936 bytes --]
Ken Mankoff <mankoff@gmail.com> writes: > Hello, > > I've just upgraded to Kubuntu 22.04. Firefox is no longer instsallable via apt so I chose flatpak over snap. Now when I C-c C-o > (org-open-at-point) on a URL, Firefox comes to the foreground, but nothing else happens. The page does not load. If I 'xdg-open URL' > then the URL loads, so the system outside of emacs does interact correctly with the flatpak app. > > Can anyone advise how to get Org (or emacs) to play well with 3rd-party flatpak'd apps? > > /grumble - I get that these new installation methods are solving a dependency problem, but it feels like a step backward. I can't > drag-and-drop images onto some apps, icons appear as generic X11 rather than the app icon in the task switcher, etc. Oh well. I guess this > is progress. > > Thanks, > > -k. Note that you can install the deb version of firefox in Ubuntu 22.04 by adding the firefox PPA. See https://askubuntu.com/questions/1399383/how-to-install-firefox-as-a-traditional-deb-package-without-snap-in-ubuntu-22
On 02/07/2022 23:03, Ken Mankoff wrote:
>
> I've just upgraded to Kubuntu 22.04. Firefox is no longer instsallable
> via apt so I chose flatpak over snap. Now when I C-c C-o
> (org-open-at-point) on a URL, Firefox comes to the foreground, but
> nothing else happens. The page does not load. If I 'xdg-open URL' then
> the URL loads, so the system outside of emacs does interact correctly
> with the flatpak app.
Please, seek for various messages reported during this action:
- Emacs *Messages* buffer (C-h C-e)
- Firefox console (Ctrl+Shift+J)
- stderr of the Firefox process, unsure where it can be expected for
flatpak apps: terminal application from which Firefox was initially
started, output of "journalctl --user", in earlier days X11 errors may
be saved to ~/.xsession-errors
- flatpak may have its own log file.
It is rather strange that Firefox receives some event, xdg-open works in
isolation, but not from Emacs. What does happen when
- `browse-url' is called from Emacs,
- a link is activated in an Org document when Firefox application is closed?
Notice that you did not specify which versions of Emacs and Org you have
installed (M-x org-version), and the source of the package: bundled with
emacs, elpa-org deb package, Emacs ELPA package, etc.
Hi Max,
Thanks for the debugging suggestions. It helped me figure out that the problem was us usual human error.
Emacs opens URLs in the last-active (from the UI perspective) firefox, even if there is a firefox on the current virtual desktop. I had "browse-url-generic-program" set to a script that used xdotool to find if there was a firefox on this desktop, and then sent the URL there. xdotool doesn't play nice withe flatpak, and that was the problem.
Thanks again for the suggestions,
-k.
On 2022-07-02 at 20:46 -07, Max Nikulin <manikulin@gmail.com> wrote:
> On 02/07/2022 23:03, Ken Mankoff wrote:
>> I've just upgraded to Kubuntu 22.04. Firefox is no longer
>> instsallable via apt so I chose flatpak over snap. Now when I C-c
>> C-o (org-open-at-point) on a URL, Firefox comes to the foreground,
>> but nothing else happens. The page does not load. If I 'xdg-open
>> URL' then the URL loads, so the system outside of emacs does
>> interact correctly with the flatpak app.
>
> Please, seek for various messages reported during this action:
> - Emacs *Messages* buffer (C-h C-e)
> - Firefox console (Ctrl+Shift+J)
> - stderr of the Firefox process, unsure where it can be expected for
> flatpak apps: terminal application from which Firefox was initially
> started, output of "journalctl --user", in earlier days X11 errors may
> be saved to ~/.xsession-errors
> - flatpak may have its own log file.
>
> It is rather strange that Firefox receives some event, xdg-open works
> in isolation, but not from Emacs. What does happen when
> - `browse-url' is called from Emacs,
> - a link is activated in an Org document when Firefox application is closed?
>
> Notice that you did not specify which versions of Emacs and Org you
> have installed (M-x org-version), and the source of the package:
> bundled with emacs, elpa-org deb package, Emacs ELPA package, etc.
On 03/07/2022 20:25, Ken Mankoff wrote: > Emacs opens URLs in the last-active (from the UI perspective) firefox, > even if there is a firefox on the current virtual desktop. Is it Emacs of Firefox behavior? However it is not trivial to choose which window should be used to open a new URL if a couple of monitors, virtual desktops, and contextual identities are involved. > I had "browse-url-generic-program" set to a script that used xdotool to > find if there was a firefox on this desktop, and then sent the URL > there. xdotool doesn't play nice withe flatpak, and that was the problem. I am not an X11 expert but it sounds strange. The protocol is designed to work across network, so it should not matter whether some application is running from flatpak. May it happen that after upgrade Wayland session is used instead of X11? Though in such case I would expect that xdotool should be rather broken due to stricter security model. Out of curiosity, what is the reason why you are avoiding firefox as a snap package? It should be tested better on Ubuntu. I do not like it because instead of decentralized apt mirrors it forces to use fixed source of packages, upgrade policy is not clear to me as well. My impression is that priorities related to application isolation is not consistent with my expectations. I understand reasons behind decision of Canonical to drop .deb package, but I still do not like them: browser packages are too expensive to build, not to mention long time support promise conflict with desire of developers to use modern tools.
Hi Max, Sorry for the delayed reply. On 2022-07-05 at 08:16 -07, Max Nikulin <manikulin@gmail.com> wrote: > On 03/07/2022 20:25, Ken Mankoff wrote: >> I had "browse-url-generic-program" set to a script that used xdotool >> to find if there was a firefox on this desktop, and then sent the URL >> there. xdotool doesn't play nice withe flatpak, and that was the >> problem. > > I am not an X11 expert but it sounds strange. The protocol is designed > to work across network, so it should not matter whether some > application is running from flatpak. May it happen that after upgrade > Wayland session is used instead of X11? Though in such case I would > expect that xdotool should be rather broken due to stricter security > model. As you suggested, the problem was not xdotool or X11. It was simply that instead of calling firefox "${1}" & to open the URL, I needed to call flatpak run org.mozilla.firefox "${1}" & > Out of curiosity, what is the reason why you are avoiding firefox as a > snap package? I'm not 100 % sure why but I don't like snap. Maybe because it pollutes the home folder. I read up on snap vs flatpak vs AppImage and flatpak seemed to get the best reviews, so I've gone with that one. -k.
Ken Mankoff <mankoff@gmail.com> writes:
>
>> Out of curiosity, what is the reason why you are avoiding firefox as a
>> snap package?
>
> I'm not 100 % sure why but I don't like snap. Maybe because it pollutes the home folder. I
> read up on snap vs flatpak vs AppImage and flatpak seemed to get the best reviews, so I've
> gone with that one.
>
There has been a real issue with startup times for snap based
firefox. While there have been some improvements very recently, the snap
version is still significantly slower to start than the flatpak version
(on my system, it was taking over 25 seconds! This is on a 20 core i7
with 32Gb RAM and SSD).
I recently switched from Ubuntu (which favours snap) to Fedora (which
favours flatpak). However, when I was on Ubuntu, I actually replaced the
snap version with the deb version (this is still possible, but people
don't necessarily know that) because it was so much faster to start. I
think the deb/rpm based versions are still the fastest, but flatpak
opens firefox within just a couple of seconds on the same hardware where
snap took 25.