Hardware enable/disable switch and mozSettings, a complication and solution

[Tim Guan-tin Chien]

TL;DR: I proposed all hardware API switches to not only move out of
mozSettings database, but also have the API taking it's own
responsibility to make the settings persistent, and expose the current
value and changes through the API.

Hi,

I would like to make sure we reach a consensus on we should deal with
hardware switches and it's relations with mozSettings.

Back in FxOS v1.0 we made a mistake moving some hardware switches to
mozSettings, and it's problem to cause a lot of headaches. The boolean
in the settings is proven to be not enough to reflect the status of
API (e.g. is being enabled, or failed to be enabled) and a lot of bugs
was caused by this. People then was mostly agreed we should move the
switches back to the APIs, e.g. mozMobileConnection.setRadioEnabled()
and returns a Promise.

Yet, once the switch has been move out of the API, we have not yet
decided what we should do with mozSettings. The settings is still
needed because we would like to keep the user preference persistent
across reboot (e.g. when the radio is turned on|off, it stay on|off
when the phone reboots). But then we have the problem who is
responsible of setting and getting these settings.

1. If we let the API caller (e.g. Settings app) to set the
mozSettings, we would have to do

(A) in Settings app
mozMobileConnection.setRadioEnabled(val)
.then(function() {
return navigator.mozSettings.createLock().set( ... );
});

and (B) in Systems app when the phone boots.

navigator.mozMobileConnection.createLock().get( ... )
.then(function(value) {
return mozTelephony.setRadioEnabled(value);
});

This is undesirable because

1. Not every API switch caller do (A) has access to mozSettings should
the API become privileged, and even if they do we can never sure they
have indeed updated the settings correctly.
2. (B) currently contributes to phone boot-up time a lot, which is
documented in bug 1095034 ("Too much IndexedDB on startup").

So I talked to Hsinyi, Alive, and Arthur, and I come up with the proposal
and they agree: I propose the responsibility of keep the status should be
moved from Gaia to Gecko, specifically, each of the APIs should keep
their own status in a clean way, and simply remove the mozSettings key
altogether. The API can keep the value in Gecko pref, which we can
make sure the hardware status and the pref is always in sync, and Gaia
will take the value returned from API (a |getRadioEnabled| method for
example, or an |radioEnabled| property?) as a single source of truth.
We would also need the API to send a change event to all document when
the status changes.

Thoughts and comments? Thanks.


Tim

[Kevin Grandon]

Just curious, would this be a non-issue if we stored more information than
just a boolean? What if we stored additional information say, in JSON? Have
we thought about using datastore?

As we've seen in the past moving stuff into gecko can be a slippery slope,
so we should definitely think this out thoroughly. In any case, it seems
that this might create a more friendly API for third party developers, so a
+1 from me on that front.

It does seem like a *lot* of work though. I think it'd be worth while to do
an initial investigation on both a platform fix and a different store in
gaia to make sure we invest our time wisely.

Best,
Kevin

On Mon, Dec 29, 2014 at 9:39 PM, Tim Guan-tin Chien <timd...@mozilla.com>
wrote:

> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi
>

[Alive]

於 2014年12月30日 於 下午12:18:26, Kevin Grandon (kgra...@mozilla.com) 寫:

Just curious, would this be a non-issue if we stored more information than just a boolean? What if we stored additional information say, in JSON? Have we thought about using datastore?

I think the problem is the race. You won’t know how long the datastore/settings db will callback, and the callback from enabling to enabled really does not mean navigator.HARDWARE.status is ‘enabled’ because the database operation is async and anything could happen during the database observer operation.

But if the hardware API has status change event we could make sure we always have the correct status in the callback.

[Shian-Yow Wu]

Current:
Gaia app (e.g. Settings app) <--> mozSettings for hardware switch <-->
Gecko pref

Proposed solution:
Gaia app (e.g. Settings app) <--> API for hardware switch <--> Gecko pref

Above is my understanding, is it correct?

