1010127 - [Settings] Wi-Fi list exposes configured but not in range SSIDs

Status: RESOLVED FIXED

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

Description

[:gerard-majax]

I think this has been the case for a while. Basically, the first panel of the WiFi section in Settings exposes a mixed list containing both in range and configured but not in range SSIDs.

I don't see any clear distinction between SSIDs that are not configured ; configured and in range ; and those configured but not in range. From my user perspective, it's quite unintuitive, especially since the signal power icon is available in all cases and one unconfigured network that is in range with a low signal will be seen exactly the same way as a configured network NOT in range.

Plus, the list of configured network is already available in the network management panel accessible below this list.

Comment 1

[:gerard-majax]

I'd like some inputs from the UX team regarding this topic.

Comment 2

[Stephany Wilkes]

Flagging Omega on UX. Omega, please reassign as appropriate/necessary.

Comment 3

[Omega Feng [:Omega] [:馮於懋]]

Alex, we proposed some changes in bug 988150. Could you see if your concerns still exist in the latest UX spec. Thanks!

Comment 4

[:gerard-majax]

(In reply to Omega Feng [:Omega] from comment #3)
> Alex, we proposed some changes in bug 988150. Could you see if your concerns
> still exist in the latest UX spec. Thanks!

Your UX spec are not covering this case, there is no obvious way to tell if you want it to be displayed or not.

Comment 5

[howie [:howie]]

feature not blocking, put to backlog

Comment 6

[Omega Feng [:Omega] [:馮於懋]]

ni? new UX owner Jenny.

Comment 7

[Jenny Lee]

Please see Bug 988150 for updated spec addressing this issue.

Comment 8

[:gerard-majax]

I got confused quite a lot of times recently again. When will this get fixed ?

Comment 9

[howie [:howie]]

Hi Alexandre, unfortunately teams are now fully loaded with 2.0 blockers. We might start working on this after v2.1 feature complete. ni Ravi, please consider to prioritize as future feature. Thanks.

Comment 10

[Julien Wajsberg [:julienw]]

This bugs me a lot too.

Jenny, I looked at the updated spec in bug 988150, and while there is a visual distinction between in-range AP and configured-but-not-visible AP, I wonder if there could be a bigger visual distinction. Or maybe it's more a VD call ?

Comment 11

[Jenny Lee]

(In reply to Julien Wajsberg [:julienw] (PTO Monday 14th July) from comment #10)

Hello Julien, I understand we are only showing the difference between in range AP (includes both configured and not configured ones) and configured but not in range AP. Are you suggesting that we further differentiate the in range configured/not configured AP?
I think it is nice to have but not quite necessary. I'm assuming whenever user comes to an area where there's previously configured AP, our device would connect to it automatically thus no need to go through the list trying to find a configured AP. Also had a conversation with VD about this, it is not advised to change the symbol or color or add string for this purpose. Let me know if you think otherwise, thanks!

Comment 12

[Julien Wajsberg [:julienw]]

Hey Jenny,

The main concern for me is this: when you're not in range, the various configured APs (you can have plenty of them in the real life !) clutter the view when what you're really looking for is a valid AP in range. So what I want is to have the view uncluttered in this situation.

I agree with you when the configured AP is in range: most of the time you don't need to think about it. The only exception is when the AP is a hidden AP, but maybe we probe for the known ones from time to time, I don't know.

Hope this makes sense !

Comment 13

[Jenny Lee]

(In reply to Julien Wajsberg [:julienw] (PTO Monday 14th July) from comment #12)

Right now we are placing all the not-in-range-but-configured APs down the list and without the Wi-Fi signal icon, I'd say it's enough to tell the difference ;) I'm not too sure about the hidden AP situation, it doesn't sound like something regular users would encounter though!

Comment 14

[:gerard-majax]

(In reply to Jenny Lee from comment #13)
> (In reply to Julien Wajsberg [:julienw] (PTO Monday 14th July) from comment
> #12)
> 
> Right now we are placing all the not-in-range-but-configured APs down the
> list and without the Wi-Fi signal icon, I'd say it's enough to tell the
> difference ;) I'm not too sure about the hidden AP situation, it doesn't
> sound like something regular users would encounter though!

When was this changed ? On all my recent builds (like, one/two days old), I still have a WiFi icon.

Comment 15

[Jenny Lee]

(In reply to Alexandre LISSY :gerard-majax from comment #14)
Hello Alexandre, not sure about the implementation progress but that part is covered in the latest Wi-Fi spec. Please take a look at attachment 8431455 [details] page 4, thanks!

Comment 16

[:gerard-majax]

(In reply to Jenny Lee from comment #15)
> (In reply to Alexandre LISSY :gerard-majax from comment #14)
> Hello Alexandre, not sure about the implementation progress but that part is
> covered in the latest Wi-Fi spec. Please take a look at attachment 8431455 [details]
> [details] page 4, thanks!

Thanks, so it's not yet in master, because I see the wifi sign on not in range networks :)

Comment 17

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

(In reply to Julien Wajsberg [:julienw] (PTO Monday 14th July) from comment #12)
> I agree with you when the configured AP is in range: most of the time you
> don't need to think about it. The only exception is when the AP is a hidden
> AP, but maybe we probe for the known ones from time to time, I don't know.

The only way to find hidden AP is send probe request with precise SSID.
AFAIK, most implementations won't do that scanning.

So for hidden AP situation, I think it might have only two cases:connecting(then connected or connection fail) or no signal.

Comment 18

[Julien Wajsberg [:julienw]]

(In reply to Chuck Lee [:chucklee] from comment #17)
> (In reply to Julien Wajsberg [:julienw] (PTO Monday 14th July) from comment
> #12)
> > I agree with you when the configured AP is in range: most of the time you
> > don't need to think about it. The only exception is when the AP is a hidden
> > AP, but maybe we probe for the known ones from time to time, I don't know.
> 
> The only way to find hidden AP is send probe request with precise SSID.
> AFAIK, most implementations won't do that scanning.

That's what I wasn't sure about :) I think I recall some implementations do this (eg Windows... I remember seeing probes when running airodump in the train :) ) but maybe this has changed over time.

Comment 19

[Julien Wajsberg [:julienw]]

(In reply to Jenny Lee from comment #13)
> (In reply to Julien Wajsberg [:julienw] (PTO Monday 14th July) from comment
> #12)
> 
> Right now we are placing all the not-in-range-but-configured APs down the
> list and without the Wi-Fi signal icon, I'd say it's enough to tell the
> difference ;)

I'm not so sure, I think the difference is too tiny and as a user I'd have to use my brain muscle (even if it's unconscious) to tell the difference. But well, it would be already better than the current situation, so let's see.

> I'm not too sure about the hidden AP situation, it doesn't
> sound like something regular users would encounter though!

I think it's more frequent than you think. You need one geeky child to make the family's WiFi hidden :)

Comment 20

[Ravi Dandu]

This is good to have not-in-range-but-configured APs down the list and without the Wi-Fi signal icon. 

For the hidden AP case, how much is the power consumption increase of sending probe request with the hidden SSID. That is an important consideration, to decide if we should implement it.

FYI: there is customer request to configure how the APs are chosen:   secure networks first, and open networks later. Bug 1019691 has the info on that. That will affect how the AP list is populated.

Comment 21

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

(In reply to rdandu from comment #20)
> For the hidden AP case, how much is the power consumption increase of
> sending probe request with the hidden SSID. That is an important
> consideration, to decide if we should implement it.

After checking the code, I found that we do, and only, send probe request on networks created by "join hidden network" now. So these networks would also have signal strength on scan result.
But I can't tell how many power it costs to do the probe request.

Comment 22

[Julien Wajsberg [:julienw]]

(In reply to Chuck Lee [:chucklee] from comment #21)
> (In reply to rdandu from comment #20)
> > For the hidden AP case, how much is the power consumption increase of
> > sending probe request with the hidden SSID. That is an important
> > consideration, to decide if we should implement it.
> 
> After checking the code, I found that we do, and only, send probe request on
> networks created by "join hidden network" now. So these networks would also
> have signal strength on scan result.

Note that this has security implications, because it's easy to sniff these requests, and then simulate such a network.

Comment 23

[:gerard-majax]

I've again been bugged by this ...

Comment 24

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Attachment: Pull Reqeuest (master)

Show configured but no signal AP as 'Not in range', as described in UX spec v1.3 [1], page 4, G.

[1] https://bug988150.bugzilla.mozilla.org/attachment.cgi?id=8431455

Comment 25

[EJ Chen [:eragonj][:小龍哥][Contributor mode on](inactive)]

Comment on attachment 8500927 [details] [review]
Pull Reqeuest (master)

Hey Chuck,

this patch looks nice to me and I left one comment on Github to make the order of if-else more readable. 

Thanks !

Comment 26

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Comment on attachment 8500927 [details] [review]
Pull Reqeuest (master)

Hi EJ,
  Unit tests are added, I think the pull request is ready for review.
  Thank you.

Comment 27

[EJ Chen [:eragonj][:小龍哥][Contributor mode on](inactive)]

Comment on attachment 8500927 [details] [review]
Pull Reqeuest (master)

Hi Chucklee,

I just left some comments on Github for test cases and please check them ! 

Overall, this patch looks nice to me and I think we are almost there ! 

Thanks :)

Comment 28

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Comment on attachment 8500927 [details] [review]
Pull Reqeuest (master)

Hi EJ,
  All comments are address, thanks!

Comment 29

[EJ Chen [:eragonj][:小龍哥][Contributor mode on](inactive)]

Comment on attachment 8500927 [details] [review]
Pull Reqeuest (master)

Thanks Chuck !

r+ !

Comment 30

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Gaia try is good: https://treeherder.mozilla.org/ui/#/jobs?repo=gaia-try&revision=ae1407b783e9

Comment 31

[Ryan VanderMeulen [:RyanVM]]

Master: https://github.com/mozilla-b2g/gaia/commit/dbf0f267d41e107e365705505284cd268203d7b0