960706 - [B2G][Settings] Unable to turn on airplane mode after turning it off

Status: RESOLVED DUPLICATE of bug 938080

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

Description

[Brogan Zumwalt [Inactive]]

Attachment: Screenshot

Description:
Turning airplane mode on through the notifications bar, then turning it off through the settings menu introduces a state where the status bar shows airplane mode is on, but the phone functions as though airplane mode is off (i.e. data, wifi, and bluetooth connections work.) Airplane mode is shown as disabled in settings at this point and can no longer be toggled through either the settings menu or notification bar. State persists even if phone is restarted.

Repro Steps:
1) Updated Buri to Build ID: 20140116040206
2) Drag down notification bar by sliding finger from top to bottom of screen
3) Tap airplane icon to turn on airplane mode
4) Press home button to dismiss notification bar
5) Open Settings app
6) Select "Airplane Mode" to toggle off

Actual:
Airplane mode still shows in status and user is unable to further toggle airplane mode on/off.

Expected:
User is able to toggle airplane mode on/off at will with status bar reflecting true status of airplane mode at all times.

Environmental Variables
Device: Buri v 1.4 Mozilla RIL
Build ID: 20140116040206
Gecko: http://hg.mozilla.org/mozilla-central/rev/324e2cba1029
Gaia: 82878ba16172213cd00ba3e8b377564b290e59c1
Platform Version: 29.0a1
Firmware Version: V1.2-device.cfg


Notes:
Repro frequency: 3/3, 100%
See attached: screenshot

Comment 1

[Brogan Zumwalt [Inactive]]

Revised STR - Step 4 IS needed for 100% repro:
Repro Steps:
1) Updated Buri to Build ID: 20140116040206
2) Drag down notification bar by sliding finger from top to bottom of screen
3) Tap airplane icon to turn on airplane mode
4) Tap bluetooth and wifi icons in notification bar
5) Press home button to dismiss notification bar
6) Open Settings app
7) Select "Airplane Mode" to toggle off

Comment 2

[Kai-Chih Hu [:khu]]

Not sure if I could nominate this bug... this looks something we should fix.

Comment 3

[Brogan Zumwalt [Inactive]]

Issue does not occur on 1.3

Result: User is able to toggle airplane mode on/off at will with status bar reflecting true status of airplane mode at all times.

Environmental Variables
Device: Buri v 1.3 Mozilla RIL
Build ID: 20140115004003
Gecko: http://hg.mozilla.org/releases/mozilla-aurora/rev/d7260b206e91
Gaia: 14e199d6a9ad917eacad883820a9f7619dbf42c8
Platform Version: 28.0a2
Firmware Version: V1.2-device.cfg

Comment 4

[Sarah Parsons]

This issue started to occur on the Buri 1.4 Build ID: 20140114040616

Gaia   002cca258af8586859c6efb2dada2fcec36754a1
SourceStamp 34dddf6f7ec1
BuildID 20140114040616
Version 29.0a1


Last working Buri 1.4 Build ID: 20140113040202

Gaia   fd3b9a97cb3c41cfa56be387b46a51db136b4422
SourceStamp 12d3ba62a599
BuildID 20140113040202
Version 29.0a1

Comment 5

[Sarah Parsons]

Also, I should add that there is a critical step missing in the STR in both comment 0 and comment 4. 

Wi-Fi MUST be enabled for this issue to occur. 

STR: 

1.Flash Buri Device to the latest master.
2.During FTU, enable wifi and connect to an access point. 
3.When on home screen drag down notification bar, and enable airplane mode. 
4.Tap on Bluetooth and Wifi to enable those too (wifi will automatically be disabled when airplane mode is turned on).
5.Press the home button, then go to Settings.
6.Disable Airplane mode.

Comment 6

[Natalya Kot [:nkot]]

per comment 3 the issue does not occur on 1.3, I've tested with 1/15 build and could not reproduce it either, however, it does reproduce on today's 1.3 build... so apparently this issue got introduced to 1.3 branch as well

here is the regression window for 1.3:

BuildID: 20140116004002
Gaia: 423326d524d3807b3a7ef9cc10f34baf26a34b8c
Gecko: 1dd80f8faa2f
Version: 28.0a2 

