Closed Bug 1688966 Opened 4 years ago Closed 4 years ago

Cannot launch Flatpak or rpm Zoom client from Flatpak Firefox 85

Categories

(Core :: Widget: Gtk, defect, P1)

Product:
Core
Component:
Widget: Gtk
Version:
Firefox 85
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
87 Branch
Tracking Flags:
Tracking Status
firefox-esr78 --- unaffected
firefox85 + verified
firefox86 + verified
firefox87 --- verified

People

(Reporter: ajtbecool, Assigned: jcristau)

References

(Blocks 1 open bug, Regression,
URL
)

Details

(Keywords: regression)

Attachments

(1 file)

Bug 1688966 - Backed out 1 changesets (bug 1669282) for breaking external scheme handlers on flatpak. r?gijs,jhorak
48 bytes, text/x-phabricator-request
RyanVM
: approval-mozilla-beta+
Details | Review

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:85.0) Gecko/20100101 Firefox/85.0

Steps to reproduce:

  1. Open a zoom invite link
  2. Click "Launch meeting"

Actual results:

Nothing launched.

Expected results:

In version 84 and below, the flatpak zoom client would always launch.

It also doesn't work with the Zoom .rpm.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core

Which Firefox flatpak version do you run? (from flathub or a different one) and which distro?
Thanks.

Blocks: flatpak
Flags: needinfo?(ajtbecool)
Priority: -- → P3

