823783 - [Settings] [Internet sharing] Tapping Wi-fi hotspot ON & OFF disables Wi-fi connection forever

Status: VERIFIED FIXED

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

Description

[Deepa Subramanian]

Attachment: Log file for WIFI disabled forever

## Environment : Unagi phone, build ID 20121217070202

Summary: Changing Wifi hot-spot On and OFF disables WI-FI connection. Wifi connection cannot be established at all. 

## Repro :
1) Tap on Settings from homescreen
2) Select "Internet sharing" Under Network & Connectivity
3) Tap on "Wifi-hotspot" to enable it
4) Notice that "Wi-Fi" is disabled on the status bar
5) Click "Back" button
6) From Settings menu Click on "Wi-fi"
7) tap on "wifi" to enable it
8) "Wifi" is not enabled 
## Expected:
Wifi to be enabled

## Actual:
Wifi is disabled forever

Comment 1

[Deepa Subramanian]

Attachment: Hot spot wifi - Tapping on and off

Comment 2

[Deepa Subramanian]

Attachment: Unable to enable wifi

Comment 3

[Walter Chen[:ypwalter][:wachen]]

Hi, Deepa subramanian,
you have a cool name =P

I think I this was the one I reported before:
https://bugzilla.mozilla.org/show_bug.cgi?id=816411

The reason behind this is that wifi can't receive and send at the same time. In that case, you need to enable 3G for wifi hotspot sharing instead of opening wifi for wifi hotspot sharing.

However, I do think that the UI design would mislead people. I would cc and asking other people in gaia team.

Comment 4

[Walter Chen[:ypwalter][:wachen]]

Bug 823813 is opened to solve all related issues

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: patch v1

If we land this, then we can land bug 823400 without regressing anything.

Comment 6

[Fabien Cazenave [:kaze]]

Comment on attachment 699767 [details]
patch v1

https://github.com/mozilla-b2g/gaia/commit/aa469f22358055d81f284e015af91eb5b51e9e4c

Comment 7

[Walter Chen[:ypwalter][:wachen]]

Device: Unagi
Build Identifier: 20130113070202
Update channel: 
   nightly b2g18 (pvt server)  
   unagi.zip	13-Jan-2013 08:06 	100M	 
   https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/nightly/mozilla-b2g18-unagi-eng/
Git commit info: 2013-01-13 15:15:51

Not verified. It still disabled the wifi forever.,

Comment 8

[David Flanagan [:djf]]

I can confirm that this bug still exists with the latest OTA update and gaia tip that includes the patch from comment 6.

Comment 9

[David Flanagan [:djf]]

I suspect we can fix this by removing these lines at wifi.js:754

    // lock UI toggle
    gWifiCheckBox.disabled = true;

Disabling the checkbox when the user interacts with it seems sufficient to me. I don't think we need to disable it when it is changed externally.

Comment 10

[David Flanagan [:djf]]

Nevermind. It looks like I can't reproduce this. Maybe I was just seeing the disabled toggle button and not waiting long enough for it to become reenabled.

Walter: would you explain exactly what you are seeing here?

If I follow the steps in the description, I find that I can enable WiFi at the same time as Tethering. (That seems like it might be a bug, but a different bug).

Its not literally in the STR, but from the summary, I gather that we are supposed to turn tethering on and then off, and then find that wifi is permanently disabled.  I thought I saw this happen in comment 8. But now I don't see it happen.

Comment 11

[Walter Chen[:ypwalter][:wachen]]

If you do with the STR and go back to see the Wifi subsection, you will not be able to turn on it again.

Comment 12

[David Flanagan [:djf]]

I just flashed exactly the same image that Walter referred to in comment 7, and I cannot reproduce the bug.

I do see a different bug, though: on this build, the "Wi-Fi hotspot" toggle won't remain turned on. If I tap it, it turns on, then in about 3 seconds it turns itself off again.

When I try to update this build to the latest gaia, it won't boot.

Comment 13

[David Flanagan [:djf]]