Maintaining two kinds of configuration for one purpose is an overhead. If
the proposed solution is the right direction, should we consider all
conditions than just hardware switches? For example, we have Gecko pref
for proxy server, but they are not configurable by user on Firefox OS. To
allow configuration by Gaia app, we can either: 1) create new API that
directly accesses Gecko pref, or 2) create new mozSettings and maintain the
mapping to Gecko pref. In such case, which way do we encourage to use?

--
Shian-Yow

[Hsin-Yi Tsai]

Hi all,

One more question: with this new proposal, how are applications going to
display "user preference" instead of a current state, like what we've
done in utility tray? Need one more attribute?

Best regards,
Hsinyi

Alive 於 12/30/2014 12:28 PM 寫道:
> 於 2014年12月30日 於 下午12:18:26, Kevin Grandon (kgra...@mozilla.com

> <mailto:kgra...@mozilla.com>) 寫:

>> Just curious, would this be a non-issue if we stored more information
>> than just a boolean? What if we stored additional information say, in
>> JSON? Have we thought about using datastore?
>
> I think the problem is the race. You won’t know how long the
> datastore/settings db will callback, and the callback from enabling to
> enabled really does not mean navigator.HARDWARE.status is ‘enabled’
> because the database operation is async and anything could happen
> during the database observer operation.
>
> But if the hardware API has status change event we could make sure we
> always have the correct status in the callback.
>
>> As we've seen in the past moving stuff into gecko can be a slippery
>> slope, so we should definitely think this out thoroughly. In any
>> case, it seems that this might create a more friendly API for third
>> party developers, so a +1 from me on that front.
>>
>> It does seem like a *lot* of work though. I think it'd be worth while
>> to do an initial investigation on both a platform fix and a different
>> store in gaia to make sure we invest our time wisely.
>>
>> Best,
>> Kevin
>>
>> On Mon, Dec 29, 2014 at 9:39 PM, Tim Guan-tin

>> Chien<timd...@mozilla.com <mailto:timd...@mozilla.com>>wrote:

>> dev-w...@lists.mozilla.org <mailto:dev-w...@lists.mozilla.org>
>> https://lists.mozilla.org/listinfo/dev-webapi
>>
>>
>

--
Hsin-Yi Tsai 蔡欣宜
Mozilla Taiwan
ht...@mozilla.com

[Tim Guan-tin Chien]

On Tue, Dec 30, 2014 at 12:40 PM, Shian-Yow Wu <s...@mozilla.com> wrote:
> Current:
> Gaia app (e.g. Settings app) <--> mozSettings for hardware switch <--> Gecko
> pref
>
> Proposed solution:
> Gaia app (e.g. Settings app) <--> API for hardware switch <--> Gecko pref
>
> Above is my understanding, is it correct?

Correct.

> Maintaining two kinds of configuration for one purpose is an overhead. If
> the proposed solution is the right direction, should we consider all
> conditions than just hardware switches? For example, we have Gecko pref for
> proxy server, but they are not configurable by user on Firefox OS. To allow
> configuration by Gaia app, we can either: 1) create new API that directly
> accesses Gecko pref, or 2) create new mozSettings and maintain the mapping
> to Gecko pref. In such case, which way do we encourage to use?

The problem with (1) (or (2), which is the current solution), is that
it is always susceptible to race unless proven otherwise.
With a simple write op to pref or settings, caller do not know when
Gecko will apply that config, or to respond when the setting failed to
apply.

The hardware switches are the most obvious cases, but I suspect almost
every other cases are affected.

On Tue, Dec 30, 2014 at 12:18 PM, Kevin Grandon <kgra...@mozilla.com> wrote:
> Just curious, would this be a non-issue if we stored more information than
> just a boolean? What if we stored additional information say, in JSON? Have
> we thought about using datastore?
>

The other approach, not mentioned on the original e-mail, is to tie
the mozSettings even closer to the API, which allow the API to
participate in the db lock and reject the changes when it fail to
apply. I suspect there will be complex settings that would need this,
but I object enabling mozSettings to do this for all APIs in general.

