webextPerms.description.* in mobile/android/locales/en-US/chrome/browser.properties is not used in Fenix
Categories
(GeckoView :: Extensions, task, P3)
Tracking
(Not tracked)
People
(Reporter: robwu, Unassigned)
References
Details
(Whiteboard: [geckoview:m86])
Fenix doesn't use permission strings from Gecko, but from Android-Components:
None of the strings at https://searchfox.org/mozilla-central/rev/e0eb861a187f0bb6d994228f2e0e49b2c9ee455e/mobile/android/locales/en-US/chrome/browser.properties#107-183 are currently used by GeckoView.
It's odd to host the permission warnings outside of the codebase of Gecko / GeckoView (since Gecko / GeckoView should decide which extension APIs cause permission warnings, not the GeckoView team). But if we want to stick with that decision, then we may as well remove these strings from mozilla-central.
Reporter | ||
Comment 1•4 years ago
|
||
Agi, do you recall where we made the decision to use Java to generate the permission warnings? This has potential to cause maintenance issues, e.g. if someone unaware of this adds a new API to Firefox with a permission warning that isn't present in A-C.
Comment 2•4 years ago
|
||
We should definitely remove those strings, we don't really share strings between Gecko and AC/Fenix, that's why we didn't do it here.
If a new warning is generated I think AC crashes, so we will notice. Long term we should really surface the list of permissions somewhere in the API so that apps can break the build when a new one is added.
Reporter | ||
Comment 3•4 years ago
|
||
(In reply to Agi Sferro | :agi | ⏰ PST | he/him from comment #2)
If a new warning is generated I think AC crashes, so we will notice. Long term we should really surface the list of permissions somewhere in the API so that apps can break the build when a new one is added.
Can you point to the code that is responsible for this crash? I'd like to see if it is a sustainable way to verify the existence permission warnings. AFAIK unit tests of gecko run against a special TestRunnerActivity which is independent of external apps. I would be surprised if there is any automated test coverage for verifying the completeness of the set of permission/permission warnings, but I'd gladly be proven wrong.
Comment 4•4 years ago
|
||
Right, I'm pretty sure there's nothing automated that would fail, just random people running nightly would run into this. I'm not sure where that would be in AC, I would ask in #android-components on Matrix.
Updated•4 years ago
|
Comment 5•4 years ago
|
||
Please fix this sooner rather than later, our permissions are all over the place, the likelihood of us shooting ourselves in the foot is real bad.
Comment 6•4 years ago
|
||
The problem here is more that the APP doesn't know the full list so it doesn't know if they're localizing all the possible permissions, we should expose that somewhere in the GV API.
Updated•4 years ago
|
Reporter | ||
Comment 7•4 years ago
|
||
Well there are multiple tasks here:
- Remove the unused translations from Gecko code.
- Add comments/documentation somewhere to make it obvious that new permission warnings must also be declared externally (in A-C).
- Add test or build automation that ensures that new permissions warnings in Firefox have been mirrored to A-C, if needed.
And a nice-to-have is some assurance that the translations for A-C are consistent with those that are used for Firefox, especially because those are publicly documented: https://support.mozilla.org/en-US/kb/permission-request-messages-firefox-extensions
I think that the potential for inconsistent translations can be avoided by pulling the translations from Gecko / GeckoView. I would highly recommend doing so, unless there is an actual benefit of keeping the status quo.
Updated•4 years ago
|
Updated•4 years ago
|
Reporter | ||
Comment 8•3 years ago
|
||
Reverting back the title of this bug, because the task of exposing the list of permissions has already been completed in bug 1622917.
I'll morph this bug back into the original report: the fact that there are strings that aren't used at all in GeckoView (except in unit tests).
To fix this bug, we need to remove the strings and update tests, by somehow figuring out a way to retrieve the strings in toolkit/components/extensions/test/xpcshell/test_ext_permissions.js, from the source at https://github.com/mozilla-mobile/android-components/blob/68ec5c4a3b4f412a7775ff07be7d853973ff4d6e/components/feature/addons/src/main/res/values/strings.xml#L7-L71
(see also bug 1632091 for a bug about the lack of test coverage for verification that the list of permissions and warnings are in sync)
Updated•3 years ago
|
Comment 9•2 years ago
|
||
still relevant
Updated•2 years ago
|
Comment 10•10 months ago
|
||
This was fixed in bug 1793557.
Reporter | ||
Updated•10 months ago
|
Description
•