959691 - Setting ril.radio.disabled in Firefox OS doesn't activate AirplaneMode

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::System, defect)

Description

[Florin Strugariu [:Bebe]]

test_dialer_airplane_mode started to fail because of Bug 948847

Bug 948847  changed how apps and Airplane mode work.
Our test sets the 'ril.radio.disabled' to True enabling the AirplaneMode


When we check the air plane icon on status bar is visible. But opening the settings app we can see that WiFi and cellar connection are available

If we try to make a call there is no warning and the call is successful. 

I think these changes are a result of Bug 948847 - [Gaia] add AirplaneModeHelper to make sure settings app and system app will not do the same thing

Comment 1

[Jason Smith [:jsmith]]

Fixed via backout.

Comment 2

[Zac C (:zac)]

Just for context, we set this setting directly in the setUp of the device so we enable airplane mode.

If there's a better way to enable airplane mode (ie via an API or something) then we can try and use that instead.

Comment 3

[EJ Chen [:eragonj][:小龍哥][Contributor mode on](inactive)]

(In reply to Florin Strugariu [:Bebe] from comment #0)
> test_dialer_airplane_mode started to fail because of Bug 948847
> 
> Bug 948847  changed how apps and Airplane mode work.
> Our test sets the 'ril.radio.disabled' to True enabling the AirplaneMode
> 
> 
> When we check the air plane icon on status bar is visible. But opening the
> settings app we can see that WiFi and cellar connection are available
> 
> If we try to make a call there is no warning and the call is successful. 
> 
> I think these changes are a result of Bug 948847 - [Gaia] add
> AirplaneModeHelper to make sure settings app and system app will not do the
> same thing

@Bebe,

can you attach your error log or a link directed to your error ?

In `test_dialer_airplane_mode.py`, I don't see any place checking the existence of icons.

Comment 4

[EJ Chen [:eragonj][:小龍哥][Contributor mode on](inactive)]

 (In reply to Zac C (:zac) from comment #2)
> Just for context, we set this setting directly in the setUp of the device so
> we enable airplane mode.
> 
> If there's a better way to enable airplane mode (ie via an API or something)
> then we can try and use that instead.

@Zac, 

I am not so familiar with Gaia UI test, here comes a question, if I want to fix `test_dialer_airplane_mode`, can I jump back to settings app to toggle airplaneMode instead of writing mozSettings directly ? Because right now in Gaia, we have only few places that can manipulate airplane mode directly (sleep_menu, checkbox in settings app, emergency call), my proposal is leaving this logic in the right place and we just toggle the checkbox (in settings) to make it change the state and then do whatever we want later. 

I think this approach is more robust than updating mozSettings key directly, any idea ?

Comment 5

[Zac C (:zac)]

(In reply to EJ Chen [:eragonj] from comment #4)
> 
> @Zac, 
> 
> I am not so familiar with Gaia UI test, here comes a question, if I want to
> fix `test_dialer_airplane_mode`, can I jump back to settings app to toggle
> airplaneMode instead of writing mozSettings directly ? Because right now in
> Gaia, we have only few places that can manipulate airplane mode directly
> (sleep_menu, checkbox in settings app, emergency call), my proposal is
> leaving this logic in the right place and we just toggle the checkbox (in
> settings) to make it change the state and then do whatever we want later. 
> 
> I think this approach is more robust than updating mozSettings key directly,
> any idea ?

@EJ, yes this is possible.

The reason why we prefer the way it is now is that if the Settings app is broken then we cannot run this test properly. It's also faster test speed to use mozSettings key. So if we can use an API or Setting we would prefer that.

We would prefer to use API or Settings key but if there is no option we can change to use the UI.

Comment 6

[Florin Strugariu [:Bebe]]

@EJ 

The error log was:
Traceback (most recent call last):
File "/var/jenkins/workspace/b2g.hamachi.mozilla-central.ui/.env/local/lib/python2.7/site-packages/marionette_client-0.7.2-py2.7.egg/marionette/marionette_test.py", line 143, in run
testMethod()
File "/var/jenkins/workspace/b2g.hamachi.mozilla-central.ui/tests/python/gaia-ui-tests/gaiatest/tests/functional/dialer/test_dialer_airplane_mode.py", line 31, in test_dialer_airplane_mode
phone.wait_for_confirmation_dialog()
File "/var/jenkins/workspace/b2g.hamachi.mozilla-central.ui/tests/python/gaia-ui-tests/gaiatest/apps/phone/app.py", line 51, in wait_for_confirmation_dialog
self.wait_for_element_displayed(*self._dialog_locator)
File "/var/jenkins/workspace/b2g.hamachi.mozilla-central.ui/tests/python/gaia-ui-tests/gaiatest/apps/base.py", line 71, in wait_for_element_displayed
raise TimeoutException('Element %s present but not displayed before timeout' % locator)
TimeoutException: Element confirmation-message present but not displayed before timeout

Also we don't check the icons but I added that after running the test and manually inspected the phone.



I guess this is fixed by your new patch. Thanks for updating our tests EJ