> As we've seen in the past moving stuff into gecko can be a slippery slope,
> so we should definitely think this out thoroughly. In any case, it seems
> that this might create a more friendly API for third party developers, so a
> +1 from me on that front.
>
> It does seem like a *lot* of work though. I think it'd be worth while to do
> an initial investigation on both a platform fix and a different store in
> gaia to make sure we invest our time wisely.
>

Yes, the efforts are non-trival. But this is one of the underlining
issues preventing FxOS to be a stable platform.
I am all ears for solutions to the problem that could solve this
cheaply -- and I want to make sure new API does not repeat the mistake
we already made.

[Tim Guan-tin Chien]

On Tue, Dec 30, 2014 at 12:44 PM, Hsin-Yi Tsai <ht...@mozilla.com> wrote:
> Hi all,
>
> One more question: with this new proposal, how are applications going to
> display "user preference" instead of a current state, like what we've done
> in utility tray? Need one more attribute?
>

Most of the time, interfaces are designed to be a both read and write
interface for user (e.g. checkbox).
I am not entirely sure what you mean by utility tray. The quick
settings buttons exhibits the same behavior.

If the user are allowed to change things and only apply when they say
so, I would imaging such UI be placed in a dialog with Back/OK buttons
(and with OK means apply now)

[Tim Guan-tin Chien]

On Tue, Dec 30, 2014 at 1:29 PM, Tim Guan-tin Chien
<timd...@mozilla.com> wrote:
> On Tue, Dec 30, 2014 at 12:40 PM, Shian-Yow Wu <s...@mozilla.com> wrote:
>> Current:
>> Gaia app (e.g. Settings app) <--> mozSettings for hardware switch <--> Gecko
>> pref
>>
>> Proposed solution:
>> Gaia app (e.g. Settings app) <--> API for hardware switch <--> Gecko pref
>>
>> Above is my understanding, is it correct?
>
> Correct.
>

Sorry, I should correct this one. I am not saying we should have a
dedicated API for hardware switches, I am saying the given hardware
API should provide the method to turn on/off given hardware, and the
API should also keep the on/off state persistent by, for example,
keeping the state in Gecko pref.

[Tim Guan-tin Chien]

Hi all,

I just talk to Hsin-Yi offline and I would like to make some
clarification here, by means of describing steps to run when the said
method is called:

A. Steps to do when setFooEnabled(false) is called:

1. If the state is not "enabled", reject the promise and stop.
2. If not, switch the property to "disabling".
2. Dispatch a property change event.
3. Submit the disable request to the relevant hardware.
4. If the request is fulfilled by the hardware,
4.1 Switch the property to "disabled".
4.2 Set the persistent state to "disabled".
4.3 Dispatch a property change event.
4.4 Resolve the promise.
5. If the request is rejected by the hardware,
5.1 Switch the property back to "enabled".
5.2 Dispatch a property change event.
5.3 Reject the promise.

B. Steps to do when the phone boots:

1. The state should start with "disabled".
2. If the persistent state is "enabled", run steps as if
|setFooEnabled(true)| is called.

The important thing to clarify is section A point 4.2: Persistent
state (e.g. Gecko pref) should not change if the request to hardware
is rejected -- therefore, a failed setFooEnabled() call should not
result any side effect.

Also, the switch state has no requirement to bind the hardware state
-- such as network state of the WIFI or RIL. It's up to the API or the
hardware to define the requirement to fulfill the hardware request
(e.g. the already connected network must be disconnect before we
fulfilled the hardware-disable request). The only requirement here is
section A point 1: to prevent race (to the hardware or the UI), we
should reject the API call when the state machine is "working" (i.e.
"enabling" or "disabling") or when the operation is simply invalid
(i.e. the state is already "disabled").

Thanks,

Tim

[Julien Wajsberg]

Le 30/12/2014 05:44, Hsin-Yi Tsai a écrit :
> Hi all,
>
> One more question: with this new proposal, how are applications going
> to display "user preference" instead of a current state, like what
> we've done in utility tray? Need one more attribute?

