1060232 - [Woodduck][WIFI] Cannot forget AP via known network

Status: RESOLVED FIXED

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

Description

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

Tested on latest 2.0 build on flame.

If we connect to an AP first (no matter it is encrypted or not) and want to remove it from "Manage Networks" panel, we are not able to remove at the first time.

All we can do is try to remove again or jump back to previous panel and then jump back again.

If we check statusbar at the moment, we can notice wifi is disconnected but the AP is still on the list, based on this observation, this can be UI inconsistent problem and not related to functionalities. 

STR :

1. open settings
2. click on wifi panel
3. connect to any AP first
4. click on "Manage network" button
5. click on the AP to remove it and press confirm button

Actual Result :

AP is still there and is clickable 

Expected Result :

AP is not there 

-- Device Information --

Gaia      5bf3b8cdea15e62ce7bf77a15085a18e24e33c44
Gecko     https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/5bcf98ed9885
BuildID   20140828160259
Version   32.0
ro.build.version.incremental=eng.cltbld.20140602.192604
ro.build.date=Mon Jun  2 19:26:18 EDT 2014
B1TC400110G0

Comment 1

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

Attachment: patch on master

Arthur, 

this is a known bug fixed by us in 2.1 but still intact on 2.0.

After checking the code, it's still the same timing issue as what we discussed before and I think we can easily use a callback to make sure the calling sequence is right.

There is one same bug talking about this problem in dependency list (for partners), but because on Flame, I can see this problem os I prefer to file this one to make sure we can ask CI to run all tests at the same time.

Hope this information helps, thanks :)

Comment 2

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

Comment on attachment 8481113 [details] [review]
patch on master

r=me with the comment addressed. Please also add appropriate flags ensuring this gets uplifted to v2.0, thanks!

Comment 3

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

[Blocking Requested - why for this release]:

Currently on v2.0, we have to double click on "forget network" button to forget memorized wifi and this would impact user experiences. And because on 2.1, this bug has been fixed due to wifi refactor work, this bug would focus on v2.0 fix.

Comment 4

[Jason Smith [:jsmith]]

QA Wanted for branch checks.

Comment 5

[Yeojin Chung [:YeojinC]]

This issue does NOT reproduce on the latest Flame 2.1, Flame 2.0, Flame 1.4, and Open C 2.1:

Flame 2.1

Environmental Variables:
Device: Flame Master
BuildID: 20140902111800
Gaia: 7e469783859785a8bd4bf02a802f32561c84be7b
Gecko: c24ec895b156
Version: 35.0a1 (Master) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Flame 2.0

Environmental Variables:
Device: Flame 2.0
BuildID: 20140901103053
Gaia: 449d8db9b3ea1f9262db822c37ef2143477172b7
Gecko: 40d74e0bbcf5
Version: 32.0 (2.0) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Flame 1.4

Environmental Variables:
Device: Flame 1.4
BuildID: 20140827090228
Gaia: 05653cb12d324649687dad3eeb2ea373a2ad84d4
Gecko: baf01c5965ef
Version: 30.0 (1.4) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Open C 2.1

Environmental Variables:
Device: Open_C Master
Build ID: 20140902111800
Gaia: 7e469783859785a8bd4bf02a802f32561c84be7b
Gecko: c24ec895b156
Version: 35.0a1 (Master)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

"No known networks" messages appears when the user confirms to forget the network under 'Manage networks' panel for the first time.

I was able to reproduce this issue on the original build(Nightly). However, this issue does NOT reproduce on the latest nightly Flame 2.0 build:

Environmental Variables:
Device: Flame 2.0
BuildID: 20140902000202
Gaia: 449d8db9b3ea1f9262db822c37ef2143477172b7
Gecko: 40d74e0bbcf5
Version: 32.0 (2.0) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 6

[Joshua Mitchell (Inactive)]

This issue does not seem to be reproducing in the latest.

Comment 7

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

I just tested again and it still happened : 

-- device info --
Gaia      449d8db9b3ea1f9262db822c37ef2143477172b7
Gecko     https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/13b41e22c8f6
BuildID   20140902160207
Version   32.0
ro.build.version.incremental=eng.cltbld.20140602.192604
ro.build.date=Mon Jun  2 19:26:18 EDT 2014
B1TC400110G0

No matter how, tracing from codebase, there is still a flaw would make this happen and I already had a r+ patch for it, so I would still land it after CI is green to make code robust.

Comment 8

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

Comment on attachment 8481113 [details] [review]
patch on master

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #):
[User impact] if declined: User have to tap "forget network" twice to forget specific wifi, 
[Testing completed]: No test for this because it is just a calling sequence problem
[Risk to taking this patch] (and alternatives if risky): low
[String changes made]: no

Comment 9

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

Joshua, 

because this is also a dependent bug for woodduck (Please check dependency field), I am not sure whether you can test with woodduck to verify this or not.

