"Enable {{keyboard}} now?" dialog for bug 1029951

RESOLVED FIXED

Status

defect
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: timdream, Assigned: timdream)

Tracking

unspecified
x86
macOS
Dependency tree / graph

Firefox Tracking Flags

(feature-b2g:3.0?)

Details

(Whiteboard: [p=3])

Attachments

(1 attachment)

+++ This bug was initially created as a clone of Bug #1029951 +++

See
https://bug983043.bugzilla.mozilla.org/attachment.cgi?id=8522035#12

In order to prevent the user from disorientated between "install" (i.e. make available to System from Keyboard app) and "enable" (actually enable the keyboard in System), ask the user to enable the layout as soon as the download is completed.
I thought about adding another API method  but to prevent abuse from other 3rd-party API maybe we could just write the mozSettings directly here?

To achieve the same effect with a sane arch, alternatively, we could set that method to be certified app only in WebIDL.

:mnjul, what do you think from the input mgmt perspective?
Flags: needinfo?(jlu)
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #1)
> I thought about adding another API method  but to prevent abuse from other
> 3rd-party API maybe we could just write the mozSettings directly here?
> 
> To achieve the same effect with a sane arch, alternatively, we could set
> that method to be certified app only in WebIDL.
> 
> :mnjul, what do you think from the input mgmt perspective?

(I have not read your patch at bug 1029951 before I answer this, but I believe the answer shouldn't be different)

From the intention of keeping it certified only (which I agree), I think writing to mozSettings should be good enough -- however, this is because we already have some "shared bridge" like KeyboardHelper: since KH and InputAppList (and probably others such as DynamicInputRegistry) are already poking their hands into mozSettings, let's investigate whether those modules may be "hacked" to achieve the feature.

I understand it can be ugly that when you "ping" the --System-- Service app, you use both mozInputMethod interface and mozSettings. But I tend to think we might still need to be a bit flexible in terms of desired UX & program interface to accommodate future user feedback when the feature lands.
Flags: needinfo?(jlu)
(In reply to John Lu [:mnjul] [MoCoTPE] from comment #2)
> ... are already poking their hands into mozSettings

in order to be notified which layouts are ""enabled"" (not just available), specifically.
Assignee: nobody → timdream
Status: NEW → ASSIGNED
Comment on attachment 8597771 [details] [review]
[gaia] timdream:keyboard-dyn-enable > mozilla-b2g:master

Please pay attention to unit tests to ensure everything is covered.
Attachment #8597771 - Flags: review?(rlu)
Comment on attachment 8597771 [details] [review]
[gaia] timdream:keyboard-dyn-enable > mozilla-b2g:master

On first look, I would think that let keyboard app modify the mozSettings is not an good idea since that should be done by input management only.
However, if this is what we want from UX perspective and the other way to achieve this is through IAC or we would refine this with new inputMethod APIs, then I'm fine with it.

The code here looks good with only some typos in it, so r=me.
Thanks.
Attachment #8597771 - Flags: review?(rlu) → review+
(In reply to John Lu [:mnjul][Please NI or I'll miss] from comment #2)
> I understand it can be ugly that when you "ping" the --System-- Service app,
> you use both mozInputMethod interface and mozSettings. But I tend to think
> we might still need to be a bit flexible in terms of desired UX & program
> interface to accommodate future user feedback when the feature lands.

Side-note: "Flexible" because I believed that modifying Input Mgmt at Gecko would incur more undertaking than just poking mozSettings around at Gaia.
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.