We can also think of the default SIM for the different Phone/SMS/Data
tasks; currently we only have the current state and no "user preference"
set, which is an issue for me because my SIM is too slow to react early
enough at startup and as a result my "preference" is never kept at reboot.

[Tim Guan-tin Chien]

Are you talking about bug 995023? That's not related to this and it's
not something can be fixed here, as long as we want to keep the
behavior of quietly disobey the user pref when a certain timing is
involved.

[Tim Guan-tin Chien]

I am sorry, EJ told me the bug is bug 1052493.
But the conclusion is the same here.


Tim

[Yoshi Huang]

Hi Tim
Will `make reset-gaia` also clear the prefs in Gecko back to original
settings?
If it couldn't, how does Gecko know it should go to the 'Default' state
instead of the previous state before rebooting?
If it could, that will surpise me because it *resets* not only gaia but
also some gecko bits.

Also the enabling/disabling states should be left to API implementation.
For example, In NFC it has different power states, the state used in P2P
sharing and in Card Emulation mode are different.
Adding many 'ING' states, IMO, could make the API difficult to use.

Thanks

On Tue, Dec 30, 2014 at 3:42 PM, Tim Guan-tin Chien <timd...@mozilla.com>
wrote:

> On Tue, Dec 30, 2014 at 1:34 PM, Tim Guan-tin Chien
> <timd...@mozilla.com> wrote:
> > On Tue, Dec 30, 2014 at 12:44 PM, Hsin-Yi Tsai <ht...@mozilla.com>
> wrote:

> >> Hi all,
> >>
> >> One more question: with this new proposal, how are applications going to
> >> display "user preference" instead of a current state, like what we've
> done
> >> in utility tray? Need one more attribute?
> >>
> >

> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-webapi
>

[Ehsan Akhgari]

I'm not sure if by Gecko "pref" you meant a preference in the usual
meaning of the word, but please note that prefs are not persisted when
you set them, and it's possible for us to lose the information if Gecko
doesn't shut down cleanly, so I don't think prefs would be the right
storage for these persistent settings.

[Jonas Sicking]

As a user, I'm not sure that this is the behavior that I want.

The most simple scenario is if I turn off wifi, but the phone crashes
before the wifi radio has been fully shut down, I think I'd prefer
that the wifi was off after bootup.

A slightly more complex scenario is if I turn on wifi, but for some
reason wifi fails to turn on, do I really want the phone to give up
rather than try again? Especially after a reboot which might actually
fix some broken state in the wifi driver? This scenario is a more
complex though since I don't know under what circumstances wifi would
actually fail to turn on?

One possible solution is to separate "desired state" from "hardware
state". So when setFooEnabled(true) is called, we'd immediately save
the new value in prefs, and then reflect "enabled" in a "desired
state" property. But the "hardware state" property would behave as you
describe above and would switch to "enabling". If turning the hardware
on fails, the "hardware state" would switch back to "disabled".
However the "desired state" would still reflect "enabled". The API
could then retry to turn on the hardware if that's appropriate.

If we did this we could technically still use mozSettings to track the
"desired state", and the individual API to track the "hardware state".
But that might just make for a more complex API. But might mean
smaller changes compared to what we have now.

I do agree that this is a more complex system though. And one that
requires UI authors to deal with more state and more complexity.

So I'm happy to go with what you are proposing if people think that
makes everyone's life simpler.

/ Jonas

[Tim Guan-tin Chien]

Hi Yoshi,

On Tue, Dec 30, 2014 at 7:14 PM, Yoshi Huang <allsta...@mozilla.com> wrote:
> Hi Tim
> Will `make reset-gaia` also clear the prefs in Gecko back to original
> settings?
> If it couldn't, how does Gecko know it should go to the 'Default' state
> instead of the previous state before rebooting?

|make reset-gaia| purges the profile, which includes prefs.js -- so
the only state should reset to the pref default.

