Closed Bug 797581 Opened 12 years ago Closed 12 years ago

[system][wifi] Wifi does not connect to known network until Settings app is opened

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-basecamp:+)

VERIFIED FIXED
blocking-basecamp +

People

(Reporter: dietrich, Assigned: timdream)

References

Details

Attachments

(1 file)

STR:

Connect to network.
Go away, causing disconnection.
Return.

Expected: reconnects

Actual: stays on mobile data, no reconnection until open the Settings app, at which point it connects immediately.
Not sure if this is blocking, since there's a workaround *and* wifi isn't huge in the target market. However, it's pretty annoying behavior, and we should get kaze/mrbkap input on whether it's expected to and whether there's an underlying bug in there that might effect other things as well.
blocking-basecamp: --- → ?
blocking-basecamp: ? → +
The only solution we got in Gaia with the current API will be doing |setInterval(scanForWifi)| when wifi is turned on but isn't connected.

If you want that I can take this issue.
CCing Casey. Is that the desired behavior?
Assignee: nobody → kaze
Once a user provisions and connects their device to a Wifi network, it's expected that it will re-connect after the device is unlocked or restarted provided the network is in range and operating.  

This is standard behavior on every Wifi enabled device that I have used. I don't see why ours should be any different.  

I would certainly flag this as blocking+
Taking. I will deliver a fix as follow, in the System app.

- if the phone is waken and wifi is at on state, issue a scanning command to the API so known wifi will be joined automatically.
Assignee: kaze → timdream+bugs
Summary: [settings][wifi] Wifi does not connect to known network until Settings app is opened → [system][wifi] Wifi does not connect to known network until Settings app is opened
(In reply to Dietrich Ayala (:dietrich) from comment #0)
> STR:
> 
> Connect to network.
> Go away, causing disconnection.
> Return.
> 
> Expected: reconnects
> 
> Actual: stays on mobile data, no reconnection until open the Settings app,
> at which point it connects immediately.

Casey, actually my plan in comment 6 does not fix what described in STR. If wifi is on but not connected, do you think we should issue scanning continuously (while the screen is on) until the wifi network is connected?
In the case that Wifi is On but does not find a known network to connect with, we should:
- Continue scanning for known Wifi networks.
- Fall-back to mobile data if available.

Wifi should always be the preferred connection unless explicitly toggled off or is unavailable.  

If we only scan and connect to Wifi networks when the screen is On, are we preventing applications from syncing and transferring background data?   How would i receive my new email or calendar notifications otherwise?

Continuous scanning i would also suspect to be a major battery suck as well?
(In reply to Casey Yee [:cyee] from comment #8)
> In the case that Wifi is On but does not find a known network to connect
> with, we should:
> - Continue scanning for known Wifi networks.
> - Fall-back to mobile data if available.
> 
> Wifi should always be the preferred connection unless explicitly toggled off
> or is unavailable.  
> 
> If we only scan and connect to Wifi networks when the screen is On, are we
> preventing applications from syncing and transferring background data?   How
> would i receive my new email or calendar notifications otherwise?

Applications generally are not allowed to wake the device unless they have the permission to use Alarm API. But even so wifi will be quietly turned off already, so they will be checking their e-mail through 3G.

> Continuous scanning i would also suspect to be a major battery suck as well?

I don't know, but if to complete the requirement I should just scan for wifi from time to time.
Comment on attachment 671789 [details]
https://github.com/mozilla-b2g/gaia/pull/5838

Fabien is probably a better reviewer than me for this.
Attachment #671789 - Flags: review?(21) → review?(kaze)
Comment on attachment 671789 [details]
https://github.com/mozilla-b2g/gaia/pull/5838

This is talking too much time. I am just gonna asking Evelyn to review this for me.
Attachment #671789 - Flags: review?(kaze) → review?(ehung)
Attachment #671789 - Flags: review?(ehung) → review+
https://github.com/mozilla-b2g/gaia/pull/5838
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
i'm reopening this as it happened to me today when i came into the office.  the unagi i'm dogfooding didn't reconnect to the wifi until i opened the settings and turned wifi off and then back on...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Component: Gaia → Gaia::System
(In reply to Faramarz (:faramarz) from comment #14)
> i'm reopening this as it happened to me today when i came into the office. 
> the unagi i'm dogfooding didn't reconnect to the wifi until i opened the
> settings and turned wifi off and then back on...

I think that is a Unagi specific issue. We are handling that in bug 811833 (where ther is a reliable STR)
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
Gecko-cfad7c9
Gaia-6c53dfd
Resolution: FIXED → WORKSFORME
Use verified fixed in this case - there was a patch here.
Status: RESOLVED → VERIFIED
Resolution: WORKSFORME → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: