Closed Bug 989717 Opened 10 years ago Closed 10 years ago

[Tarako][WIFI][Internet sharing] While wifi-hotspot enabled, enable and disable wifi, then wifi cannot be enabled again

Categories

(Firefox OS Graveyard :: Wifi, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:1.3T+, firefox29 wontfix, firefox30 fixed, firefox31 fixed, b2g-v1.3T fixed, b2g-v1.4 fixed, b2g-v2.0 fixed)

VERIFIED FIXED
1.4 S6 (25apr)
blocking-b2g 1.3T+
Tracking Status
firefox29 --- wontfix
firefox30 --- fixed
firefox31 --- fixed
b2g-v1.3T --- fixed
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed

People

(Reporter: bli, Assigned: chucklee)

References

Details

(Whiteboard: [p=5])

Attachments

(2 files, 5 obsolete files)

Environment:
------------------
Gaia 14ef4fcdf9199f04f7678755c917dc77f51e13ba
Gecko https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/b574a7967338
BuildID 20140329004002
Version 28.1


Steps to reproduce:
----------------------
1. Launch settings
2. Select "Internet sharing"
3. Enable "Wifi-hotspot"
4. Notice that "Wi-Fi" is disabled on the status bar
5. Click "Back" button
6. From Settings menu Click on "Wi-Fi"
7. Enable "Wi-Fi"
   --> Wifi connection cannot be established, and it keeps searching available networks.
8. Disable "Wi-Fi"
9. Tap on the button to enable "Wi-Fi" again.


Actual results:
---------------------
1. Cannot enable "Wi-Fi" again.
2. The enable/disable button turns grey.


Additonal info:
---------------------
This bug cannot be reproduced 100%, but there is a high probability.
Hi! Vincent,

Could you help on this? Thanks


--
Keven
blocking-b2g: --- → 1.3T?
Flags: needinfo?(vchang)
Chuck may be able to check this bug first.
Flags: needinfo?(vchang)
Flags: needinfo?(chulee)
Can't reproduced on unagi(this is the only phone I got), may QA help to test this on both 1.3T and central on Buri?
Flags: needinfo?(chulee)
Keywords: qawanted
Chuck, can you please borrow a device from Thomas's team and take a look? Thanks
Flags: needinfo?(chulee)
QA Contact: bzumwalt
Issue occurs on both Tarako 1.3 and Buri 2.0

Was able to get issue to occur with lower repro rate on Buri running 2.0 Central. STR was slightly different. Had to go through steps 2 through 7 repeatedly (and rapidly) for issue to occur. 

Unable to get ER2 ("The enable/disable button turns grey.") to reproduce for either device. Button is briefly grey but becomes available to use after a few seconds. Wifi cannot be truly enabled as it searches for an access point infinitely or (on the Buri) rapidly cycles through trying to connect to an available access point without success.


2.0 Environmental Variables:
Device: Buri Central Mozilla RIL
BuildID: 20140401040202
Gaia: 874fe42b82e8d819d592690e74db91c07179e68c
Gecko: 1417d180a1d8
Version: 31.0a1
Firmware Version: v1.2-device.cfg