> If it could, that will surpise me because it *resets* not only gaia but also
> some gecko bits.
>
> Also the enabling/disabling states should be left to API implementation.
> For example, In NFC it has different power states, the state used in P2P
> sharing and in Card Emulation mode are different.
> Adding many 'ING' states, IMO, could make the API difficult to use.

So it sounds like the NFC hardware are duo-purposed -- it can be
disabled, enable-to-card-emulation-mode, or enable-to-p2p-mode.

I agree it can be complex if we want to put all the states in one
|setFooEnabled(enum)| -- therefore in this example I don't think we
should, nor we most.

You can always keep the switch 2-state and introduce another 2-state
switch to switch between two enable-* states.

[Tim Guan-tin Chien]

On Wed, Dec 31, 2014 at 2:41 AM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
> I'm not sure if by Gecko "pref" you meant a preference in the usual meaning
> of the word, but please note that prefs are not persisted when you set them,
> and it's possible for us to lose the information if Gecko doesn't shut down
> cleanly, so I don't think prefs would be the right storage for these
> persistent settings.
>

Ehsan,

I mentioned Gecko pref because I think it is persistent. I am a bit
surprised that it's not -- doesn't that means my preferences in
desktop Firefox won't persist?

Does this makes the steps I described unrealistic?


Tim

[Tim Guan-tin Chien]

This can be solved if we write the pref to disk before calling the
hardware, and revert it if the hardware fail to fulfill the request.
The behavior can be kept internally to API implementations.

> A slightly more complex scenario is if I turn on wifi, but for some
> reason wifi fails to turn on, do I really want the phone to give up
> rather than try again? Especially after a reboot which might actually
> fix some broken state in the wifi driver? This scenario is a more
> complex though since I don't know under what circumstances wifi would
> actually fail to turn on?

This proposal is deliberately flawed to work with broken hardware.
Instead of quietly trying to call the hardware for the user (before
and after the reboot), the proposal is trying to be explicit to user
when hardware fail to fulfill the request(s).

> One possible solution is to separate "desired state" from "hardware
> state". So when setFooEnabled(true) is called, we'd immediately save
> the new value in prefs, and then reflect "enabled" in a "desired
> state" property. But the "hardware state" property would behave as you
> describe above and would switch to "enabling". If turning the hardware
> on fails, the "hardware state" would switch back to "disabled".
> However the "desired state" would still reflect "enabled". The API
> could then retry to turn on the hardware if that's appropriate.
>
> If we did this we could technically still use mozSettings to track the
> "desired state", and the individual API to track the "hardware state".
> But that might just make for a more complex API. But might mean
> smaller changes compared to what we have now.
>

The proposal is designed such that "desired state" and "hardware
state" is kept in sync as closely as possible, streamlining the
interfaces between three. What you are describing is what we are doing
right now -- keeping the desired state in mozSettings and have the API
to track the changes and try to achieve the described hardware state.

It's proven to be complex for both Gecko and Gaia, when the user
attempt to toggle many times in a short interval -- something fairly
common being tried by QA forks.

I) For Gecko, since there is no way to deny changes in desired state,
it would always have to "catch up" with the changes, presumably by
queue the state change and send the requests to hardware one-by-one.
II) For Gaia, we would have hard time to find the right timing for
disabling/re-enabling the UI (to express the "working" state and
provide a "cool down" period). Oh, and doing that on all toggles of
the same setting on different apps.

> I do agree that this is a more complex system though. And one that
> requires UI authors to deal with more state and more complexity.
>

Exactly.

There is one even simpler alternative: We drop the UI requirement of
(II) and ensure every Gecko API have (I) properly implemented. But
then we will get bugs like "I am able to toggle 'airplane mode' 5
times in 1 sec but the icon only shows up after 1 minute." and we
would have to argue that it's not a bug :)

[Julien Wajsberg]

(replying to dev-webapi only)