Walter, please clarify your STR. The title of this bug says turn wifi hotspot on and off. But the STR just say to turn it on.

I can't reproduce what you are seeing. A screenshot might help. When you go back to the wifi screen, is the toggle button disabled?  (Slightly grayed out?) There is lots of code that disables the toggle buttons, and it is possible that the button is somehow getting disabled and never re-enabled.

When you see the button disabled, do you give it 10 or more seconds to become re-enabled?  The process can take some time.

Finally, when you test, is there a wifi network nearby that your phone can connect to?  That is, after you flash it, do you enter the password of a network?

Comment 14

[David Flanagan [:djf]]

Trying again to reproduce, this time with https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/nightly/mozilla-b2g18-unagi/2013/01/2013-01-13-23-02-02/unagi.zip

I wonder if the problem I was having with enabling the hotspot above was because I didn't have a data connection enabled...

With a data connection enabled and no wifi password entered, I turn on hotspot, and it stays on. Then I turn off hotspot.  Then I go to the wifi screen and see that the toggle button is turned on.  I tap it and it goes off.  Then it is disabled and stays disabled.

So I have reproduced this bug.

Cancelling the need info request

Comment 15

[Walter Chen[:ypwalter][:wachen]]

1) Tap on Settings from homescreen
2) Turn on the Wifi and connect to any internet
2) Select "Internet sharing" Under Network & Connectivity
3) Tap on "Wifi-hotspot" to enable it
4) Notice that "Wi-Fi" is disabled on the status bar
5) disable Wifi-hotspot
6) From Settings menu Click on "Wi-fi"

Actual result: not able to enable it because the option still grey out

Comment 16

[David Flanagan [:djf]]

After reproducing this bug, if I kill the settings app and restart, it seems to work normally.  But if I reboot the phone then I can reproduce it using the steps above.

Comment 17

[David Flanagan [:djf]]

Hmm. I can't reproduce this consistently. Now I can't reproduce following walter's steps in comment 15 or my steps in comment 16.

Comment 18

[David Flanagan [:djf]]

I still can't reproduce using Walter's STR, but here's how I reproduce it:

1) Flash phone
2) In first-run, enable data, but don't select a wifi network or enter a password
3) Start the settings app
4) Enable wifi hotspot, then disable it
5) Go to wifi settings, notice that the phone thinks wifi is enabled
6) Tap toggle button to turn off wifi.
7) See that wifi toggle is disabled, and remains disabled forever.

The weird state in step 5 (wifi off, but toggle button on) make it pretty obvious why this bug is happening: tapping on the toggle button disables the button until the wifi state changes. But wifi was already off, so the state isn't going to change, and the button remains disabled.

I'm going to bed now. Blake: feel free to reassign this to me if I can help.

Comment 19

[David Flanagan [:djf]]

Wait! I think I figured out why I'm seeing my version of the bug (this may not explain what Walter is seeing, though).

The Settings app has this optimization where it doesn't load the HTML or JS for a panel until you go to that panel.  So if I start the settings app and go to the hotspot panel and turn on the hotspot, the system is going to disable wifi. But if I haven't opened the wifi panel yet, then the wifi.js file has never run, and there are no settings listeners listening for that wifi setting change.  So it misses the fact that the system has disabled wifi and does not adjust the setting value apporpriately.  Perhaps this is why in step 5 above, the toggle button shows that wifi is enabled even though the hotspot disabled it.

My guess, therefore, is that uncommenting the entire wifi section in apps/settings/index.html will make this bug go away.  Its too late at night to try that myself, though.

Comment 20

[David Flanagan [:djf]]

This seems like a pure Gaia bug at this point, so I'm stealing it.

Comment 21

[David Flanagan [:djf]]

Here's another way to reproduce it, without requiring the reflash step that I had above:

1) start settings app, ensure that wifi is enabled and connected to a network
2) force quit settings app
3) open setting app again, and go to hotspot
4) turn hotspot on and off
5) Go to wifi panel. Toggle button shows wifi on, but it is actually off now
6) Tap on wifi toggle button. It goes off and remains disabled forever.