Comment 10

[Joshua Mitchell (Inactive)]

Unfortunately - we do not have any of those devices here

Comment 11

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

Hi Bajaj,

can you help me check the approval flag for 2.0 ? thanks :)

Comment 12

[Jason Smith [:jsmith]]

(In reply to EJ Chen [:eragonj][:小龍哥](PTO: 09/05 ~ 09/12) from comment #11)
> Hi Bajaj,
> 
> can you help me check the approval flag for 2.0 ? thanks :)

Shouldn't this be nominated to 2.0M? if this is woodduck specific?

Comment 13

[bhavana bajaj [:bajaj]]

Given this is woodduck specific, moving the blocking flag to 2.0M+.

Ej, Kai-Zhen Li  should be able to help land on 2.0M branch.

Comment 14

[bhavana bajaj [:bajaj]]

(In reply to EJ Chen [:eragonj][:小龍哥](PTO: 09/05 ~ 09/12) from comment #3)
> [Blocking Requested - why for this release]:
> 
> Currently on v2.0, we have to double click on "forget network" button to
> forget memorized wifi and this would impact user experiences. And because on
> 2.1, this bug has been fixed due to wifi refactor work, this bug would focus
> on v2.0 fix.

If this needs to land on 2.0 , I need to confirm this is a 2.0 regression. QA's testing does not seem to confirm this, anything you are doing differently? was it ever working on 1.4?

Comment 15

[Kai-Zhen Li [:seinlin][:kli]]

Yeah, I can help on 2.0M branch. 
But AIK, this issue is also reproduced on Flame 2.0, so I think we should land it on 2.0. Then I'll pick it to 2.0M. If someone can confirm that we need to land on 2.0M only, I will follow to process.

Comment 16

[bhavana bajaj [:bajaj]]

(In reply to Kai-Zhen Li from comment #15)
> Yeah, I can help on 2.0M branch. 
> But AIK, this issue is also reproduced on Flame 2.0, so I think we should
> land it on 2.0. Then I'll pick it to 2.0M. If someone can confirm that we
> need to land on 2.0M only, I will follow to process.

Unless this is a proven issue, I want to avoid any code changes on 2.0 at this point. I am NI EJ for clarification of comment #15.

Comment 17

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

Just using QA's tool to re-flash the phone to latest 2.0 (with device info attached below).

Not sure how QA test this bug, what I did is just using the tool they provide (./flash_pvt.py -w and select 2.0 device) and can produce this.

This is a minor bug for engineering but is easily reproduced to users, so leave the decision to release team. 

If we want to stabilize 2.0, I can only land on 2.0M.

Thanks.

== device info ==

Gaia      7edd3b0b9f65c3dde235c732d270e43e055a1254
Gecko     https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/f2a6fb59a7f5
BuildID   20140914160201
Version   32.0
ro.build.version.incremental=eng.cltbld.20140602.192604
ro.build.date=Mon Jun  2 19:26:18 EDT 2014
B1TC400110G0

Comment 18

[bhavana bajaj [:bajaj]]

(In reply to EJ Chen [:eragonj][:小龍哥] from comment #17)
> Just using QA's tool to re-flash the phone to latest 2.0 (with device info
> attached below).
> 
> Not sure how QA test this bug, what I did is just using the tool they
> provide (./flash_pvt.py -w and select 2.0 device) and can produce this.
> 
> This is a minor bug for engineering but is easily reproduced to users, so
> leave the decision to release team. 
> 
> If we want to stabilize 2.0, I can only land on 2.0M.
> 
> Thanks.
> 
> == device info ==
> 
> Gaia      7edd3b0b9f65c3dde235c732d270e43e055a1254
> Gecko     https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/f2a6fb59a7f5
> BuildID   20140914160201
> Version   32.0
> ro.build.version.incremental=eng.cltbld.20140602.192604
> ro.build.date=Mon Jun  2 19:26:18 EDT 2014
> B1TC400110G0

Ej and I discussed this bug in-person, I think its a nasty regression and could also be a cert blocker. Let us first get clarification from QA on them being able to reproduce this issue. After which, I can NI the OEM/carrier partner to comment on whether this will be a cert blocker or not.

Comment 19

[Eric Chang [:ericcc] [:echang]]

Reproduce rate is quite low, just 2 out of 30+ attempts, and only the 1st attempt right after flashing, not able to reproduce it since that.


v2.0 BuildID   20140828160259, B1TC400110G0, not reproducible so far 
v2.0 BuildID   20140917160210, B1TC400110G0, only once, the 1st attempt right after flashing, but not reproducible after that, not even reset, reboot, quit settings of the phone.

v2.0 BuildID   20140828160259, B1TC00011230, not reproducible so far 
v2.0 BuildID   20140917160210, B1TC00011230, only once, the 1st attempt right after flashing, but not reproducible after that, not even reset, reboot, quit settings of the phone.

N.B. Partner build version should not be a factor here. Bug still exists in v2.0, but the reproduce rate is just quite low.

Comment 20

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

After discussing with Eric and based on the result from Eric's finding, personally I think let's just keep this patch on 2.0m only, what do you think :bajaj :) ?

Comment 21

[bhavana bajaj [:bajaj]]

(In reply to EJ Chen [:eragonj][:小龍哥] from comment #20)
> After discussing with Eric and based on the result from Eric's finding,
> personally I think let's just keep this patch on 2.0m only, what do you
> think :bajaj :) ?

yep, 2.0m only and this will go-in into 2.1 anyways .

Comment 22

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

Attachment: patch on v2.0m

This is the same patch taken from v2.0, waiting for CI.

Comment 23

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

Merged into Gaia/v2.0m : https://github.com/mozilla-b2g/gaia/commit/a18becbdce13ad83c4ac2888c25d19e6654781a9

Thanks all.

Comment 24

[Hubert Lu[:hlu] <[e-mail]>]

I could not reproduce this issue on woodduck v2.0, please see following build information.

== Build Information ==
Gaia-Rev        b337a8839d6302c19469512dd3bb4a5f6d06e300
Gecko-Rev       c6f1a6a8b2b1c5efb464dc1c3ee3f0792fdefb78
Build ID        20140922094331
Version         32.0
Device Name     soul35
FW-Release      4.4.2
FW-Incremental  1411349471
FW-Date         Mon Sep 22 09:31:37 CST 2014

Comment 25

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

Hubert, based on your Gaia-Rev, it doesn't contain my patch but it seems work there even without my patch (?)

If I remember right, there might be high chances that you can (and can't) reproduce the bug without my patch and my patch is to make sure the timing issues are 100% gone.

Can you double-check to see whether my patch does fix the problem or not ?

Big thanks !

Comment 26

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

You can check Eric's comment 19 to know more about this timing issue.

Comment 27

[Hubert Lu[:hlu] <[e-mail]>]

Hi EJ,
   Thanks for your reminding. The build in comment 24 really doesn't contain your patch. I have synced the latest code contains your patch, and re-verify it. This issue also could NOT be reproduced on Woodduck 2.0M. (Total trials: 20)

== Build Information ==
Gaia-Rev        a18becbdce13ad83c4ac2888c25d19e6654781a9
Gecko-Rev       47fae72926357e64793eace45ffe06f928301208
Build ID        20140922173149
Version         32.0
Device Name     soul35
FW-Release      4.4.2
FW-Incremental  1411377575
FW-Date         Mon Sep 22 17:19:57 CST 2014

Comment 29

[Josh Cheng [:josh]]

Hi EJ,
It is an generic bug for 2.0, 2.0M, 2.1, 2.2.
I understand that this seems to be fix without patch in 2.0M. However to be on the safe side, can you also provide patch for 2.0, 2.1 and 2.2(Maintrunk)?
Thanks!

Comment 30

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

(In reply to Josh Cheng from comment #29)
> Hi EJ,

Hi Josh !

> It is an generic bug for 2.0, 2.0M, 2.1, 2.2.

Please check comment 1 to know the reason why this bug doesn't need to be uplifted to 2.1 and 2.2 (master).
And also, based on comment 16 and comment 17, we only land this patch on 2.0m instead of 2.0.

> I understand that this seems to be fix without patch in 2.0M. However to be

No ... we did merge the patch to 2.0m already.

> on the safe side, can you also provide patch for 2.0, 2.1 and 2.2(Maintrunk)?
> Thanks!

Hope this can clarify something, thanks !

Comment 31

[Josh Cheng [:josh]]

(In reply to EJ Chen [:eragonj][:小龍哥][ni? if you need me] from comment #30)
> (In reply to Josh Cheng from comment #29)
> > Hi EJ,
> 
> Hi Josh !
> 
> > It is an generic bug for 2.0, 2.0M, 2.1, 2.2.
> 
> Please check comment 1 to know the reason why this bug doesn't need to be
> uplifted to 2.1 and 2.2 (master).
> And also, based on comment 16 and comment 17, we only land this patch on
> 2.0m instead of 2.0.
> 
> > I understand that this seems to be fix without patch in 2.0M. However to be
> 
> No ... we did merge the patch to 2.0m already.
> 
> > on the safe side, can you also provide patch for 2.0, 2.1 and 2.2(Maintrunk)?
> > Thanks!
> 
> Hope this can clarify something, thanks !

Hi EJ,
Sorry I must mistakely comment this. I am marking this bug to 2.0M+.

Comment 32

[Lancy(Leave from Mozilla)]

Test case has been added in moztrap:
https://moztrap.mozilla.org/manage/case/1357/