Android: Add search engine does not work with moz-extension URLs
Categories
(Firefox for Android :: Search, enhancement)
Tracking
()
People
(Reporter: alvinhochun, Unassigned)
References
Details
(Whiteboard: [qa-triaged])
Firefox for Android
Steps to reproduce:
On Firefox Android:
- Install Yomitan: https://addons.mozilla.org/en-US/firefox/addon/yomitan/
- On a page, open the Firefox menu, under "Extensions" select "Yomitan"
- Select "Search", then press back
- Copy the URL (should be in the form of
moz-extension://<UUID>/search.html) - Open the Firefox menu and select "Settings"
- Under "General", select "Search"
- Select "Manage alternative search engines"
- Select "Add search engine"
- Input "Yomitan" as the name
- Paste the previous URL as the search string URL, then append
?query=%sto it - 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)
| Reporter | ||
Updated•1 year ago
|
Comment 1•1 year ago
|
||
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.
Comment 2•1 year ago
|
||
When saving search engine, Firefox for android will check the url connectivity. However the moz-extension url is not supposed to pass the check.
[1] https://searchfox.org/mozilla-central/rev/f9139f56bbcc0d587966c007178910ea31df7d58/mobile/android/fenix/app/src/main/java/org/mozilla/fenix/settings/search/SaveSearchEngineFragment.kt#129
[2] https://searchfox.org/mozilla-central/rev/f9139f56bbcc0d587966c007178910ea31df7d58/mobile/android/fenix/app/src/main/java/org/mozilla/fenix/settings/search/SearchStringValidator.kt#20
[3] https://searchfox.org/mozilla-central/rev/f9139f56bbcc0d587966c007178910ea31df7d58/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/GeckoWebExecutor.java#131
Some ideas
- Do not check the url connectivity
- Check but when failed user still could forcibly save.
- Bypass checking for moz-extension url (and other possible schemes)
Comment 3•1 year ago
|
||
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).
Updated•1 year ago
|
Comment 4•1 year ago
|
||
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?
Comment 5•1 year ago
|
||
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.
Comment 6•5 months ago
|
||
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:
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.
Comment 7•5 months ago
|
||
(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.
Comment 8•5 months ago
|
||
(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-extensionurls would be dependant on the actual install? i.e. the id part ofmoz-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.
Description
•