Comment 22

[David Flanagan [:djf]]

I think everyone agrees that the wifi+hotspot interactions all need to be redesigned and we need to integrate the code in wifi.js with the code in hotspot.js and make it all work together.  But that is a post-v1 task.

For now, I think I can fix this by turning the wifi.enabled setting off when the user turns on the hotspot.  

Actually, that would fix the issue when wifi.js had not been loaded yet, but it might cause new bugs if wifi.js had already been loaded because then we might get two notifications that wifi was off, and wifi.js might get confused about the state in some other way.

Comment 23

[David Flanagan [:djf]]

Just adding code to hotspot.js to turn off wifi.enabled is not enough to fix this.  I can still get the phone into a wedged state where it is not possible to turn on wifi.  I haven't figured out reliable STR, but I'm going to abandon that approach.

Instead: I'm going to try to take the code that keeps the wifi api state and the wifi settings in sync and move that code to settings.js or somewhere so it will always run.

Comment 24

[David Flanagan [:djf]]

Attachment: link to patch on github

This patch takes code from wifi that was added in Blake's patch for this bug, and moves some of it to connectivity.js. It does this because connectivity.js is always running, but code in wifi.js only starts running once the user visits the wifi pane.

The problem (I think) was that if the user turned on the hotspot, WifiWorker.js would disable the wifi hardware. But if wifi.js was not running yet, we wouldn't notice that and wouldn't keep the wifi.enabled setting in sync.

So now there is code in connectivity.js that keeps the setting value in sync with the hardware state.

I'm not really familiar with this part of Gaia, and am not completely confident about this patch, so please review and test it carefully.  I'm asking both Blake and Kaze for review because of the urgency of getting this fixed.

Comment 25

[David Flanagan [:djf]]

Setting qa wanted and flagging Walter to see if he can reproduce with my patch applied. Walter, if you apply attachment 701931 [details], does that fix the bug for you?

I've never been able to reproduce the bug with Walter's STR, so I can't check this myself.  If anyone else can reproduce following comment 15 and can check this patch, that would be much appreciated.

Comment 26

[David Flanagan [:djf]]

Reviewers: here's my thinking about this patch. I'm feeling sleep-deprived, so please help to ensure that this is valid and doesn't create race conditions or infinite loops of setting changes or anything...

What makes this part of the settings app tricky is that there are 3 things that can change:

1) the state of the wifi toggle button
2) the state of the wifi.enabled setting
3) the state of the wifi hardware

We want to keep all of these in sync.  

dom/wifi/WifiWorker.js listens to settings and updates hardware state to match

wifi.js listens for toggle button state changes and modifies wifi.enabled
to match

wifi.js also listens for settings changes and sets the toggle button
state to match

Currently, wifi.js also listens to the hardware state and trys to
keep the toggle button and settings in sync with that.  But
wifi.js isn't loaded until the user opens that panel, so it isn't
notified of all hardware state changes (such as the one that happens when the hotspot is turned on)

So this patch adds code to connectivity.js to keep the
wifi.enabled setting in sync with the hardware state.

To summarize, with this patch applied:

WifiWorker.js keeps the hardware in sync with the setting and
connectivity.js keeps the setting in sync with the hardware.
This means that wifi only needs to keep the update the toggle
button when the setting changes and update the setting when the
toggle button changes.

Comment 27

[David Flanagan [:djf]]

I'm going to be away for a few hours now, so if this proposed patch does not resolve the bug anyone who understands it should feel free to steal the bug and fix it.

Comment 28

[David Flanagan [:djf]]

Comment on attachment 701931 [details]
link to patch on github

Looks like Blake isn't around today, so I'm clearing his review request.

Comment 29

[Fabien Cazenave [:kaze]]

Comment on attachment 701931 [details]
link to patch on github

Spent the last 2.5 hours testing your patch. The code makes sense, but I still get a few situations where the wifi is stuck:
 • either because the wifi toggle cannot be activated;
 • or because the wifi backend doesn’t respond properly — in which case I get this error:

