Open Bug 1900568 Opened 1 year ago Updated 5 months ago

Android: Add search engine does not work with moz-extension URLs

Categories

(Firefox for Android :: Search, enhancement)

Firefox 127
Unspecified
Android
enhancement

Tracking

()

People

(Reporter: alvinhochun, Unassigned)

References

Details

(Whiteboard: [qa-triaged])

Firefox for Android

Steps to reproduce:

On Firefox Android:

  1. Install Yomitan: https://addons.mozilla.org/en-US/firefox/addon/yomitan/
  2. On a page, open the Firefox menu, under "Extensions" select "Yomitan"
  3. Select "Search", then press back
  4. Copy the URL (should be in the form of moz-extension://<UUID>/search.html)
  5. Open the Firefox menu and select "Settings"
  6. Under "General", select "Search"
  7. Select "Manage alternative search engines"
  8. Select "Add search engine"
  9. Input "Yomitan" as the name
  10. Paste the previous URL as the search string URL, then append ?query=%s to it
  11. Press "Save"

Actual results:

An error message appears below the URL:

Error connecting to "Yomitan"

Expected results:

The search engine should be saved without errors.

(Firefox Beta 127.0b8)

OS: Unspecified → Android

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

Component: Untriaged → General
Product: Firefox → Fenix

Confirming this as a feature request/enhancement. I can reproduce the behavior on Firefox Nightly 128.0a1, Beta 127.0b9 and RC 127.0 with Samsung Galaxy S22 Ultra (Android 14).

Severity: -- → N/A
Status: UNCONFIRMED → NEW
Type: defect → enhancement
Ever confirmed: true
Whiteboard: [qa-triaged]
Component: General → Search

I'm not sure if this is something that's intended to be supported for WebExtensions to be used in this way.

I think the better and safer option would be to implement the omnibox API (bug 1427501), this would also mean that if the add-on was removed, then the associated search parts would also be cleaned up.

Maybe the add-on teams have some thoughts?

Flags: needinfo?(tomica)
See Also: → 1427501

We're supportive of skipping the connectivity check for moz-extension:-URLs. If any, it is only necessary to check whether the extension is installed. Currently, extensions that really want to could work around the current limitation by asking the user to set a dummy http(s) URL, and using the extension to intercept and redirect that dummy URL to the extension. That is a terribly work-around, and we prefer that users can just specify the moz-extension:-URL instead of requiring extensions to implement this hacky work-around.

The omnibox API would be nice, but that also requires extensions to cooperate by implementing the API. I see value for both features co-existing.

Flags: needinfo?(tomica)

Currently this bug only covers Android, but this limitation exists in desktop versions of Firefox as well. On desktop, the Add Search Engine UI in about:settings#search UI requires requires that the user-provided URL has either a "http:" or "https:" protocol. The logic for the form validator can be found here:

https://searchfox.org/firefox-main/rev/16707ce1df112d9e067175ed8e16be717ab684c4/browser/components/search/content/addEngine.js#138

I'm not authoritative on this UI is implemented, but while looking into this I didn't see any additional validation logic for the user-provided URL in that file or toolkit/components/search/UserSearchEngine.sys.mjs.

https://searchfox.org/firefox-main/rev/16707ce1df112d9e067175ed8e16be717ab684c4/toolkit/components/search/UserSearchEngine.sys.mjs

(In reply to Rob Wu [:robwu] from comment #5)

We're supportive of skipping the connectivity check for moz-extension:-URLs. If any, it is only necessary to check whether the extension is installed.

Am I correct in thinking that these moz-extension urls would be dependant on the actual install? i.e. the id part of moz-extension://<id>/ changes with each install?

So the extension would have to present the correct URL to the user, and then the user would have to copy & paste across (or maybe "Add search engine" on a field on the page).

That presumably would mean that we cannot sync those search engines, because the URL would be different across each client that the user has hooked up to sync, or do we have some existing way of managing those urls across devices?

(In reply to Simeon Vincent [:dotproto] from comment #6)

Currently this bug only covers Android, but this limitation exists in desktop versions of Firefox as well.

Desktop will need a separate issue, as it is a different code base.

Flags: needinfo?(rob)

(In reply to Mark Banner (:standard8) from comment #7)

(In reply to Rob Wu [:robwu] from comment #5)

We're supportive of skipping the connectivity check for moz-extension:-URLs. If any, it is only necessary to check whether the extension is installed.

Am I correct in thinking that these moz-extension urls would be dependant on the actual install? i.e. the id part of moz-extension://<id>/ changes with each install?

Yes. And it is not just being installed, but also enabled AND available. An installed-and-enabled extension can be unavailable in private windows if the user has not granted access to private windows, for example.

So the extension would have to present the correct URL to the user, and then the user would have to copy & paste across (or maybe "Add search engine" on a field on the page).

Currently yes.

That presumably would mean that we cannot sync those search engines, because the URL would be different across each client that the user has hooked up to sync, or do we have some existing way of managing those urls across devices?

If we want to sync, we would have to special-case this by sharing the extension ID. The extension ID-UUID mapping is stored in a pref, but I don't know if that pref is synced (I expect not, but never checked).

There have been plenty of cases where a public URL based on the extension ID is desired. I wouldn't be opposed to introducing a new well-known alias for the current moz-extension URLs.

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