Closed
Bug 823247
Opened 12 years ago
Closed 11 years ago
Wifi should not be disabled in sleep mode
Categories
(Firefox OS Graveyard :: Wifi, defect)
Tracking
(tracking-b2g:backlog)
RESOLVED
FIXED
tracking-b2g | backlog |
People
(Reporter: whimboo, Unassigned)
References
Details
(Keywords: dogfood, unagi)
Over on bug 802418 I got the information that wifi gets disabled when the device is put into sleep mode. It's to ensure that we save the battery. But I question that this is helpful, especially when the mobile data connection is getting enabled instead. I can't say what the power consumption is for the wifi or the 3G/2G controller but from my experience with other phones and from technical reviews I got that wifi consumes lesser power than a 3G controller. If that's correct, we wouldn't safe the battery but drain it even faster. Additionally we have to keep in mind that disabling wifi will cause the mobile data connection to be enabled. This will cause extra traffic for the user by data transfers of background applications. As result mobile users with a tiny mobile plan will earlier reach their limit, and will be dropped to 2G or will have to pay extra. So I think that we should keep the wifi connection enabled in sleep mode as long as it is available. Once you are out of reach we can disable it and make use of the mobile data connection (if enabled by the user). Whenever you come back into the reach, wifi should be automatically reconnected even while the device is in sleep mode. Not sure if that can become a blocker but it should at least be discussed.
Reporter | ||
Comment 1•12 years ago
|
||
Additionally I'm not sure about features of possible apps on such a phone, but if we allow background updates for apps while the phone is in sleep mode, e.g. a RSS reader downloading the full article content for offline mode reading, we would use the mobile data connection. Even harder it is if such a download is tied to an active wifi connection. That means whenever you want to update your locally cached articles, you have to turn on your phone to not exceed your mobile traffic over time.
Comment 2•12 years ago
|
||
basecamp- as this is intentional behaviour for v1. We can look to change the behaviour in a future version. Blake - cced you in case you have any comments on this one.
blocking-basecamp: ? → -
Reporter | ||
Comment 3•12 years ago
|
||
When do we actually check for updates? I haven't gotten a notification about an update since 2 days now given that the phone was mostly in sleep mode. Do we only check automatically when wireless is active? That would be another example why it would be important to not disable WIFI in sleep mode.
Flags: needinfo?(dhylands)
Comment 4•12 years ago
|
||
My understanding is that it checks once per day. If it's not online at the time it checks, then it sets up a listener and tries to resume when it comes back online again.
Flags: needinfo?(dhylands)
Reporter | ||
Comment 5•12 years ago
|
||
(In reply to Dave Hylands [:dhylands] from comment #4) > If it's not online at the time it checks, then it sets up a listener and > tries to resume when it comes back online again. Which delay will this listener have? Is it long enough to miss activity which takes about 5 minutes? I really don't get the update notification daily but sporadically whenever I didn't let my phone fall into sleep.
Comment 6•12 years ago
|
||
+1 for not disabling wifi when screen goes off, it's really annoying. This should be an opt-in preference under wifi settings. Even updates are interrupted by this behaviour and a lot of battery is drained switching to 3G and back to wifi+connecting AP...
Comment 7•12 years ago
|
||
Bug 859895 - Make wifi timeout build-configurable is landed, we can disable wifi automatically turn off by modifying wifi.screen_off_timeout to 0 in gaia/build/settings.py.
Comment 8•12 years ago
|
||
Hi, I was trying a chat app on a Keon device, and with this behaviour is not possible at all to run an app that should be online all the time. Shouldn't this be blocker to allow these kind of demanded apps be functional on launch?
blocking-basecamp: - → ?
Reporter | ||
Comment 9•12 years ago
|
||
AFAIK we don't block on basecamp anymore. Moving to leo.
blocking-b2g: --- → leo?
blocking-basecamp: ? → ---
Comment 10•12 years ago
|
||
ni? product as current behaviour was previously decided. Need product to comment if this needs to be reviewed so that Wifi is kept enabled when device enters sleep.
Flags: needinfo?(ffos-product)
For Push notifications, we'd like to keep a connection open for as long as possible. When wifi is disabled on sleep, push has to switch to 3g to receive notifications. This is not a very large data hit when there are no notifications. I've no idea about relative power consumption. On the other hand, if the user is in a place with no 3g/data connectivity, but is connected to wifi, disconnecting the wifi means that push isn't really push anymore. The network stack does not detect when a socket open is attempted. At the least wifi should reconnect if some process tries a network operation. The other annoying thing when 3g and wifi both are available, with respect to push, is: 1) User connected via WiFi, push socket is over WiFi. 2) Phone goes to sleep, socket switches over to 3G. 3) User gets a notification, switches on display. 4) Sigh... push socket switches over to WiFi again. This cycle will continue.
Comment 12•12 years ago
|
||
Also switching to 3G is a lot more power consuming than Wifi. This means if a leave the phone at night at home, it's going to use my 3G data and more battery.
Comment 13•12 years ago
|
||
Product - please renominate if you feel this should be a blocker for a future release.
blocking-b2g: leo? → -
Comment 14•12 years ago
|
||
We will consider this for Koi.
blocking-b2g: - → koi?
Flags: needinfo?(ffos-product)
Comment 15•12 years ago
|
||
This can be solved by build time configuration in comment 7. Do we need it to be run time configurable?
Comment 18•11 years ago
|
||
What is the UX need here? Please clarify and we'll triage. Thanks!
Comment 19•11 years ago
|
||
Hi there- I'm going to assign needs info to Mike in Taipei. He can help to work with Carrie and Juwei to get feedback. Thanks! Jaime
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(mtsai)
Comment 20•11 years ago
|
||
Hi All, Can anyone prove that ? (The WiFi consumes lesser power than a 3G controller)
Flags: needinfo?(kchang)
Comment 21•11 years ago
|
||
Excuse me, Are we talking about sleep mode = suspend ? I don't think we have sleep mode or power saving mode in our device. This can cause different solutions and discussions. Thank you.
Flags: needinfo?(mtsai)
Reporter | ||
Comment 22•11 years ago
|
||
Isn't it called sleep mode when you turn off the screen via the power button? That's what I got from various other bugs.
Comment 23•11 years ago
|
||
Peter, What is the expectation here with Wifi. This seems to be going in circles and we need guidance here.
Flags: needinfo?(pdolanjski)
Comment 24•11 years ago
|
||
(In reply to Neo Hsieh from comment #20) > Hi All, Can anyone prove that ? > (The WiFi consumes lesser power than a 3G controller) Theoretically, the wifi component consumes lesser power than a 3G radio component in "connection" mode. But it is better to directly measure the power consumption of device.
Flags: needinfo?(kchang)
Updated•11 years ago
|
blocking-b2g: koi? → 1.3?
Comment 25•11 years ago
|
||
IRC with Pdol this is a feature where requirements are getting spec'ed. So agree with 1.3?
Flags: needinfo?(pdolanjski)
Comment 26•11 years ago
|
||
Sandip is checking with the RIL team on the possibility of addressing this in 1.3.
Flags: needinfo?(skamat)
Comment 27•11 years ago
|
||
I wonder if we can handle this issue. In current OEM design, wifi can not enter the deep sleep mode. That means the WIFI has more power consumption than 3G data call during the sleep mode. If we really want to have keep wifi on and have the better power consumption during sleep mode, we need OEM's support to have a wifi chip/component enabling deep sleep mode.
Comment 28•11 years ago
|
||
(In reply to Ken Chang from comment #27) > I wonder if we can handle this issue. In current OEM design, wifi can not > enter the deep sleep mode. That means the WIFI has more power consumption > than 3G data call during the sleep mode. > If we really want to have keep wifi on and have the better power consumption > during sleep mode, > we need OEM's support to have a wifi chip/component enabling deep sleep mode. Can we just provide the option to enable/disable wifi during sleep mode for v1.3? We can have OEM make the decision of changing the defaults (and further optimizing the power consumption later).
Flags: needinfo?(skamat)
Comment 29•11 years ago
|
||
Have commented in https://bugzilla.mozilla.org/show_bug.cgi?id=930972#c5
Comment 30•11 years ago
|
||
This is being addressed as part of the feature in bug 930972, so I'm duping over there.
Status: NEW → RESOLVED
blocking-b2g: 1.3? → ---
Closed: 11 years ago
Resolution: --- → DUPLICATE
Comment 31•11 years ago
|
||
It is not a duplicate of bug 930972, but a blocker for 930972.
Comment 32•11 years ago
|
||
This doesn't fall under the QC blocking feature list & DSDS feature list. Renoming.
blocking-b2g: 1.4+ → 1.4?
Updated•11 years ago
|
blocking-b2g: 1.4? → backlog
Comment 34•11 years ago
|
||
After fixing bug 979130 and 960623, we don't need to fix this. Everyone who want WIFI to keep waking up just can use that wifilock mechanism.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Flags: needinfo?(kchang)
Resolution: --- → WONTFIX
Reporter | ||
Comment 35•11 years ago
|
||
(In reply to Ken Chang[:ken] from comment #34) > After fixing bug 979130 and 960623, we don't need to fix this. Everyone who > want WIFI to keep waking up just can use that wifilock mechanism. My original request with that bug was to not get wifi disabled during sleep mode. With the bugs you pointed out here, this got fixed. So not sure why you set this bug as wontfix.
Resolution: WONTFIX → FIXED
Assignee | ||
Updated•10 years ago
|
blocking-b2g: backlog → ---
tracking-b2g:
--- → backlog
You need to log in
before you can comment on or make changes to this bug.
Description
•