Le 31/12/2014 04:56, Tim Guan-tin Chien a écrit :
>
>> One possible solution is to separate "desired state" from "hardware
>> state". So when setFooEnabled(true) is called, we'd immediately save
>> the new value in prefs, and then reflect "enabled" in a "desired
>> state" property. But the "hardware state" property would behave as you
>> describe above and would switch to "enabling". If turning the hardware
>> on fails, the "hardware state" would switch back to "disabled".
>> However the "desired state" would still reflect "enabled". The API
>> could then retry to turn on the hardware if that's appropriate.
>>
>> If we did this we could technically still use mozSettings to track the
>> "desired state", and the individual API to track the "hardware state".
>> But that might just make for a more complex API. But might mean
>> smaller changes compared to what we have now.
>>
> The proposal is designed such that "desired state" and "hardware
> state" is kept in sync as closely as possible, streamlining the
> interfaces between three. What you are describing is what we are doing
> right now -- keeping the desired state in mozSettings and have the API
> to track the changes and try to achieve the described hardware state.

Currently, mozSettings can hold different things depending on the
setting. For the case of "current sim ID", for example, it definitely
have both in the same time: desired state when the user changes it, but
hardware state after a reboot.

I think the "reboot" use case needs to be really thought through. I
don't think that has been the case until now.

Jonas' proposal makes sense to me because we clearly separate the user
intent from the hardware state. I really think it's needed, and we don't
have this currently.
If you find another way to achieve this, I'm fine with it. But we need
to stop mixing all use cases into one value.

>
> It's proven to be complex for both Gecko and Gaia, when the user
> attempt to toggle many times in a short interval -- something fairly
> common being tried by QA forks.
>
> I) For Gecko, since there is no way to deny changes in desired state,
> it would always have to "catch up" with the changes, presumably by
> queue the state change and send the requests to hardware one-by-one.
> II) For Gaia, we would have hard time to find the right timing for
> disabling/re-enabling the UI (to express the "working" state and
> provide a "cool down" period). Oh, and doing that on all toggles of
> the same setting on different apps.
>
>> I do agree that this is a more complex system though. And one that
>> requires UI authors to deal with more state and more complexity.
>>
> Exactly.
>
> There is one even simpler alternative: We drop the UI requirement of
> (II) and ensure every Gecko API have (I) properly implemented. But
> then we will get bugs like "I am able to toggle 'airplane mode' 5
> times in 1 sec but the icon only shows up after 1 minute." and we
> would have to argue that it's not a bug :)

I'd argue it is :)

[Julien Wajsberg]

Le 30/12/2014 10:34, Tim Guan-tin Chien a écrit :

> On Tue, Dec 30, 2014 at 5:08 PM, Tim Guan-tin Chien
> <timd...@mozilla.com> wrote:
>> On Tue, Dec 30, 2014 at 4:44 PM, Julien Wajsberg <jwaj...@mozilla.com> wrote:
>>> Le 30/12/2014 05:44, Hsin-Yi Tsai a écrit :

>>>> Hi all,
>>>>
>>>> One more question: with this new proposal, how are applications going
>>>> to display "user preference" instead of a current state, like what
>>>> we've done in utility tray? Need one more attribute?

>>> We can also think of the default SIM for the different Phone/SMS/Data
>>> tasks; currently we only have the current state and no "user preference"
>>> set, which is an issue for me because my SIM is too slow to react early
>>> enough at startup and as a result my "preference" is never kept at reboot.
>>>
>> Are you talking about bug 995023? That's not related to this and it's
>> not something can be fixed here, as long as we want to keep the
>> behavior of quietly disobey the user pref when a certain timing is
>> involved.
> I am sorry, EJ told me the bug is bug 1052493.
> But the conclusion is the same here.
>
>

Let me disagree here.

If we keep 2 values -- desired value vs actual value -- we can actually
react when the first SIM finally shows up:

* after a timeout, we see only SIM 2, so we switch actual values to SIM
2. But we keep desired values to whatever the user has set
* after some ms, we see SIM 1; looking at desired values, we can decide
to switch back actual values to SIM 1.

