1976472 - Typing query in Address Bar with colon (:) triggers SystemHandler instead of search

Status: REOPENED

(Firefox :: Address Bar, defect)

Description

[tmnk]

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

Steps to reproduce:

Type e.g. "std::vector" or "sf::Sprite" in Address Bar.

The problem started after update to Firefox 140. I'm on Ubuntu 22.04.5 LTS, Firefox is installed via snap and autoupdated.

Actual results:

Modal window shows, asking "Open the std link with System Handler?"

Expected results:

Query is passed to my default search engine.

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Hello, thank you for the bug report!
I managed to reproduce the issue on:

• Firefox 140.0.4 - Snap build;
• Firefox 141.0b9 - Snap build;
• Firefox 142.0a1 - Snap build;

Tested and reproduced on Ubuntu 22.

Setting as NEW.

Comment 3

[Marco Bonardo [:mak]]

I wonder if it's a regression from bug 1966666. Could you please check with mozregression?

Comment 4

[Emilio Cobos Álvarez [:emilio]]

Ubuntu 22.04.5 LTS

Ugh, according to https://launchpad.net/ubuntu/+source/xdg-desktop-portal, that still doesn't have https://github.com/flatpak/xdg-desktop-portal/pull/1203, so this is kind of expected...

Do we have contacts at canonical, can we get them to update the portal?

Comment 5

[:gerard-majax]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #4)

Ubuntu 22.04.5 LTS

Ugh, according to https://launchpad.net/ubuntu/+source/xdg-desktop-portal, that still doesn't have https://github.com/flatpak/xdg-desktop-portal/pull/1203, so this is kind of expected...

Do we have contacts at canonical, can we get them to update the portal?

The problem is not on canonical side but on flatpak project. That work has been again stalled. I'm not working on that anymore and Its off today so I don't have links to share but Rob and Nathan are handling this ..

Comment 6

[:gerard-majax]

Ah that's not native messaging but Nathan is still valid contact

Comment 7

[Emilio Cobos Álvarez [:emilio]]

Yeah this is not about the messaging, this is about the snap and the desktop portal.

Comment 8

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Hello,
Unfortunately I cannot get a regression range using mozregression since I could only reproduce so far on snap builds, and to my knowledge mozregression does not bisect on those. I tried using mozregression but the issue is not reproducible on the builds provided( as tar.xz builds are not affected).
Please let me know if there’s anything else I can do to help, thank you.

Comment 9

[Nathan Teodosio :nteodosio]

I backported the xdg-desktop-portal commit that Emilio mentioned to 24.04, "Added SchemeSupported to the OpenURI portal" and uploaded it to the desktop PPA.

My test shows it's working but it would be much appreciated if the affected user can confirm it, as I personally usually disable that functionality in Firefox (so I could miss something) and also because the stable release update is a long process.

I'll now proceed to attempt a backport for 22.04.

Comment 10

[Nathan Teodosio :nteodosio]

Also did a upload for 22.04.

To test, one needs to

Comment 11

[Moritz Beier [:mbeier]]

Hi Oana, could you please verify that this is fixed in Ubuntu 22.04 and 24.04?

Comment 12

[Nathan Teodosio :nteodosio]

It's not yet fixed in Ubuntu 22.04 or 24.04, the patch is awaiting SRU review in the linked bug.

One could test it by installing xdg-desktop-portal directly from the PPA I indicated though.

Comment 13

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Hello,
I can confirm that the issue is no longer reproducible after updating xdg-desktop-portal gtk to 1.14.4.1y2(using the .deb file provided in Comment 10).
Typing any query in Address Bar with single/double colons (:/::) now executes the search with the default search engine instead of opening the SystemHandler.

Tested on Ubuntu 22 on:

• Firefox Nightly 143.0a1 - snap build;
• Firefox 142.0b1-2 - snap build;
• Firefox 141.0-2 - snap build;

Comment 14

[Marco Bonardo [:mak]]

Assuming we have no control over the review process, I think there's no further work to do on our side, we'll consider it fixed upstream.

Thanks a lot for the help.

Comment 15

[ales.astone]

Is this a regression from a Firefox version adopting a new portal API? If so, I think Firefox should maintain a fallback to the previous implementation when detecting that the new portal API is not available.

We -- Ubuntu -- can try backporting the new feature, and actively are attempting to do so thanks to Nathan, but that is usually not how we handle interfaces. Ubuntu LTS interfaces are frozen in time, and users should check whether an interface is available (you can query the portal API version over dbus for that) and fallback to something else if not; it sounds like Firefox already had an implementation not using this portal API if this issue only surfaced in a recent update.

Comment 16

[Emilio Cobos Álvarez [:emilio]]

Is this a regression from a Firefox version adopting a new portal API?

Kind of, it's a regression from us removing a workaround for the lack of such an API, because it slowed down startup by doing synchronous dbus queries.

Unfortunately, without that API, on snap we can't tell reliably whether something is a known protocol or not, so we have to assume it is... I did test ubuntu, but of course this only manifests itself under snap :(

Comment 17

[ales.astone]

Chatted with Jan at GUADEC; we think it would be better to detect whether the new portal API is available (check for version 5), and fallback to always search rather than always trying to open the URI -- which Jan tells me was the behavior before this was implemented.

Comment 18

[Emilio Cobos Álvarez [:emilio]]

That would still require a dbus call on startup tho :/

Comment 19

[Emilio Cobos Álvarez [:emilio]]

Maybe we can expose a custom API and make it async, but still not amazing (because then it's basically racy until it resolves, maybe fine in practice)

Comment 20

[Marco Bonardo [:mak]]

It sounds like the bug is stalled because providing a fallback would reintroduce a performance issue on startup, due to synchronous dbus requests.
If we assume all protocols are invalid, and always search, then we break valid protocols.
The only solution would probably be to do requests asynchronously, but that seems like a lot of work for a fallback solution.
Ideas are welcome.