E/GeckoConsole(  893): [JavaScript Error: "NS_ERROR_NOT_INITIALIZED: Component returned failure code: 0xc1f30001 (NS_ERROR_NOT_INITIALIZED [nsIMessageSender.sendAsyncMessage]" {file: "jar:file:///system/b2g/omni.ja!/components/WifiWorker.js" line: 2341}]                                    

I can’t be sure but I don’t think this is related to your patch.

Evelyn, it’d be a great help if you could both look at David’s patch (feedback?) and double-check that the wifi now works in a reliable way.

Comment 30

[David Flanagan [:djf]]

If we want to be more aggressive about preventing this bug, we could modify wifi.js and hotspot.js so that the wifi toggle is disabled if the hotspot is enabled and vice versa.  Then we wouldn't have to disable wifi when the hotspot went on.

Intead (and this would require late-l10n) we'd display a message "Disable hotspot to enable wifi" or "disble wifi to enable hotspot" in each of the screens.

I think something like that would sidestep this bug completely.

Comment 31

[Walter Chen[:ypwalter][:wachen]]

Sorry, I was in deep sleep by the time you ask to try the patch, but the review+ is from kaze. So, I will cancel the reqinfo.

Comment 32

[Blake Kaplan (:mrbkap) (inactive)]

I was wondering on the plane home if this code should live in the system app instead of the settings app. What happens right now if I never open the settings app and wifi dies?

Comment 33

[David Flanagan [:djf]]

Walter, Kaze has given r+, but I'm not certain that he was every able to reproduce the bug following your steps.  Since this is one of the last remaining blockers, it has to land, but no one is particularly happy about the fix, so we need all the testing we can get.  Please, if you can, try the patch and see if it resolves the issue for you.

Comment 34

[Walter Chen[:ypwalter][:wachen]]

David, 

Thanks for the quick response. However, I couldn't reproduce it anymore in the new version of nightly b2g18. (1/14)

Comment 35

[Evelyn Hung]

I'm investigating the issue now. Will comment here if I get some idea.

Comment 36

[David Flanagan [:djf]]

What happens if wifi dies when settings is not running.  When settings starts up, it loads connectivity.js.  That file monitors wifi state changes and synchronizes wifi.enabled to them, but it does not seem to check the connection state when it first starts up.

I've updated my pull request with additional initialization code that checks the state of wifi when the settings app starts and sets the state of wifi.enabled to match it.  Evelyn, I've kept the new code as a separate commit, so you can review them separately, if you want.

Your thought about putting this in the system app is an interesting one, and to my horror, I find that there is already a whole bunch of system app code that deals with the wifi.enabled setting.  That code seems to be concerned with the status bar and the quick settings function and with shutting down the hardware when the phone is sleeping or idle to save power. The system app sets wifi.enabled when it turns wifi on and off. When the system app observes chagnes to the hardware state, it broadcasts them to other parts of the settings app using custom events.  I don't think that we're going to have a race condition or an infinite loop, but it certainly seems likely that we're going to end up generating too many notification events with this many different components listening to hardware notifications and settings change notifications.

Comment 37

[David Flanagan [:djf]]

I updated my pull request without testing it, and it was broken. I've updated the PR once again, but tested it this time.

Comment 38

[Evelyn Hung]

Here are some my understanding and findings:

1. per :vchang told me before, when the user turn hotspot on, platform will turn wifi off and update mozSettings' wifi.enabled to be false. But I found it didn't update the key in settings DB now, probably because bug 823400 landed?

2. I added `gWifiCheckBox.disabled = true` before to prevent quick tapping wifi on/off, it will cause the setting state out of sync with device because device interface will ignore all setting changes when it is initiating (which is good), but after initialized, it didn't check the settings again, that's the problem cause the out of sync.

3. I can reproduce the weird settings toogle is inactive issue by STR in comment 21 
my build: pvt 14-Jan-2013 08:36 with Gaia latest commit (bd976995e2ec6565e8b200f7743535c375ec233a)

