As per ringtone settings (see bug 1024779), the keyboard settings architecture is causing unexpected behaviours with transitions, launch screens, task manager and sheets. Steps to Reproduce - Launch Settings - Tap Keyboards - Tap on the "Built-in Keyboard" or "Demo Keyboard" links Actual Behaviour - Transition to the new view does not follow the standard view transition - App launch screen is displayed - Separate "Keyboard" app shows in the task switcher - Left edge gesture returns the user to the main Settings page Expected Behaviour For 2.0 we'd like to maintain the illusion that the keyboard settings are part of the settings app. Etienne is recommending the use of an inline activity to accomplish this. Although the transitions will vary from the standard view transitions, the keyboard settings will at least not launch a new separate app. So the launch screen would not appear, the sheets behaviour would not be broken, and no separate app would show up in the task switcher.

NI'ing Jenny and Omega as an FYI - Feel free to NI me with any questions. Thanks!

(In reply to Rob MacDonald [:robmac] from comment #1) > NI'ing Jenny and Omega as an FYI - Feel free to NI me with any questions. > Thanks! Rob, this is technically impossible. We are having 3rd party keyboard so we cannot do activity to launch them. Please read https://bugzilla.mozilla.org/show_bug.cgi?id=1023046#c18

Etienne ^ AFAIK we don't have any solution to this issue right now.

If we can only launch keyboard app now, how about making it really like launching an app rather than pretending they are the same app. For example, using different color headers, using "X" instead of "<", etc.

More clearly, In keyboard panel of Settings app, there are columns of each keyboard settings, it is 1 to 1 mapping for each install keyboard apps. Web activity is exactly 1 to many mapping around one activity name. We cannot launch the keyboard settings by activity otherwise the UX will become strange. For instance, user has 2 keyboard apps installed, one is A and one is B. There will be <Keyboard> Keyboard A - [Settings Icon] Keyboard B - [Settings Icon] And press settings icon of keyboard app A should access the settings of keyboard A, press settings icon of keyboard app B should access the settings of keyboard B. 1. If we want to invent a new activity 'keyboard_config', we will run into an activity menu like [Keyboard A] [Keyboard B] [Cancel] After pressing any of the settings icon. 2. If we want to invent different activity name for each keyboard, I wonder this is a misuse of web activity and that also means settings app won't know the activity name of the new install keyboard until it parses the manifest of the keyboard app, hence it cannot add a column inside keyboard app. Anyway the original mechanism is invented by keyboard owners so I am looping them in.

I agree using the activity menu in this way is actually worse than the original problem. I wouldn't object to deferring this to 2.1 if Jenny and Omega agree.

This is new feature, no blocking.

Arthur and I think the proper fix should be depend on bug 1020063 -- we should embed the keyboard settings in the Settings app so these panels are literally in the same app (from the window management perspective).

(In reply to Rob MacDonald [:robmac] from comment #6) > I agree using the activity menu in this way is actually worse than the > original problem. I wouldn't object to deferring this to 2.1 if Jenny and > Omega agree. Agree that this issue should depend on bug 1020063. UX side will continue discuss proper behavior for 3rd party app, tks!

Firefox OS is not being worked on