If/when we eventually support inserting a SIM without rebooting, this
can be an issue, but I don't see this happening soon.

(note: this is my number 1 annoyance when dogfooding the Flame -- albeit
using an older build, I'd need to try a newer build)

[Jan-Ivar Bruaroey]

On 12/30/14, 9:47 PM, Jonas Sicking wrote:
> A slightly more complex scenario is if I turn on wifi, but for some
> reason wifi fails to turn on, do I really want the phone to give up
> rather than try again? Especially after a reboot which might actually
> fix some broken state in the wifi driver?

If the wifi driver is in a state where turning on wifi crashes my phone
then wont persisting the setting before success cause my phone to boot-loop?

Maybe I've been burning to many ROMs but a
weakest-link-takes-down-my-phone strategy seems bad as a systems default.

If we're going to have an async API (no opinion) then one of the
advantages seems to me to be that we can be safe about only persisting
known-good states.

.: Jan-Ivar :.

[Jan-Ivar Bruaroey]

On 12/30/14, 9:47 PM, Jonas Sicking wrote:

> A slightly more complex scenario is if I turn on wifi, but for some
> reason wifi fails to turn on, do I really want the phone to give up
> rather than try again? Especially after a reboot which might actually
> fix some broken state in the wifi driver?

If the wifi driver is in a state where turning on wifi crashes my phone
then wont persisting the setting before success cause my phone to boot-loop?

Maybe I've been burning to many ROMs but a
weakest-link-takes-down-my-phone strategy seems bad as a systems default.

If we're going to have an async API (no opinion) then one of the
advantages seems to me to be that we can be safe about only persisting
known-good states.

..: Jan-Ivar :.

[Jan-Ivar Bruaroey]

On 12/30/14, 9:47 PM, Jonas Sicking wrote:

> A slightly more complex scenario is if I turn on wifi, but for some
> reason wifi fails to turn on, do I really want the phone to give up
> rather than try again? Especially after a reboot which might actually
> fix some broken state in the wifi driver?

[Julien Wajsberg]

I think it's persisted only when the B2G process exits cleanly.

--
Julien

[Tim Guan-tin Chien]

I don't understand what you are for or against -- you comments are
contraceptive. Allow me to rephrase my previous e-mail:

If we want to take Jonas's solution, we would have to ensure all Gecko
APIs correctly handles hardware switches in [1] and never ask for
workarounds in Gaia, and we would also need consistent timing from API
to correctly do [2].

Or, we could drop [2] and accept [3] not being a bug.

===

[1] API need to allow switch toggle at all times, as described here:

...

I) For Gecko, since there is no way to deny changes in desired state,
it would always have to "catch up" with the changes, presumably by
queue the state change and send the requests to hardware one-by-one.

[2] Gaia needs right timing to disable/re-enable the UI (to express
the working state)

...

II) For Gaia, we would have hard time to find the right timing for
disabling/re-enabling the UI (to express the "working" state and
provide a "cool down" period). Oh, and doing that on all toggles of
the same setting on different apps.

[3] Remove the UI requirement of (II) and accept the following as the
right behavior

... we will get bugs like "I am able to toggle 'airplane mode' 5

times in 1 sec but the icon only shows up after 1 minute."

[Tim Guan-tin Chien]