(In reply to Martin Stránský [:stransky] from comment #2)

Which Firefox flatpak version do you run? (from flathub or a different one) and which distro?
Thanks.

I am on Fedora Silverblue 33 using the flathub Firefox.

[andythurman@rockhopper ~]$ flatpak info org.mozilla.firefox

Firefox - Mozilla Firefox Web Browser

          ID: org.mozilla.firefox
         Ref: app/org.mozilla.firefox/x86_64/stable
        Arch: x86_64
      Branch: stable
     Version: 85.0
     License: MPL-2.0
      Origin: flathub
  Collection: org.flathub.Stable
Installation: system
   Installed: 223.6 MB
     Runtime: org.freedesktop.Platform/x86_64/20.08
         Sdk: org.freedesktop.Sdk/x86_64/20.08

      Commit: 9a8a038a5a9b30782e49cd2f8c543d83f9294d16c4988e5e98a0308d109b181e
      Parent: 4d78662527d2185df6bc1f7c7538773d5db1ba7a68e415a5328a5a56b6a9d33f
     Subject: Export org.mozilla.firefox
        Date: 2021-01-26 13:37:12 +0000

[andythurman@rockhopper ~]$ rpm-ostree status 
State: idle
Deployments:
● ostree://fedora:fedora/33/x86_64/silverblue
                   Version: 33.20210128.0 (2021-01-28T00:52:45Z)
                BaseCommit: 8612a75172b042a63d74043fc254f41c4f45f913c85d243a528e2935996a0785
              GPGSignature: Valid signature by 963A2BEB02009608FE67EA4249FD77499570FF31
       RemovedBasePackages: gnome-software gnome-software-rpm-ostree 3.38.0-2.fc33, firefox 84.0.2-1.fc33
           LayeredPackages: abrt-desktop fedora-workstation-repositories totem

  ostree://fedora:fedora/33/x86_64/silverblue
                   Version: 33.20210127.0 (2021-01-27T00:47:33Z)
                BaseCommit: 71406bae5957d4d5e103e58fe622d8de61c07dc7a5a4a5e2a98ac6fc4b9ec6c0
              GPGSignature: Valid signature by 963A2BEB02009608FE67EA4249FD77499570FF31
       RemovedBasePackages: gnome-software gnome-software-rpm-ostree 3.38.0-2.fc33, firefox 84.0.2-1.fc33
           LayeredPackages: abrt-desktop fedora-workstation-repositories totem
Flags: needinfo?(ajtbecool)

I think I have the same issue on Ubuntu/GNOME.

~ ❯ flatpak info org.mozilla.firefox

Firefox - Mozilla Firefox Web Browser

          ID: org.mozilla.firefox
         Ref: app/org.mozilla.firefox/x86_64/stable
        Arch: x86_64
      Branch: stable
     Version: 85.0
     License: MPL-2.0
      Origin: flathub
  Collection: org.flathub.Stable
Installation: system
   Installed: 223.6 MB
     Runtime: org.freedesktop.Platform/x86_64/20.08
         Sdk: org.freedesktop.Sdk/x86_64/20.08

      Commit: 9a8a038a5a9b30782e49cd2f8c543d83f9294d16c4988e5e98a0308d109b181e
      Parent: 4d78662527d2185df6bc1f7c7538773d5db1ba7a68e415a5328a5a56b6a9d33f
     Subject: Export org.mozilla.firefox
        Date: 2021-01-26 13:37:12 +0000

@ajtbecool do you have this issue with other applications as well? I noticed the same bug with Slack links.

(In reply to kaimast from comment #5)

@ajtbecool do you have this issue with other applications as well? I noticed the same bug with Slack links.

The "Open with system handler" widget works when opening files, but I'm not certain if I have any other applications to test that open links.

I am affected by the same issue. The issue is only with Firefox, other Flatpak applications (e.g. Slack) can open links as usually.

I also have this issue. This seems to be happening with all types of links Firefox doesn't handle. Instead of the typical "open with" popup or it automatically choosing an app, nothing happens. Using Firefox from flathub on Fedora 33.

Same here. I have to use a Chromium based browser as a workaround.

Only workaround I can think of is downgrading, but that will open up several issues of its own.

+1

Debian Stable, with and without backports

Only firefox, and only after recent update

status-firefox85: --- → affected

Can also reproduce with skype links

Most probably, all such "external scheme handlers" are afffected

[Tracking Requested - why for this release]:
Requesting tracking because this seems like a fairly serious issue.

tracking-firefox85: --- → ?

Martin is this something you would be able to look into?

Flags: needinfo?(stransky)

Jan Horak works on Firefox flatpak. Jan, can you look at it please?
Thanks

Flags: needinfo?(stransky) → needinfo?(jhorak)

I'm sorry to hear that, but we had to disable scheme handlers completely because of bug 1669282. When using Flatpak there's a no way to know, , whenever system supports specific scheme handler or not, so we're unable to determine if Firefox is supposed to use system handler for the scheme or try to open it.

There's a feature request to add this functionality to the flatpak portals: https://github.com/flatpak/xdg-desktop-portal-gtk/issues/330.

Flags: needinfo?(jhorak)

Thanks Jan for the pointer. That's unfortunate.

URL: https://github.com/flatpak/xdg-deskto...
status-firefox85: affected → wontfix
tracking-firefox85: ? → -

When using Flatpak there's a no way to know, , whenever system supports specific scheme handler or not, so we're unable to determine if Firefox is supposed to use system handler for the scheme or try to open it.

I'm looking at Firefox Preferences -> General -> Applications -> "Choose how Firefox handles the files you download from the web or the applications you use while browsing"

When running Firefox without flatpak, when something is set to "Always ask", there is a GUI that pops up for the user to choose the handler from available applications

When running Firefox within flatpak, this chooser only ever has one option: the equivalent of xdg-open

As a workaround for the issue, can you make it so that Firefox within flatpak always behaves as though "Always ask" is selected for non-browser protocols? So, without any user-friendly intelligence or protocol handler detection, just give the user the choice to try xdg-open or not?

Without xdg-open support, Firefox-in-flatpak user experience is very broken: I cannot use Firefox for the authentication flows in many native apps include Slack and Zoom

I'd honestly prefer a confirmation prompt with the possibility of success than silent failure

I get it, it's a tricky problem, lots of moving parts, thanks so much for looking into this

Alternatively, could you treat "localhost:port" as a special case and automatically treat it as though it is automatically destined for Firefox without looping through the OS's registered protocol handler, so that it does not flow through to xdg-open at all?

I acknowledge this is an assumption without any research, but surely nobody types in localhost:9090 into Firefox and expects another completely different application to pop-up

I would suggest that completely disabling all protocol handlers in Firefox-in-flatpak was an overly broad solution, and hopefully we can come up with a focused alternative

The problem is that the ask dialog shows up only when Firefox detects that system has a handler for the specific schema/mimetype. Currently there's no way to know the system has a handler for it. We've tried to be overoptimistic by pretending flatpak can handle all schemes. This led to showing ask dialog with System handler. But problem is that it also try to open localhost: by external application. We could put it back, whitelisting the localhost.

Can we put together list of all handlers which should not be forwarded to the system?

Having own hostname (for example in /etc/hosts) will do the same problem as with localhost. But it's rather less frequent use case.

(In reply to Jan Horak [:jhorak] from comment #16)

I'm sorry to hear that, but we had to disable scheme handlers completely because of bug 1669282. When using Flatpak there's a no way to know, , whenever system supports specific scheme handler or not, so we're unable to determine if Firefox is supposed to use system handler for the scheme or try to open it.

There's a feature request to add this functionality to the flatpak portals: https://github.com/flatpak/xdg-desktop-portal-gtk/issues/330.

So, I am as frustrated about the brokenness from bug 1669282 as anyone else, but this feels like throwing the baby out with the bathwater - we're dropping all external protocol links, even outside of the address bar, on the floor, because we don't want to annoy people who use localhost:1234 or do a search with site:mozilla.org someword in the address bar? The current state means opening any external app from a website is broken - all external video conference software, steam games, everything. I think fixing the brokenness from 1669282 this way is the wrong direction. I'm also confused why we suddenly needed to do this for 85 when the localhost: problem has been known for a long time (cf bug 1618094).

Please can we reconsider?

Flags: needinfo?(jhorak)
Flags: needinfo?(jcristau)

(In reply to :Gijs (he/him) from comment #22)

people who use localhost:1234 or do a search with site:mozilla.org someword in the address bar

It's also worth noting these two cases have a workaround - prefix http:// for the first one, or prefix ? for the second one.

AIUI the only workaround for this bug's problem is "copy-paste the link to some other app" or "use another browser".

That's fair. I'm planning on building 85.0.1 today, I can back out bug 1669282 there.

status-firefox85: wontfix → affected
tracking-firefox85: - → +
Flags: needinfo?(jcristau)
Regressed by: 1669282
Has Regression Range: --- → yes
tracking-firefox86: --- → +

Go on guys, the report for the localhost is reported on KDE (where maintainers use GTK_USE_PORTAL=1 to get native file dialogs). There's been no report on the flatpak AFAIK.

To be honest, I want the GTK/portal guys do something about it, and without some bugzilla pressure we won't make a progress.

Changing the priority to p1 as the bug is tracked by a release manager for the current release.
See What Do You Triage for more information

Priority: P3 → P1

(In reply to Jan Horak [:jhorak] from comment #25)

Go on guys, the report for the localhost is reported on KDE (where maintainers use GTK_USE_PORTAL=1 to get native file dialogs). There's been no report on the flatpak AFAIK.

I'm not entirely sure what this means, to be honest. Can you elaborate?

To be honest, I want the GTK/portal guys do something about it, and without some bugzilla pressure we won't make a progress.

I too would like the gtk/portal people to find a solution, because although I understand the idea of encapsulating things to sandbox them and so on, the current state is obviously not great. But I'm worried about making "ordinary Linux users having a hard time" the "tool" with which to force gtk/portal people to make specific changes that we want to see. Perhaps it's worth having a meeting on matrix or a video chat solution to discuss a way forward here?

I feel that it is quite unfortunate to knowingly brake an important functionality like this one.
It causes significant disruption to my workflow.

Confirmed fixed in 85.0.1

Regarding the localhost functionality, could Firefox developer edition get its own Flatpak, with tweaks like these applied for it specifically. Kind of a very hacky solution, but could kill two birds with one stone.

For those on immutable systems like me on Fedora Silverblue, Firefox is available through podman, toolbox, and docker with this functionality still available.

We landed this backout on mozilla-release for Firefox 85.0.1, but the
problem is still there in 86/87, so let's get this on trunk since the
regression is worse than the initial issue, and doesn't have a
workaround.

Backed out changeset c37b45058138 (bug 1669282)

Assignee: nobody → jcristau

Comment on attachment 9202832 [details]
Bug 1688966 - Backed out 1 changesets (bug 1669282) for breaking external scheme handlers on flatpak. r?gijs,jhorak

Beta/Release Uplift Approval Request

  • User impact if declined: 3rd party apps with external scheme handlers don't open from firefox flatpak
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): We already broke this in 85.0, then fixed it in 85.0.1, so we don't want to regress it again in 86.0
  • String changes made/needed:
Attachment #9202832 - Flags: approval-mozilla-beta?
Flags: qe-verify+
Pushed by jcristau@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/68c881bd1ac0 Backed out 1 changesets (bug 1669282) for breaking external scheme handlers on flatpak. r=Gijs

https://hg.mozilla.org/mozilla-central/rev/68c881bd1ac0

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
status-firefox87: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → 87 Branch

Comment on attachment 9202832 [details]
Bug 1688966 - Backed out 1 changesets (bug 1669282) for breaking external scheme handlers on flatpak. r?gijs,jhorak

Approved for 86.0rc1.

Attachment #9202832 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
QA Whiteboard: [qa-triaged]

Hi, I tried to reproduce this issue in order to verify the fixes but I might need a little help since I'm testing this on Ubuntu 18.04 and I'm not that familiar with the Flatpack packages.

First I tested this on a Nightly 66.0 Flatpack from flathead since it was already installed on this machine and after pasting a zoom link in the browser and Clicking the Launch Zoom button from the page nothing would happen.

Second I have installed and ran Firefox 85.0.2 from:

flatpak install flathub org.mozilla.firefox

In this Release version of Firefox when I was clicking Launch Zoom, it will open the Choose application panel and then I was able to select ZOOM and open the meeting without issues.

Then I have installed and updated the Nightly version of Firefox using the following commands :

flatpak install --from https://firefox-flatpak.mojefedora.cz/org.mozilla.FirefoxNightly.flatpakref
flatpak update org.mozilla.FirefoxNightly

and it had the same behavior as Release, clicking Launch Zoom it will prompt for the Choose application panel where I could select to open the link with system, where I could choose the ZOOM app and I would start the meeting without any issues.

And last but not least I have installed the latest version of Beta 86.0b9 using: flatpak install --user https://flathub.org/beta-repo/appstream/org.mozilla.firefox.flatpakref

but with this version of Firefox when I click Launch Zoom from the page nothing happens like in the old versions of Nightly.

Is there a way to download a Specific version of Release ? like 85.0 ? using flatpack ? where I could try to reproduce the issue ?

Also since I do not have a Fedora system can you @ajtbecool please try these links to get our latest versions of Firefox and Verify if this issue has been fixed on your end as well ? specially the beta version ?

Flags: needinfo?(jcristau)
Flags: needinfo?(ajtbecool)

I could downgrade to 85.0 with flatpak update --commit 9a8a038a5a9b30782e49cd2f8c543d83f9294d16c4988e5e98a0308d109b181e --user org.mozilla.firefox
The commit id is listed by flatpak --user remote-info --log flathub org.mozilla.firefox, by matching the release date.

Flags: needinfo?(jcristau)

I was able to reproduce the issue in 85.0 using the above command to downgrade Firefox and I was able to verify that 85.0.2 is working correctly, as well as our latest Nightly, But Beta 86.0b9 still has the issue, the moment I click the Launch Zoom button it just shows #success in the url bar but nothing happens.

I also tried to test this issue again in a fresh BETA version but for some reason it keeps updating to 86.0 Release during install which works correctly, no issues there. I'm not sure how to mark this issue , the issue only occurs in 86.0b9..

Flags: needinfo?(jcristau)

86.0b9 didn't have the fix, so if you're able to reproduce this bug there then that is expected.

Flags: needinfo?(jcristau)

This issue is Verified as fixed in 85.0.2, RC 86.0 and our latest Nightly build 87.

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-triaged]
status-firefox85: fixed → verified
status-firefox86: fixed → verified
status-firefox87: fixed → verified
Flags: qe-verify+
Flags: needinfo?(ajtbecool)

On 85.0.2 I get a menu now to select an application but not sure how to pick zoom from this? It only allows me to browse my system and I cannot even access /usr/bin or ~/.var/flatpak as Firefox's file access is restricted by flatpak.

https://www.imgpaste.net/image/Pynj6

Oh. I need to change from "Always Ask" to "System Handler" in preferences. "Always Ask" seems to be useless on Flatpak, maybe disable it there?

(In reply to kaimast from comment #45)

Oh. I need to change from "Always Ask" to "System Handler" in preferences. "Always Ask" seems to be useless on Flatpak, maybe disable it there?

Please file a separate bug with more specifics.

Flags: needinfo?(jhorak)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: