863719 - [Meta] First Time Experience/language selection & default keyboard selection work for 3rd-party keyboard support

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::System::Input Mgmt, defect, P1)

Description

[Tim Guan-tin Chien [:timdream] (please needinfo)]

STR:

1. |make reset-gaia|
2. Select [正體中文] (Traditional Chinese)
3. Going forward till reaches the wifi page
4. Select an wifi network with password

Expected:
1. Be able to type alphabets

Actual:
1. Only be able to type Chinese.

Comment 1

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Looks like keyboard_layout.json doesn't have a syntax to enable two layouts in one language.

Comment 2

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Let's mark this as part of the upgrades to Gaia on 3rd-party keyboard work.

Comment 3

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

For this issue, we have 3 areas to take care of,
 1. FTU -> language selection
 2. Settings -> language selection
 3. Build time with a given default locale

We have done this for Bug 828237 (thanks to Mihai), and we need to think of a general way to handle this for all keyboard apps.

Comment 4

[Mihai Cirlanaru [:mihai][:mcirlanaru]]

Rudy, this was fixed by the patch for bug 868001, where an array of non-latin keyboard layouts was added to keyboard_layouts.json for the purpose of enabling the English layout as well during FTU (with all the required JS logic).

Marking this bug as a duplicate of bug 868001, since Chinese was added to the non-latin list of keyboards there.

Comment 5

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Hi Mihai,

Thanks for pointing out the related work for v1.
I'd like to keep this open to make sure this part will be considered when we implement 3rd-party keyboard support.

Comment 6

[[e-mail]]

might need run time customization?

Comment 7

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Hi Mihai,

Thank you for taking a look at this.
Please be informed that,
  1. You would need the following patch before starting working on this,
     https://github.com/mozilla-b2g/gaia/pull/11527

  2. We should store enabled keyboard layouts in mozSettings, and we propose to store it as,
     "keyboard.enabled-layouts": [
       {layoutId: "en", appOrigin: "keyboard.gaiamobile.org"},
       {layoutId: "es", appOrigin: "keyboard.gaiamobile.org"}
     ]

     The layoutId is the key of the entry_point for each layout, please refer to the manifest file of Gaia keyboard app for details.

--
Please let me know if you have any questions.
Thank you.

Comment 8

[Ivan Tsay (:ITsay)]

Hi Mihai,

Thank you for taking this bug. Just a friendly reminder that this bug blocks the must have feature for v1.2. I appreciate it if this bug can be resolved by the end of our sprint 3 (8/30).

Ivan

Comment 9

[Mihai Cirlanaru [:mihai][:mcirlanaru]]

Hi Ivan, from what I understand in comment 7, I should wait for the patch of bug 858383 before starting. Let me know if this changed in any way?

I am quite familiar with the Keyboard app so it shouldn't take me more than a couple of days to submit a patch for it, that is 8/30 should be feasible.

Comment 10

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Hi Mihai,

If you want to start working on this, you may base your work on our branch in this pull request, 
https://github.com/mozilla-b2g/gaia/pull/11740

Those patches are r+'ed, so should not be changed a lot and we're going to land it asap.

BTW, I'd like to remind you of Bug 904068, in which we're going to change settings.py to JS implementation.

Thanks.

Comment 11

[Mihai Cirlanaru [:mihai][:mcirlanaru]]

Hey Rudy,

I seem to be having trouble getting the keyboard to work with the 3rd party keyboard patches applied (checked out your 3rdParty_keyboard_support_commit2 branch which was the latest one landed -- now reverted due to its side-effects on the unit tests): whenever I focus a text input field (e.g. UI tests > Keyboard) I only see a thin gray bar appearing at the bottom of the screen on the unagi (with latest gecko, clean state -- |reset-gaia|).

Do you have any idea what might be the cause of this and how I can solve it? Thanks!

Comment 12

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

If you see the gray bar then the problem is in keyboard app itself.

May I know if you used Gecko mozilla-central (m-c) to develop?
After our updates, the new keyboard app would depend on new IME WebAPI which should apppear on m-c (i.e. master branch of Gecko).

BTW, just out of curiosity, did you build Unagi device build by yourself, or you have access to our pvtbuilds?
 -- https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/nightly  

Now I am trying to get the latest pvt build to try again, I am sure yesterday's build can work.
Thanks for looking into this.

Comment 13

[Mihai Cirlanaru [:mihai][:mcirlanaru]]

> May I know if you used Gecko mozilla-central (m-c) to develop?
>
> BTW, just out of curiosity, did you build Unagi device build by yourself, or you
> have access to our pvtbuilds?

I used mozilla-b2g/B2G repo and built by myself as I don't have access to pvtbuilds. Let me know if I should be doing it differently.

Comment 14

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Then, could you check the gecko/ in your B2G repo is corresponding to m-c or not?
The simplest way to check this is to see if the commit history is the same as 
https://git.mozilla.org/?p=releases/gecko.git;a=summary.

Thank you.

--
BTW, I have checked today's pvt builds, and I found it can work.

Comment 15

[Mihai Cirlanaru [:mihai][:mcirlanaru]]

(In reply to Rudy Lu [:rudyl] from comment #14)
> Then, could you check the gecko/ in your B2G repo is corresponding to m-c or
> not?
> The simplest way to check this is to see if the commit history is the same
> as 
> https://git.mozilla.org/?p=releases/gecko.git;a=summary.
> 
> Thank you.
> 
> --
> BTW, I have checked today's pvt builds, and I found it can work.

Thanks for the info Rudy! I reflashed the phone with a build based on mozilla-central and it indeed works now.

Comment 16

[Ivan Tsay (:ITsay)]

Update keyword in white board for the status query more precise

Comment 17

[Mihai Cirlanaru [:mihai][:mcirlanaru]]

This proves to be quite a big chunk of work, taking longer than expected in some areas, so I am breaking it in smaller parts and converting this bug to a master bug -- will file the relevant bugs right away.

Comment 18

[Ivan Tsay (:ITsay)]

Remove blocking on 891674. This is not a blocker for user story 891674 (define active keyboard). This is the following up work for the enhancement of the 3rd party keyboard active setting. Keep this as koi+ to follow it up later for v1.2

Comment 19

[Jason Smith [:jsmith]]

(In reply to Ivan Tsay (:ITsay) from comment #18)
> Remove blocking on 891674. This is not a blocker for user story 891674
> (define active keyboard). This is the following up work for the enhancement
> of the 3rd party keyboard active setting. Keep this as koi+ to follow it up
> later for v1.2

Why is a meta bug being marked as a blocker? Meta bugs aren't supposed to block the release. Only the dependent actionable bugs can.

Comment 20

[Preeti Raghunath(:Preeti)]

Meta bug needn't be a blocker

Comment 21

[Jason Smith [:jsmith]]

(In reply to Preeti Raghunath(:Preeti) from comment #20)
> Meta bug needn't be a blocker

Let's just clear the nomination in that case.

Comment 22

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

This meta bug could be closed since all dependent bugs have been resolved.