Comment 39

[David Flanagan [:djf]]

Comment on attachment 701931 [details]
link to patch on github

Asking for Blake's feedback on this, since my patch alters his previous patch

Comment 40

[David Flanagan [:djf]]

Blake, 

I'm hoping to land this Tuesday morning. So if you're jetlagged and up early, maybe you can give it a sanity check.

Comment 41

[Evelyn Hung]

David, I tested and still get an inactive toogle, here is my STR:
0. reset gaia
1. turn data connection on
2. turn wifi on and connect to a network
3. turn hotspot on and then off
4. turn wifi on

result: the wifi toogle will be in a ON but *inactive* looks. but if you kill setting app, and launch it again, the toogle will back (shows wifi off), you can turn on wifi successfully now.

Comment 42

[Evelyn Hung]

My build: 
Gecko: 14-Jan-2013 08:36 pvt build 
Gaia: Github gaia master commit bd976995e2ec6565e8b200f7743535c375ec233a
Apply patch attachment 701931 [details] and do reset-gaia

Comment 43

[David Flanagan [:djf]]

I can't reproduce using Evelyn's steps and Evelyn's build.

If I read those STR carefully, it sounds as if the settings and toggles are working okay, but wifi just isn't coming up for her.  I could never reproduce what Walter was seeing, either. Its as if Taiwan wifi is different than US wifi.

Evelyn: you're not using the WPS connection are you? I know there is a lot of code involved in that.  I'm connected to a home wifi network with a password.

I'm not going to be able to do anything else on this tonight, so I'm unassigning myself in case anyone else wants to take this and run with it.  (Kaze?)

Comment 44

[Evelyn Hung]

Can't reproduce by following STR on comment 21, but I can reproduce the case on the bug description. copy & paste it again:
## Repro :
1) Tap on Settings from homescreen
2) Select "Internet sharing" Under Network & Connectivity
3) Tap on "Wifi-hotspot" to enable it
4) Notice that "Wi-Fi" is disabled on the status bar
5) Click "Back" button
6) From Settings menu Click on "Wi-fi"
7) tap on "wifi" to enable it
8) "Wifi" is not enabled 

## Expected:
Wifi to be enabled

## Actual:
Wifi is disabled forever

I still suspect it's a gecko problem, :vchang, can you take a look? If so, Walter will file another issue for it and let's land David's patch here. (which solve the problem on comment 21)

Comment 45

[Vincent Chang[:vchang][changyihsin]]

