1762640 - [meta] Form Autofill does not update its localization if the locale is changed

Status: NEW

(Toolkit :: Form Autofill, defect, P3)

Description

[Tim Giles [:tgiles]]

Various parts of Form Autofill do not change their localized text if a locale is changed via langpack. For example:

• The save/update panel will not change from English until the browser is restarted after a locale change
• The "Forms and Autofill" section in about:preferences#privacy will not update until a browser restart
• The management dialogs for both addresses and credit cards will not update until a browser restart

I'm not entirely sure why these parts do not update their localized text when the local changes...it might have something to do with Form Autofill localization not being Fluent yet or perhaps we're just not listening for localization changes in the Form Autofill module.

Comment 1

[Tim Giles [:tgiles]]

Something I've noticed is that the password manager section (Logins and Passwords) updates its localization correctly without a restart. This appears to be because there is a fluent file already for about:preferences, preferences.ftl. In this preferences file, there are sections for the various entries under the Logins and Passwords section in about:preferences. I wonder if we can utilize this file and move the strings in formautofill.properties to this preferences.ftl file? I'm sure there's more work than that, but it seems like a good starting point.

While trying to find more information on how to solve this bug, I stumbled upon Bug 1446164 which seems similar minus the webpayments part. It seems a blocker for making Form Autofill fluent was "system add-on support for Fluent which isn't ready yet", but that was four years ago...maybe things have changed? Maybe we have to create a self contained fluent file for form autofill and can't just migrate the strings to preference.ftl since form autofill is an extension? I'm not entirely sure how to verify what we could do in this situation.

If Fluent does support system add-ons though, there are guides to help migrate from legacy formats as well as tools that should help with the migration process. On first glance, it seems like the majority of the new logic to use Fluent for Form Autofill will live in formautofill/api.js

Tangentially related, the password manager experiences this same issue (but it could be that my particular steps to reproduce are invalid, since I'm not too familiar with langpacks and multi-locale builds):

1. Go https://mozilla.github.io/form-fill-examples/password_manager/login_and_pw_change_forms.html
2. Click on the first new-password field so that the "Generate a secure password" drop down appears
3. Notice that it is in English (or your default locale)
4. Download a different langpack (for Nightly/local builds, see this link to install langpacks)
5. Open browser toolbox
6. Update the requested locale so that new localization can occur

• Run Services.locale.requestedLocales = ["your lang pack"];
  • For example, Services.local.requestedLocales = ["es-ES"] for Castilian Spanish

7. Click on the new-password field from Step 2
8. Notice that the dropdown is not translated to Castilian Spanish while the rest of the browser UI is translated

You can use the previously steps for Form Autofill as well. You will need saved credit cards and/or addresses as well as using either the address test page or the credit card test page.

Comment 2

[:Gijs (he/him)]

Is this fixed now that bug 1446164 is fixed, or is there work left to do here?

Comment 3

[Tim Giles [:tgiles]]

Attachment: image.png

There is still work to be done to resolve this bug as there are parts in about:preferences#privacy that do not update when the locale is changed.

The save/update panel needs to be updated as well (but maybe that can be a separate but related bug) as there probably isn't much overlap between that code and the about:preferences code. It still does not update when the locale is changed while the browser is running.

The management dialogs for adding/editing credit cards and addresses is almost good to go. The only case I'm seeing is when the credit cards or addresses management dialog is open, then you go to add or edit an entry and then change the locale. Then the original containing dialog title is not updated but all the other parts are updated with the locale change. Seems like an outlier but needs to be fixed (like the rest of the content adjusts accordingly, no idea why the "outer" title doesn't adjust in this case.

I think it would make sense to break these problems down into separate bugs (I should have done that in the first place 🙃) and so I'll go ahead and do that and update the descriptions according. Might just turn this into a little meta bug so we don't lose any of the conversation so far.

Keeping NI open as a reminder to file dependent bugs and make this a little meta bug.

Comment 4

[Tim Giles [:tgiles]]

Alright, broke down the work into (hopefully) more manageable tasks and changed this bug to a meta.

Comment 5

[:Gijs (he/him)]

Thanks Tim!

FWIW, I came across this bug because of this comment which suggests that if we finish moving to fluent for the formautofill extension code, we can drop using a bootstrapped manifest for this.

The reason I came across that is because of bug 1370658. AIUI form autofill is the only builtin extension that has a bootstrapped manifest on release (on beta/deved/nightly we also have the webcompat reporter, which has copy-pasted the comment including the bug number...). As kmag noted in that bug,

At this point, though, we should really just stop loading chrome manifests from bootstrapped extensions. Our system extensions can be updated to register things without them, and no other extensions need them.

so I think the path forward for that performance bug is going to be removing the .properties dependencies here.

It's not really clear what the impact of the perf bug is and what if any impact that has on the importance/priority of these bugs. I'll check in on the perf bug with the perf team to try to get more clarity on that.

Comment 6

[Tim Giles [:tgiles]]

I'd love to see more .properties going away! Thanks for all the context and information Gijs, I'd be curious to see what the impact of the perf bug is...would be nice to see less main thread IO when possible!