Closed Bug 1060232 Opened 7 years ago Closed 7 years ago

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

Categories

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

x86
macOS
defect
Not set
normal

Tracking

(blocking-b2g:2.0M+, b2g-v2.0 wontfix, b2g-v2.0M verified, b2g-v2.1 unaffected, b2g-v2.2 unaffected)

RESOLVED FIXED
2.1 S5 (26sep)
blocking-b2g 2.0M+
Tracking Status
b2g-v2.0 --- wontfix
b2g-v2.0M --- verified
b2g-v2.1 --- unaffected
b2g-v2.2 --- unaffected

People

(Reporter: eragonj, Assigned: eragonj)

References

Details

(Keywords: regression, Whiteboard: [p=1][2.0M_only])

Attachments

(2 files)

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
Attached file 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 :)
Attachment #8481113 - Flags: review?(arthur.chen)
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!
Attachment #8481113 - Flags: review?(arthur.chen) → review+
[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.
blocking-b2g: --- → 2.0?
blocking-b2g: 2.0? → 2.0+
QA Wanted for branch checks.
Keywords: qawanted
QA Contact: ychung
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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
This issue does not seem to be reproducing in the latest.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell) → needinfo?(ejchen)
Keywords: qawanted
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.
Flags: needinfo?(ejchen)
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
Attachment #8481113 - Flags: approval-gaia-v2.0?
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.
Flags: needinfo?(jmitchell)
Unfortunately - we do not have any of those devices here
Flags: needinfo?(jmitchell)
Hi Bajaj,

can you help me check the approval flag for 2.0 ? thanks :)
Flags: needinfo?(bbajaj)
(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?
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.
blocking-b2g: 2.0+ → 2.0M+
Flags: needinfo?(bbajaj) → needinfo?(kli)
(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?
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.
Flags: needinfo?(kli)
(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.
Flags: needinfo?(ejchen)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
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
Flags: needinfo?(ejchen) → needinfo?(bbajaj)
(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.
Flags: needinfo?(bbajaj)
Keywords: regression
Flags: needinfo?(echang)
Whiteboard: [p=1]
Target Milestone: --- → 2.1 S5 (26sep)
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.
Flags: needinfo?(echang)
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 :) ?
Flags: needinfo?(bbajaj)
(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 .
Flags: needinfo?(bbajaj)
Attachment #8481113 - Flags: approval-gaia-v2.0?
Attached file patch on v2.0m
This is the same patch taken from v2.0, waiting for CI.
Merged into Gaia/v2.0m : https://github.com/mozilla-b2g/gaia/commit/a18becbdce13ad83c4ac2888c25d19e6654781a9

Thanks all.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
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
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 !
Flags: needinfo?(hlu)
You can check Eric's comment 19 to know more about this timing issue.
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
Flags: needinfo?(hlu)
Duplicate of this bug: 1070924
Blocks: Woodduck
Summary: [WIFI] Cannot forget AP via known network → [Woodduck][WIFI] Cannot forget AP via known network
Whiteboard: [p=1] → [p=1][2.0M_only]
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!
blocking-b2g: 2.0M+ → 2.0+
Flags: needinfo?(ejchen)
(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 !
Flags: needinfo?(ejchen)
(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+.
blocking-b2g: 2.0+ → 2.0M+
Test case has been added in moztrap:
https://moztrap.mozilla.org/manage/case/1357/
Flags: in-moztrap+
You need to log in before you can comment on or make changes to this bug.