(In reply to Evelyn Hung [:evelyn] from comment #38)
> Here are some my understanding and findings:
> 
> 1. per :vchang told me before, when the user turn hotspot on, platform will
> turn wifi off and update mozSettings' wifi.enabled to be false. But I found
> it didn't update the key in settings DB now, probably because bug 823400
> landed?

Yes, Bug 823400 is landed based on the comment 5, and platform side will not update mozSettings for wifi.enabled anymore.

Comment 46

[David Flanagan [:djf]]

What should we do about this Evelyn?  I can't reproduce the bug you see and you can't reproduce the bug I see.

I've got a reviewed patch that fixes the bug I can reproduce, but doesn't fix the bug you can reproduce. Should we go ahead and land that and then keep the bug open and ask for more QA or something?

Comment 47

[David Flanagan [:djf]]

We also have Blake's suggestion that the code from my patch might be better in the system app so that it keeps the hardware and the setting in sync even when the settings app isn't running.  Blake or Evelyn, do either of you want to give that a try?

And we have Kaze's thought that there is still a gecko or gonk issue here.

Comment 48

[Evelyn Hung]

Okay, I've discussed with vchang which is a platform Dev and he is responsible for wifi and hotspot interface control. 

To be concluded, we have two STR for two issues in this bug, STR #1 in the issue description might be a platform bug, vchang is looking it and will file another issue. STR#2 in comment 21 is resolved by David's patch. Let's land David's patch first here.

Regard to System app, I'd like to file another issue for it and try David's code there.

Comment 49

[Evelyn Hung]

Comment on attachment 701931 [details]
link to patch on github

I believe the patch is good to solve the problem in comment 21.
David, could you please squash the commits into one? so we can merge it to Gaia master. Thanks.

Comment 50

[Evelyn Hung]

I realize I may misunderstand what David means... yes, I should test the code in System app. doing.

Comment 51

[Evelyn Hung]

Attachment: point to https://github.com/mozilla-b2g/gaia/pull/7662

in this patch, we are solving issues in comment 21. that is caused by bug 823400 landed, platform wifi interface won't update settings DB anymore, so Gaia should take the responsibility to update the status in DB when wifiManager.onenabled and wifiManager.ondisabled are fired.

Comment 52

[David Flanagan [:djf]]

Comment on attachment 703223 [details]
point to https://github.com/mozilla-b2g/gaia/pull/7662

I'm setting r- here even though I wasn't asked to review. See my comments on github.  I fear that this version of the patch is doing too much.

Modifying the system app is a lot scarier than just modifying the settings app!

Comment 53

[David Flanagan [:djf]]

Evelyn,

I've squashed the two commits in https://github.com/mozilla-b2g/gaia/pull/7601 so that it is ready to land if you want to land it.

Or, if you want to think more about patching the system app instead, you might start with my analysis in comment 26 and try extending that to include the system app in addition to the other files listed there.

I think I'd suggest that we land my patch and then continue investigating the cause of the bug you're seeing.  It might just be a matter of inserting debugging statements into all the code that touches the toggles or the settings just to figure out what events and notifications are being received when and what we're doing because of them.  

I'm sorry you're stuck with this. I'd offer to take the bug back if I could ever reproduce the symptoms you're seeing!

Comment 54

[David Flanagan [:djf]]

Evelyn,

Wait, maybe I can reproduce it. I just reread your STR in comment 44. I've been confused by this bug all along because the summary line says "hotspot on & off" but the STR just turn it on and then do not turn it off.

For me, if I follow the steps in comment 44, and turn the hotspot on and then go to the wifi panel, I see that the wifi toggle is on (incorrectly) and when I tap it it slides off and stays disabled forever. But what I'm describing here is almost the same as what I described in comment 21, and my patch fixes it, so maybe that is different than what you are seeing.  

Here are the STR you listed in comment 44:

> 1) Tap on Settings from homescreen
> 2) Select "Internet sharing" Under Network & Connectivity
> 3) Tap on "Wifi-hotspot" to enable it
> 4) Notice that "Wi-Fi" is disabled on the status bar
> 5) Click "Back" button

So you're leaving the hotspot turned on, right?

> 6) From Settings menu Click on "Wi-fi"

Is the wifi toggle on or off when you get here? Is it enabled or disabled? For me, if this is first time I've run the settings app, the toggle is on even though the hardware is off. (And my patch fixes that.) If I've already visited with wifi panel once, then the toggle is off here.  In both cases it is enabled and responds to my taps.

> 7) tap on "wifi" to enable it
> 8) "Wifi" is not enabled 

Does the toggle slide and then become disabled and remain in the disabled state?

We should compare notes too about what kind of wifi network you are connecting to.  Do you use the "Connect with WPS" feature?  I don't, and I don't even know what that is.  I'm connecting to a home wifi network with a password. It uses WPA-PSK. I connect without having to set any of the advanced settings.  If your network connection is different, maybe the difference is there.

Comment 55

[David Flanagan [:djf]]

I'm taking this back to see if I can move it forward today.

Comment 56

[David Flanagan [:djf]]

Ah ha! I can reproduce what Evelyn sees. I just have to do it quickly enough. If I wait a few seconds after turning the hotspot on and then turn wifi on, everything is okay. 

But if I turn on the hotspot and then go as quickly as I can to turn on wifi, I get stuck, like Evelyn and Walter reported.

Now we can get somewhere.  I'm going to land my Gaia patch for the bug in comment 21, and then investigate this different bug.

Comment 57