On Wed, Dec 31, 2014 at 5:31 PM, Julien Wajsberg <jwaj...@mozilla.com> wrote:
> Let me disagree here.
>
> If we keep 2 values -- desired value vs actual value -- we can actually
> react when the first SIM finally shows up:
>
> * after a timeout, we see only SIM 2, so we switch actual values to SIM
> 2. But we keep desired values to whatever the user has set
> * after some ms, we see SIM 1; looking at desired values, we can decide
> to switch back actual values to SIM 1.
>
> If/when we eventually support inserting a SIM without rebooting, this
> can be an issue, but I don't see this happening soon.
>
> (note: this is my number 1 annoyance when dogfooding the Flame -- albeit
> using an older build, I'd need to try a newer build)
>

That would only partly fix your bug. I can already file that bug
before your solution is implemented, and it's summary would be "Active
SIM suddenly switches to SIM1 and then quietly back to 2 when the
phone boots".

The bottom-line is, we can never abstract failure/quirks of hardware
in the Platform or UI level cleanly, and I am tired of fixing the
fallout. So my intention is to streamlining the interfaces in order to
cleanly express the states to the user.

[Ehsan Akhgari]

Yes, exactly.

[Jonas Sicking]

On Tue, Dec 30, 2014 at 7:56 PM, Tim Guan-tin Chien
<timd...@mozilla.com> wrote:
> On Wed, Dec 31, 2014 at 10:47 AM, Jonas Sicking <jo...@sicking.cc> wrote:

>> A slightly more complex scenario is if I turn on wifi, but for some
>> reason wifi fails to turn on, do I really want the phone to give up
>> rather than try again? Especially after a reboot which might actually

>> fix some broken state in the wifi driver? This scenario is a more
>> complex though since I don't know under what circumstances wifi would
>> actually fail to turn on?
>
> This proposal is deliberately flawed to work with broken hardware.
> Instead of quietly trying to call the hardware for the user (before
> and after the reboot), the proposal is trying to be explicit to user
> when hardware fail to fulfill the request(s).
>

>> One possible solution is to separate "desired state" from "hardware
>> state". So when setFooEnabled(true) is called, we'd immediately save
>> the new value in prefs, and then reflect "enabled" in a "desired
>> state" property. But the "hardware state" property would behave as you
>> describe above and would switch to "enabling". If turning the hardware
>> on fails, the "hardware state" would switch back to "disabled".
>> However the "desired state" would still reflect "enabled". The API
>> could then retry to turn on the hardware if that's appropriate.
>>
>> If we did this we could technically still use mozSettings to track the
>> "desired state", and the individual API to track the "hardware state".
>> But that might just make for a more complex API. But might mean
>> smaller changes compared to what we have now.
>>
>
> The proposal is designed such that "desired state" and "hardware
> state" is kept in sync as closely as possible, streamlining the
> interfaces between three. What you are describing is what we are doing
> right now -- keeping the desired state in mozSettings and have the API
> to track the changes and try to achieve the described hardware state.

I guess what I'm saying is that I'm not convinced that this makes for
a good UX. I know that it's quite annoying when I accidentally turn on
or off some piece of hardware, and have to wait a few seconds before I
can "undo" it.

I'd rather be able to flick the switch as much as I want, and have a
status indicator next to the switch indicating if the hardware is
currently on/off/switching.

But if the complexity to make that work is really too hard, then I
agree that we might have more important things to work on.

> It's proven to be complex for both Gecko and Gaia, when the user
> attempt to toggle many times in a short interval -- something fairly
> common being tried by QA forks.
>
> I) For Gecko, since there is no way to deny changes in desired state,
> it would always have to "catch up" with the changes, presumably by
> queue the state change and send the requests to hardware one-by-one.
> II) For Gaia, we would have hard time to find the right timing for
> disabling/re-enabling the UI (to express the "working" state and
> provide a "cool down" period). Oh, and doing that on all toggles of
> the same setting on different apps.
>
>> I do agree that this is a more complex system though. And one that
>> requires UI authors to deal with more state and more complexity.
>>
>
> Exactly.
>
> There is one even simpler alternative: We drop the UI requirement of
> (II) and ensure every Gecko API have (I) properly implemented. But
> then we will get bugs like "I am able to toggle 'airplane mode' 5
> times in 1 sec but the icon only shows up after 1 minute." and we
> would have to argue that it's not a bug :)

We don't really have to queue up all changes. I.e. if the user
switches airplane mode on/off 5 times while gecko is still in the
process of turning airplane mode on for the first time, we don't need
to turn it on/off 4 more times. We'll just check the current state
compared to the desired state, and if they are not in sync change one
more time.

/ Jonas