1.3T Environmental Variables:
Device: Tarako v1.3 Mozilla RIL
BuildID: 20140401060054
Gaia: 769c3b00a43f03ca901414ec533f7b313a7684c5
Gecko: 321494b801617a6bdf8260a483a80c0c09d49c4d
Version: 28.1
Keywords: qawanted
(In reply to Joe Cheng [:jcheng] from comment #4)
> Chuck, can you please borrow a device from Thomas's team and take a look?
> Thanks

If this can be reproduced on Buri 2.0, I'll try unagi first.
Flags: needinfo?(chulee)
Assignee: nobody → chulee
Hi Bingqing, can you verify that you can connect to wifi after disabling wifi-hotspot after step 4?
Flags: needinfo?(bli)
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #7)
> Hi Bingqing, can you verify that you can connect to wifi after disabling
> wifi-hotspot after step 4?

I've tried on build 20140402164000. Sometimes I can connect to wifi after disabling wifi-hotspot after step 4, sometimes I cannot. 

And what seems really strange to me is sometimes the tip under a ap's name is 'Connected', but the icon on the notification bar is still searching status. Then I go back to 'settings' page, the tip under 'Wi-Fi' is 'Offline'. Actually Wifi connection is not established in such a situation.
Flags: needinfo?(bli)
hi Chuck, can you please provide some update on the bug? thanks
Flags: needinfo?(chulee)
Chuck is on vocation today. He'll be back tomorrow.
Component: Gaia::Settings → Wifi
Treat enabling and disabling state as enabled/disabled, so enable/disable command won't be dropped in these transition states.
Attachment #8403073 - Flags: feedback?(vchang)
Flags: needinfo?(chulee)
Root cause for this bug seems to be the execution time of enable/disable command is getting longer(I don't know why) after rapid enable/disable command.
So when next disable/enable command comes in, the wifi/hotspot might be in previous enabling/disabling state, which is treat as disabled/enabled. And the command is ignored and cause unsync between gaia and gecko.

The WIP patch handles enabling/disabling state as enabled/disabled state to resolve the the command unsyc issue.
But the execution time issue can't be solved, and will bring another issue that there are many commands to be executed in the command queue, and gaia UI will be locked or unsync before the command queue is complete executed.

I'll try to give the command queue the ability to detect redundant command, like enable wifi then disable wifi, and remove them, too see if this can improve the execution time.
triage: 1.3T+, wifi should be able to turn on all the time
blocking-b2g: 1.3T? → 1.3T+
Comment on attachment 8403073 [details] [diff] [review]
WIP - 0001. Handle enabling and disabling state properly.

Review of attachment 8403073 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good.
Attachment #8403073 - Flags: feedback?(vchang) → feedback+
Chuck, is the patch ready for review?
Flags: needinfo?(chulee)
1. Move requestDone() to last step of enable/disable command to prevent state confusion.
2. Treat disabling/enabling state correctly.
3. Workaround to handle wifi-enable-loop, should be removed after bug 930355.
Attachment #8403073 - Attachment is obsolete: true
Attachment #8405202 - Flags: review?(vchang)
Flags: needinfo?(chulee)
Attached patch 0002. Optimize request queue. (obsolete) — Splinter Review
Optimize request queue by removing paired command(like disable wifi right after enable wifi) and redundant command(like disable wifi right after disable wifi).
Attachment #8405203 - Flags: review?(vchang)
Whiteboard: [p=5]
Target Milestone: --- → 1.4 S6 (25apr)
Fix state issue brought by bug 993821.
Attachment #8405202 - Attachment is obsolete: true
Attachment #8405202 - Flags: review?(vchang)
Attachment #8405306 - Flags: review?(vchang)
Comment on attachment 8405203 [details] [diff] [review]
0002. Optimize request queue.

Review of attachment 8405203 [details] [diff] [review]:
-----------------------------------------------------------------

Per offline discussion, we can do queue optimization stuff in the follow up bug.
Or we could support wifi and wifi hotspot enable/disable APIs soon since bug 886110 is landing.

::: dom/wifi/WifiWorker.js
@@ +2761,5 @@
> +    (function queueOptimize() {
> +      let lastRequest = self._stateRequests[self._stateRequests.length - 1];
> +
> +      // Push command if no previous command or commands are not the same.
> +      if (!lastRequest || lastRequest.data.command !== data.command) {

I think we should put request with the same command but different value to the queue as well.
Attachment #8405203 - Flags: review?(vchang)
Comment on attachment 8405306 [details] [diff] [review]
Handle enabling and disabling state properly. V2

Review of attachment 8405306 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good. Thank you.
Attachment #8405306 - Flags: review?(vchang) → review+
Attachment #8405306 - Attachment description: 0001. Handle enabling and disabling state properly. V2 → Handle enabling and disabling state properly. V2
Use different control variable to skip redundant setting of wifi enable and wifi disable seperately, in case there's anothre wifi enable/disable settings sent from Gaia before system app does.
Adding these control should prevent wifi enable/disable settings loop, but can't reduce redundant enable/disable settings event.
Attachment #8405306 - Attachment is obsolete: true
Attachment #8406606 - Flags: review?(vchang)
Attachment #8406606 - Flags: review?(vchang) → review+
Comment on attachment 8406610 [details] [diff] [review]
Handle enabling and disabling state properly. V2 (1.3t)

Review of attachment 8406610 [details] [diff] [review]:
-----------------------------------------------------------------

The patch looks good. Thank you.
 
But I found the new bug if I toggle wifi hotspot settings quickly.
I filed bug 996541.
Attachment #8406610 - Flags: review?(vchang) → review+
Comment on attachment 8406606 [details] [diff] [review]
Handle enabling and disabling state properly. V3

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 989717
User impact if declined: wifi setting malfunction if user apply actions as STR.
Testing completed (on m-c, etc.): m-c and 1.3t
Risk to taking this patch (and alternatives if risky): No
String or IDL/UUID changes made by this patch: No
Attachment #8406606 - Flags: approval-mozilla-aurora?
insmod itm_sta ko fail
sprd bug
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/092bbc509ddc
Status: NEW → RESOLVED
Closed: 10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Attachment #8406606 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
verified and fixed with today's daily build
Gaia      3f1d8332d127f1d6bc0fdbb08146ce1deb0efbc0
Gecko     https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/5da76152c2bd
BuildID   20140421164001
Version   28.1
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.