[David Flanagan [:djf]]

Landed my pull request:

https://github.com/mozilla-b2g/gaia/commit/15c80a9ac48a0029feab518c059f71af72c8da40

Comment 58

[David Flanagan [:djf]]

I think the other bug is in dom/wifi/WifiWorker.js.  I've been studying that code all day, the code for dealing with concurrent settings changes is really bad. We need to rewrite all of it from scratch.

For now, though, I think the problem is that setWifiEnabledInternal uses its "enabled" argument not as the enabled state of wifi, but as the argument to its callback.  But elsewhere in the code, the saved value of that enabled argument is treated like an actual wifi enabled value.

When I follow the steps to reproduce, I end up with these objects on the _statesRequest stack:

[{"enabled":true,"callback":"function"},{"enabled":true}]

That first "enabled":true is true because we're turning the hotspot on, not because we're turning wifi on.   But when we call setWifiAPEnabled(true, nextRequest), we end up passing true to nextRequest() telling it that the wifi state is true.  So it pops the second enabled:true off the stack without doing anything.

I'm not sure exactly where to fix it. But I think it will be a small patch for now.  (But we really do need to rewrite all that code.)

I may not get to this over the weekend and the US holiday on monday, so feel free to take it and fix it yourself, Vincent.

Comment 59

[David Flanagan [:djf]]

Attachment: work in progress patch

This is a work-in-progress patch for WifiWorker.js

With this patch applied, when I follow Walter and Evelyn's STR, I no longer see the bug they see. Unfortunately, there is a new bug: tethering does not get turned off when I turn wifi back on.  (Or probably tethering gets turned off but the setting is never set so the status bar and settings toggle button don't know that it has been turned off.)

Vincent: you are probably more familiar with the WifiWorker.js code than anyone. Would you look at my patch and see if you think this is the right direction to go in?  Any idea what why the tethering setting isn't being set to false?

The reason I wrote above that the code needed to be rewritten is that it looks like it has been changed and patched so many times, that it has grown too complex to reason about.  This should be a simple bug, but I've been beating my head against it all day.

Blake, if you happen to see this and are working over the weekend, I'd value your feedback too.

Comment 60

[Vincent Chang[:vchang][changyihsin]]

Comment on attachment 704190 [details] [diff] [review]
work in progress patch

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

I am going to apply your patch and fix the bug in comment 59 together in Bug 831716. 
The problem I found is that gNetworkManager.wifiTetheringEnabled and WifiManager.enabled may not reflect the 
state of wifi hotspot and wifi correctly while receiving settings change event.

Comment 61

[David Flanagan [:djf]]

It looks to me like Vincent's patch in 831716 fixes the bug here.  So when that lands, we should close this bug.

Comment 62

[Fabien Cazenave [:kaze]]

I’ll trust you on this. Pinging mrbkap.

Comment 63

[Evelyn Hung]

(Sorry for my late response here because I was in Jakarta for supporting their App Days event.) 
I'm okay with Vincent's patch, and will test and close here when it lands.

:mrbkap, any comments? (because kaze is pinging you.)

Comment 64

[Evelyn Hung]

Comment on attachment 703223 [details]
point to https://github.com/mozilla-b2g/gaia/pull/7662

cancel the review request because we have had another solution.

Comment 65

[Evelyn Hung]

oh, just noticed the issue owner has been changed to David. Thank you, David.

Comment 66

[Vincent Chang[:vchang][changyihsin]]

We could close this bug once the gecko part fix in Bug 831716 is landed.

Comment 67

[David Flanagan [:djf]]

Fix landed in Bug 831716. Closing.

Comment 68

[Walter Chen[:ypwalter][:wachen]]

pvt b2g18 build unagi_2013-01-24_eng.zip
Verified fixed

Comment 69

[Lukas Blakk [:lsblakk] use ?needinfo]

Landed on mozilla-b2g18/gaia master prior to the 1/25 branching to mozilla-b2g18_v1_0_0/v1.0.0, updating status-b2g-v1.0.0 to fixed.