BuildID: 20140117004005
Gaia: a81ccdc53e45a6adeaae423e104e91bcc1e12b0e
Gecko: 2c033140eff4
Version: 28.0a2

Base: v1.2-devices.cfg

Comment 7

[Natalya Kot [:nkot]]

(In reply to Natalya Kot [:nkot] from comment #6)
> per comment 3 the issue does not occur on 1.3, I've tested with 1/15 build
> and could not reproduce it either, however, it does reproduce on today's 1.3
> build... so apparently this issue got introduced to 1.3 branch as well
> 
> here is the regression window for 1.3:
> 
> BuildID: 20140116004002
> Gaia: 423326d524d3807b3a7ef9cc10f34baf26a34b8c
> Gecko: 1dd80f8faa2f
> Version: 28.0a2 
> 
> BuildID: 20140117004005
> Gaia: a81ccdc53e45a6adeaae423e104e91bcc1e12b0e
> Gecko: 2c033140eff4
> Version: 28.0a2
> 
> Base: v1.2-devices.cfg

Sorry, correct regression window (1/15 - 1/16)

~ works ~
BuildID: 20140115004003
Gaia: 14e199d6a9ad917eacad883820a9f7619dbf42c8
Gecko: d7260b206e91
Version: 28.0a2

~ broken ~
BuildID: 20140116004002
Gaia: 423326d524d3807b3a7ef9cc10f34baf26a34b8c
Gecko: 1dd80f8faa2f
Version: 28.0a2

Comment 8

[Reuben Morais [:reuben]]

:eragonj, :arthurcc, could this be caused by bug 948847?

Comment 9

[Etienne Segonzac (:etienne)]

This may be a duplicate of bug 964974.
We hit a pass were we wait indefinitely for a DOMRequest triggering neither onsucess nor onerror.

Comment 10

[Arthur Chen [:arthurcc][inactive after 6/30]]

The issue has been existed since v1.1 and appeared in a different way. Please see bug 938080. After bug 948847 landed, it behaves as the description of this bug. The root causes of both bugs are the same.
We can resolve this issue by landing the proposed patch of bug 938080.

Comment 11

[Jason Smith [:jsmith]]

(In reply to Etienne Segonzac (:etienne) from comment #9)
> This may be a duplicate of bug 964974.
> We hit a pass were we wait indefinitely for a DOMRequest triggering neither
> onsucess nor onerror.

Probably is. If someone can fully confirm this, then feel free to dupe it.

(In reply to Arthur Chen [:arthurcc] (OOO 1/30 ~ 2/4) from comment #10)
> The issue has been existed since v1.1 and appeared in a different way.
> Please see bug 938080. After bug 948847 landed, it behaves as the
> description of this bug. The root causes of both bugs are the same.
> We can resolve this issue by landing the proposed patch of bug 938080.

The regression range seems to imply though this didn't started reproducing until recently, so I'm confused why this is arguing this was present in 1.1.

Comment 12

[Ted Clancy [:tedders1]]

I can't reproduce this.

Comment 13

[Jason Smith [:jsmith]]

QA Wanted - check if this happens on 1.3 again.

Comment 14

[Sarah Parsons]

This issue still reproduces on the Buri 1.3 Build ID: 20140131004001

Gaia   0ddcd8da5bfe1b48c73502ef29220e92f2db6b73
SourceStamp 32e45047b663
BuildID 20140131004001
Version 28.0a2

Comment 15

[Ted Clancy [:tedders1]]

Weird. I'm using a Hamachi, which has the same electronics as a Buri.

Comment 16

[Arthur Chen [:arthurcc][inactive after 6/30]]

(In reply to Jason Smith [:jsmith] from comment #11)
> (In reply to Etienne Segonzac (:etienne) from comment #9)
> > This may be a duplicate of bug 964974.
> > We hit a pass were we wait indefinitely for a DOMRequest triggering neither
> > onsucess nor onerror.
> 
> Probably is. If someone can fully confirm this, then feel free to dupe it.
> 
> (In reply to Arthur Chen [:arthurcc] (OOO 1/30 ~ 2/4) from comment #10)
> > The issue has been existed since v1.1 and appeared in a different way.
> > Please see bug 938080. After bug 948847 landed, it behaves as the
> > description of this bug. The root causes of both bugs are the same.
> > We can resolve this issue by landing the proposed patch of bug 938080.
> 
> The regression range seems to imply though this didn't started reproducing
> until recently, so I'm confused why this is arguing this was present in 1.1.

The root cause of this issue and bug 938080 are the same. It started to behave differently after bug 948847 landed.

Comment 17

[Ted Clancy [:tedders1]]

Last Friday (2014-01-31), I was able to reproduce the issue in the most recent nightly build, but I didn't see the issue in my manual build.

Today, I no longer see the issue in the most recent nightly build. I assume something was checked in Friday which fixed this issue. (I don't know specifically what, but I know there's been a lot of work regarding Airplane mode lately.)

Does QA still see this issue?

Comment 18

[Matthew Vaughan]

This issue reproduces for me on the 02/04/14 Master (1.4) build.

Environmental Variables:
Device: Buri Master (1.4) MOZ RIL
BuildID: 20140204040201
Gaia: 75e9691f02b9d18585c18a5434beeff39ee7ea20
Gecko: c150845d077d
Version: 30.0a1
Firmware Version: V1.2-device.cfg

Comment 19

[Ted Clancy [:tedders1]]

Matthew, does the issue occur for you on 1.3? This is listed as a 1.3 blocker, so right now I'm concerned about whether it happens on 1.3.

If it doesn't happen on 1.3, we can re-classify this bug as a 1.4 issue.

Comment 20

[Matthew Vaughan]

(In reply to Ted Clancy [:tedders1] from comment #19)
> Matthew, does the issue occur for you on 1.3? This is listed as a 1.3
> blocker, so right now I'm concerned about whether it happens on 1.3.
> 
> If it doesn't happen on 1.3, we can re-classify this bug as a 1.4 issue.

Sorry Ted,

Yes, this issue does reproduce on the 02/03/14 1.3 build on a Buri device.

Environmental Variables:
Device: Buri v1.3 MOZ RIL
BuildID: 20140203181708
Gaia: bb36b4164d3e51ca04b612e507e1178f80bf240d
Gecko: 9731b0b7fa78
Version: 28.0
Firmware Version: V1.2-device.cfg

Comment 21

[Kai-Chih Hu [:khu]]

Can we get ETA to fix this bug? Thank you.

Comment 22

[Arthur Chen [:arthurcc][inactive after 6/30]]

The patch for bug 938080 solves the issue and only lacks unit tests. I think we can get the patch landed on master today.

Comment 23

[Jason Smith [:jsmith]]

(In reply to Arthur Chen [:arthurcc] (OOO 1/30 ~ 2/4) from comment #22)
> The patch for bug 938080 solves the issue and only lacks unit tests. I think
> we can get the patch landed on master today.

That's not going to help here. Triage already determined that we need an alternative solution here to resolve this on 1.3, as we will not be taking bug 938080 to 1.3.

Comment 24

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

(In reply to Jason Smith [:jsmith] from comment #23)
> That's not going to help here. Triage already determined that we need an
> alternative solution here to resolve this on 1.3, as we will not be taking
> bug 938080 to 1.3.

Did triage came out with a decision based on the information given in comment 22, just 2 hours ago? If not, triage should re-visit the decision based on the new information given by the developer and find the fastest path to resolve the 1.3 bugs.

We need to be flexible here.

Comment 25

[Jason Smith [:jsmith]]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #24)
> (In reply to Jason Smith [:jsmith] from comment #23)
> > That's not going to help here. Triage already determined that we need an
> > alternative solution here to resolve this on 1.3, as we will not be taking
> > bug 938080 to 1.3.
> 
> Did triage came out with a decision based on the information given in
> comment 22, just 2 hours ago? If not, triage should re-visit the decision
> based on the new information given by the developer and find the fastest
> path to resolve the 1.3 bugs.
> 
> We need to be flexible here.

Fair enough, I'll + the dependency here then.

Comment 26

[Ted Clancy [:tedders1]]

Arthur, if you're going to be landing the patch that fixes this bug, should we reassign this bug to you?

Comment 27

[Arthur Chen [:arthurcc][inactive after 6/30]]

Thanks for reminding. Let's mark this issue as a duplicate of bug 938080. I'll leave a comment there to ensure the issue reported here gets verified afterward.