Chris Jones [:cjones] inactive; ni?/f?/r? if you need me Reporter
	Description • 12 years ago

STR
 (1) Open system tray
 (2) Disable wifi
 (3) Enable wifi

The settings app is quite unexpectedly launched.  When it finally loads all the code needed to configure every setting in the system, it tells me that wpa_supplicant had already connected to my primary already-configured network.  That's not helpful at all.

Is this intentional or is there a system message being crossed somewhere?

	Josh Carpenter [:jcarpenter]
	Comment 1 • 12 years ago

Larissa can you comment on this one?

	Larissa Co [:lco]
	Comment 2 • 12 years ago

No, this is definitely not intentional. I suspect what's happening is that it's trying to get to a list of networks to connect to (This shouldn't occur when there's already a saved network anyway).

The intended behavior is as follows:

Case 1: The user is within range of a saved network
1. Tap Wi-Fi in quick settings to turn it on
2. Phone automatically connects to the saved network in range

Case 2: The user is not within range of a saved network
1. Tap Wi-Fi in quick settings to turn it on
2. List of Available networks shows up in an Action Sheet
3. User selects a network, enters password if necessary to connect
4. Once connected, the user is brought back to the home screen.

cc Casey, I believe he might have been working more closely with Marco on this one.

	Chris Jones [:cjones] inactive; ni?/f?/r? if you need me Reporter
	Comment 5 • 12 years ago

Per UX, this isn't working as intended.

Not necessarily suggesting bb+, but this is definitely a bug.

	Casey Yee
	Comment 6 • 12 years ago

This certainly is not intended and should be fixed.

The intended behavior as Larissa described is correct.

renomming for fix.

cc Marco for further comment is necessary.

	David Scravaglieri [:scravag]
	Comment 7 • 12 years ago

We would take a patch but we wouldn't block on this issue for V1.

	marcoc
	Comment 8 • 12 years ago

(In reply to Casey Yee [:cyee] from comment #6)
> This certainly is not intended and should be fixed.
> 
> The intended behavior as Larissa described is correct.
> 
> renomming for fix.
> 
> cc Marco for further comment is necessary.

I agree with Larissa's flow in Comment 2. 
Casey, is there anything in particular you wanted me to comment on?

	KM Lee [:rexboy] (inactivate after Sep. 22) Assignee
	Comment 9 • 12 years ago

Working on this but I found something need to be discussed on case 2.  When toggling  Wifi on, it needs a bit seconds to scan known networks around.  So we need additional, say, 5 to 10 seconds to wait for the event confirming there's no network to connect, and popup setting apps after that.  I think this may be a little confusing for users if they're doing something else.  Would this be acceptable?

	KM Lee [:rexboy] (inactivate after Sep. 22) Assignee
	Comment 10 • 12 years ago

Larissa, may you take a look at comment 9?

	Larissa Co [:lco]
	Comment 12 • 12 years ago

(In reply to KM Lee [:rexboy] from comment #9)
> Working on this but I found something need to be discussed on case 2.  When
> toggling  Wifi on, it needs a bit seconds to scan known networks around.  So
> we need additional, say, 5 to 10 seconds to wait for the event confirming
> there's no network to connect, and popup setting apps after that.  I think
> this may be a little confusing for users if they're doing something else. 
> Would this be acceptable?

Well, I think it's minimally acceptable. The right solution would obviously be to try and reduce the time it takes to scan. (If I interpret this issue correctly, it also means that there's a delay before the user is actually on the Internet at all).

But if we've optimized the connection time as much as we can, the stopgap fix would be to show a notification or banner saying "Searching for networks..." just so that the user knows we're doing something when he turns wi-fi on.

	KM Lee [:rexboy] (inactivate after Sep. 22) Assignee
	Comment 13 • 12 years ago

First try, may need some discussion.
Tim, may you help reviewing this patch?  Thank you!

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 14 • 12 years ago

Comment on attachment 704501 [details]
Patch

I think there's a more elegant way than scan all networks many times.

	KM Lee [:rexboy] (inactivate after Sep. 22) Assignee
	Comment 15 • 12 years ago

After discussing with Alive and Vincent, I rewrote a patch using onstatuschange event.
(I decided to send another PR since it's way different than the earlier one)
Alive, may you help review this patch?  Thanks!

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 16 • 12 years ago

Comment on attachment 707429 [details]
Patch (Use onstatuschange)

Just talk to Rex and we have some questions need UX input before the final implementation. Cancel review first.

	KM Lee [:rexboy] (inactivate after Sep. 22) Assignee
	Comment 17 • 12 years ago

As the comment above, we found that when signal is somewhat weak, it takes awhile trying to establish wifi connection.  It will retry for 3 times (said Vincent), which can take half a minute before really abort and disconnect.  This won't be the case when signal is good, but it's not a rare case.
Because of this case, the questions are mainly about the notification banner mentioned in comment #12:
* Do we need to implement the notification banner while connecting?
 - If yes, Should there also be a banner indicating we've connected to wifi, too?
 - If yes, Popping up the banner (in the bottom of screen?) may block other things on the screen for a while.  Do we need to handle it?

	KM Lee [:rexboy] (inactivate after Sep. 22) Assignee
	Comment 18 • 12 years ago

We had another talk and concluded below,
- After tapping wifi on quick settings:
  case 1: Found known wifi and trying to connect - Don't popup wifi settings whether success or not because time needed on trying is unpredictable (may be very long).
  case 2: Didn't found any known wifi at very first scan - popup wifi settings.

Notification banner wouldn't come out because we already have wifi connecting icon on the status bar.  We think this matches Comment #12, so cancelling needinfo for now.  Thanks!

	Joe Cheng [:jcheng] (please needinfo)
	Comment 19 • 12 years ago

with captive portal support in v1.0.1, this bug needs to be taken care of along with shira+ bug 834191. Shira+ this bug

	KM Lee [:rexboy] (inactivate after Sep. 22) Assignee
	Comment 20 • 12 years ago

Comment on attachment 707429 [details]
Patch (Use onstatuschange)

Let's try this patch.  Alive, may you help review it?  Thanks!

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 21 • 12 years ago

Comment on attachment 707429 [details]
Patch (Use onstatuschange)

R=me

	KM Lee [:rexboy] (inactivate after Sep. 22) Assignee
	Comment 22 • 12 years ago

Landed.  Thank you, Alive!

master: https://github.com/mozilla-b2g/gaia/commit/651379a40188da133b52fb6408cc7dfb16c2d1d0

v1-train: https://github.com/mozilla-b2g/gaia/commit/7a393bb762f8586fa0357378f966184d6ac8562c

	Lukas Blakk [:lsblakk] use ?needinfo
	Comment 23 • 12 years ago

Batch edit: Bugs fixed on b2g18 after 1/25 merge to v1.0 branch are fixed on v1.0.1 branch.

	Jeni
	Comment 24 • 12 years ago

Verified issue fixed.  Works according to comment 18 on Unagi

Build ID: 20130215070202
Kernel Dec 5
Gecko  http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/a9e4f8912607
Gaia   21ba59d933c66024cb351c2379315301d5352e0c