Default keyboard layout is hard-coded to 'en'

RESOLVED WORKSFORME

Status

Firefox OS
Gaia::Keyboard
RESOLVED WORKSFORME
6 years ago
4 years ago

People

(Reporter: Margaret, Unassigned)

Tracking

unspecified
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-basecamp:-)

Details

(Reporter)

Description

6 years ago
I think it would be better to make this a setting that changes when the locale changes.

We only fall back to this when no keyboard layout is selected in settings, so it's not a huge problem, but it would make things better.
Keyboard layout is also not beeing kept when you restart the phone. Adding the current layout as a mozSettings would fix those bugs.

Nominating because of the keyboard layout not beeing remembered between restart and I'm pretty sure this can happen without restart because we add/remove the keyboard iframe iirc.
blocking-basecamp: --- → ?
(Reporter)

Comment 2

6 years ago
The current layouts are already saved in a setting. Have you seen bug 828237?

Are the keyboard.layouts.<lang> settings not being saved? If so, that's a different bug, and that would be the blocker, not fixing the fallback layout in keyboard.js.
blocking-basecamp: ? → ---
blocking-basecamp: --- → -
tracking-b2g18: --- → +
tracking-b2g18: + → ---
Just wondering technically if 828237 is fixed, would this still be an issue?  I would think that this bug is a duplicate of that bug.
(Reporter)

Comment 4

6 years ago
(In reply to Naoki Hirata :nhirata from comment #3)
> Just wondering technically if 828237 is fixed, would this still be an issue?
> I would think that this bug is a duplicate of that bug.

Yes, this is still an issue. These are different parts of the code.

Bug 828237 is about changing the keyboard.layouts.<lang> settings when the language changes, but the user can still go in and uncheck all of those, which leads back to this default 'en' that's hardcoded into keyboard.js.
As far as I know, the hard-coded fallback in keyboard.js is to prevent the case that all keyboard layouts in settings are unchecked.

If we handled that correctly in settings app., i.e., not allowing the user to un-select all keyboard layouts.

If we want to make the keyboard app. itself fallback to correct keyboard layout according to the languages, which seems like copying the same logic that should exist in Bug 828237 to keyboard app. I don't think this is good.

-------------------------------
As of keyboard layouts settings
-------------------------------
1. Now, the set of keyboard layouts will be kept in MozSettings.
2. What Vivien mentioned in Comment 1 should mean that the last keyboard layout you are using is not persistent after reboot, which is relatively minor issue to me.


I would suggest we set this as a dupe of Bug 828237.
(Reporter)

Comment 6

6 years ago
(In reply to Rudy Lu [:rudyl] from comment #5)
> As far as I know, the hard-coded fallback in keyboard.js is to prevent the
> case that all keyboard layouts in settings are unchecked.
> 
> If we handled that correctly in settings app., i.e., not allowing the user
> to un-select all keyboard layouts.

That's bug 821646. If that is fixed, we could just remove this fallback.

Even if bug 828237 is fixed, the user could still go in and uncheck all the keyboard layouts in settings, leaving us back to this fallback.

I think we need fixes for both of those bugs before we could get rid of this default fallback check.
Just to renominate a bug. I second Rudy since Bug 821646 is talking about it should not allow 0 keyboard layout
any news on this one?
The keyboard (or input method) architecture has changed a lot since we start to enable 3rd-party keyboard into our eco system.
Right now, the keyboard app would not have this fallback mechanism, and rely on system to tell it which layout it should display.
At the time, the settings would not allow the user to un-check all the keyboard layouts, IIRC.

So, let's close this old bug as worksforme.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.