Closed Bug 855513 Opened 11 years ago Closed 11 years ago

WIFI is not re-enabled when internet sharing is getting stopped and WIFI was enabled before

Categories

(Firefox OS Graveyard :: Wifi, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g18 affected)

RESOLVED FIXED
B2G C4 (2jan on)
Tracking Status
b2g18 --- affected

People

(Reporter: whimboo, Assigned: vliu)

References

Details

Attachments

(1 file, 1 obsolete file)

We do not re-enable WIFI when the user stops internet sharing, and wifi was enabled before. That will force you to always have to go back into the wifi settings to turn on wifi again. We should only do this when wifi was turned on before.

Steps:
1. Turn on WIFI and connect to a network
2. Enable internet sharing
3. Disable internet sharing

After step 3 we do not automatically connect to the WIFI network used before. This is done by Android, and probably other platforms.
Assignee: nobody → vliu
I think we should have more control behavior betweeen handleWifiEnabled and handleWifiTetheringEnabled. I can come out a patch to ask for more info.
blocking-b2g: --- → tef?
I don't think we should hold the release because of that as user has all the information to detect the issue and activate WiFi manually
blocking-b2g: tef? → -
Attached patch Patch V1 (obsolete) — Splinter Review
Hi vchang,

I created a patch to fix this bug. Can you please review it? Thanks.
Attachment #732210 - Flags: review?(vchang)
Comment on attachment 732210 [details] [diff] [review]
Patch V1

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

Looks good.

Please remove trail blank before commit the patch. r=me with that fixed. 
Please also help to test if there is any side effect if we turn on/off Wifi and Wifi Hotspot repeatedly.
Attachment #732210 - Flags: review?(vchang) → review+
Attached patch Patch V2Splinter Review
(In reply to Vincent Chang[:vchang] from comment #4)
> Comment on attachment 732210 [details] [diff] [review]
> Patch V1
> 
> Review of attachment 732210 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Looks good.
> 
> Please remove trail blank before commit the patch. r=me with that fixed. 
> Please also help to test if there is any side effect if we turn on/off Wifi
> and Wifi Hotspot repeatedly.

Thanks for the review. Removed trail blank for the patch. r=me.
Attachment #732210 - Attachment is obsolete: true
Attachment #734450 - Flags: review+
Keywords: checkin-needed
Summary: WIFI is not re-enabed when internet sharing is getting stopped and WIFI was enabled before → WIFI is not re-enabled when internet sharing is getting stopped and WIFI was enabled before
https://hg.mozilla.org/mozilla-central/rev/312ea5e42aef
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → B2G C4 (2jan on)
Can we ask to get this backported to b2g18? It's a kinda annoying issue and already fixed about 2 month on master.
It will be too late for leo, but could we get this feature into koi?
blocking-b2g: - → koi?
Hi Vincent, 
For your patch https://hg.mozilla.org/mozilla-central/rev/312ea5e42aef, there are something we don't think is write behavior, please help check, thanks.

1. turn on hotspot,
2. turn on WiFi, the hotspot turn off.
3. turn off WiFi,  the hotspot turn on.------->KO.

We don't think step 3 is OK, maybe you could check android's behavior.
Flags: needinfo?(vliu)
(In reply to Ray REN from comment #13)
> Hi Vincent, 
> For your patch https://hg.mozilla.org/mozilla-central/rev/312ea5e42aef,
> there are something we don't think is write behavior, please help check,
> thanks.
> 
> 1. turn on hotspot,
> 2. turn on WiFi, the hotspot turn off.
> 3. turn off WiFi,  the hotspot turn on.------->KO.
> 
> We don't think step 3 is OK, maybe you could check android's behavior.

I think the patch is fine.
The cause of your problem might be sync issue of request queue, as same as bug 906631.
(In reply to Chuck Lee [:chucklee] from comment #14)
> I think the patch is fine.
> The cause of your problem might be sync issue of request queue, as same as
> bug 906631.

I don't mean the patch has something error.
I want to know why you turn on hotspot when turn off wifi ? Is your spec design or by your ideas? For android's behavior,the hotspot doesn't turn on itself.
(In reply to Ray REN from comment #15)
> (In reply to Chuck Lee [:chucklee] from comment #14)
> > I think the patch is fine.
> > The cause of your problem might be sync issue of request queue, as same as
> > bug 906631.
> 
> I don't mean the patch has something error.
> I want to know why you turn on hotspot when turn off wifi ? Is your spec
> design or by your ideas? For android's behavior,the hotspot doesn't turn on
> itself.

I think it's designed to do so, to restore previous wifi status.
(In reply to Chuck Lee [:chucklee] from comment #16)

> I think it's designed to do so, to restore previous wifi status.

We also think wifi status should been restored, but we dosen't think hotspot status  need to restored, it is not useful
dear Vincent and Chuck,

For this patch, we don't know who(wifi/airplane/hotspot) turn on/off wifi,when we setWifiEnabled in gecko, So it cause new problems as follows, please help check. Thanks
The reproduce step:
1.turn on wifi
2.turn on hotspot
3.turn on airlpane model via systembar, find wifi will turn on itself-----> KO.
Flags: needinfo?(chulee)
Airplane mode is controlled by Gaia, and it seems the wifi state doesn't sync between Gaia and Gecko.
I'll look into this, please also report a new bug for this issue instead of discussing in a closed bug, thanks.
Flags: needinfo?(chulee)
(In reply to Ray REN from comment #18)
> dear Vincent and Chuck,
> 
> For this patch, we don't know who(wifi/airplane/hotspot) turn on/off
> wifi,when we setWifiEnabled in gecko, So it cause new problems as follows,
> please help check. Thanks
> The reproduce step:
> 1.turn on wifi
> 2.turn on hotspot
> 3.turn on airlpane model via systembar, find wifi will turn on itself----->
> KO.

Reported as Bug 917097.
This already landed in time for 1.2, so no need to nominate for koi at this point.
blocking-b2g: koi? → ---
Flags: needinfo?(vliu)
You need to log in before you can comment on or make changes to this bug.