1188617 - [Aries][Utility Tray] Re-enabling wi-fi from notification tray automatically launches Settings app.

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Wifi, defect, P3)

Description

[Nicholas Nelson [:NicholasN]]

Attachment: logcat_wifi.txt

Description:
Re-enabling wi-fi from notification tray automatically luanches Settings app.


Repro Steps:
1) Update a Aries to 20150728162417
2) Go to Settings, enable wi-fi and conntect to a network.
3) Close settings and swipe down to open the utility tray from the homescreen.
4) Tap the wi-fi symbol to disable wi-fi.
5) Tap the wi-fi symbol to re-enable wi-fi.


Actual:
Settings app is automatically launched.


Expected:
User is reconnected to the network they previously selected without launching Settings.


Notes:

Environmental Variables:
Device: Aries 2.5
Build ID: 20150728162417
Gaia: 302a448729ff2b336581cf94b66327ea836294c7
Gecko: cd9fa05c943e6784faeeaff7c027d1b561c070b0
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 42.0a1 (2.5)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0


Repro frequency: 5/5
See attached:  video clip, logcat

Comment 1

[Nicholas Nelson [:NicholasN]]

Issue reproduces on earlier Aries builds but does not reproduce on Flame 2.5.

Aries (RC4)

Actual Result:

Settings app is automatically launched.

Environmental Variables:
Device: Aries 2.5
BuildID: 20150619225606
Gaia: 4c06ed88ddccaba8dc941e5006bd2a9e57306f07
Gecko: 7c1a6b1151a1539186b950a144387e2d7f378d1b
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 41.0a1 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0


Flame 2.5

Actual Result:

Wi-fi is re-enabled without opening Settings app.

Environmental Variables:
Device: Flame 2.5
BuildID: 20150728030208
Gaia: 14e32276025b0310d3e89027320cf4b2a24cedfb
Gecko: 33dc8a83cfc0
Gonk: 41d3e221039d1c4486fc13ff26793a7a39226423
Version: 42.0a1 (2.5) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

Comment 2

[Peter Bylenga [:PBylenga]]

[Blocking Requested - why for this release]:
Regression from flame behavior, this was deemed a blocker and fixed in previous releases.

Comment 3

[Ken Chang[:kenkai]]

Winnie, an interesting bug. Please take a look.

Comment 4

[XiaoLe Sun]

(In reply to Ken Chang[:ken] from comment #3)
> Winnie, an interesting bug. Please take a look.

Okay, thanks! :)

Comment 5

[XiaoLe Sun]

Hi, Harly!

I found this bug seems duplicate with others which were solved.
<U>bug 805289</U> <U>bug 1191228</U>

In the <U>bug 805289, comment 18</U>, there is a conclusion about this behavior.

It's now waiting 2 seconds for scanning APs. If the scanning is out of time, the Settings app pops out. I have tried to extended the waiting time to 10 seconds, and it works.(Connected successfully, and the Settings app doesn't launch.)

Is there any modification in need?

Thanks! :)

Comment 6

[Harly Hsu[:harly]]

Hi XiaoLe, I am wondering if you could provide the current waiting time on Flame? Cause it doesn't seem to happen on Flame device.

Comment 7

[XiaoLe Sun]

Hi~

I found it is also 2 seconds......

The definition I saw is in gaia/apps/system/js/quick_settings.js :24 "WIFI_STATUSCHANGE_TIMEOUT".

Comment 8

[Harly Hsu[:harly]]

Hmm, then why Flame doesn't seem to have this kind of problem but Aries has? Does tweaking on the waiting time help in this case?

Comment 9

[XiaoLe Sun]

Oh~ I have just asked my mentor this question!

It seems that Aries scans slower than Flame does! So, when I extend the waiting time, it works.

So... it seems like a feature not a bug!

Comment 10

[Ken Chang[:kenkai]]

Xiaole, in the following code, the wifi state is in disconnected state. But I wonder if we could have the *scanning* state to indicate that the current state is in scanning the networks.
https://github.com/mozilla-b2g/gaia/commit/651379a40188da133b52fb6408cc7dfb16c2d1d0#diff-c6f6a93ef2f3dacce1ce5b6dcf60b793R267

Comment 11

[XiaoLe Sun]

Hmm...there isn't *scanning* state definition in "MozWifiManager.webidl" now. But I wonder if there could be, what can we do with this state? That is, if the state is now in *scanning*, shall we just keep waiting and don't pop out the settings app, until the state change to *disconnected*? In this case, maybe we don't have to set the waiting time~

Comment 12

[Ken Chang[:kenkai]]

(In reply to XiaoLe Sun from comment #11)
> Hmm...there isn't *scanning* state definition in "MozWifiManager.webidl"
> now. But I wonder if there could be, what can we do with this state? That
> is, if the state is now in *scanning*, shall we just keep waiting and don't
> pop out the settings app, until the state change to *disconnected*? In this
> case, maybe we don't have to set the waiting time~
Yes. But if there isn't *scanning* state now, we need to consider if adding *scanning* status could cause any problem in other code flows using mozwifimanager.

Comment 13

[Harly Hsu[:harly]]

I don't see this as a hardware case by case issue. We should have a global waiting time for all devices rather than treating each device differently.

Comment 14

[Ken Chang[:kenkai]]

(In reply to Harly Hsu[:harly] from comment #13)
> I don't see this as a hardware case by case issue. We should have a global
> waiting time for all devices rather than treating each device differently.

Per user experience design, how long should user wait for a connection establishment?

Comment 15

[Harly Hsu[:harly]]

I think we need to first identify why Aries scans slower than Flame, is it something we can improve? If not, then we can set a global waiting time that works for all devices. Also, we have a guideline related to performance that stated if the user needs to wait for more than 1 second, we should provide some kind of visual feedbacks.

Comment 16

[Ken Chang[:kenkai]]

(In reply to Harly Hsu[:harly] from comment #15)
> I think we need to first identify why Aries scans slower than Flame, is it
> something we can improve? If not, then we can set a global waiting time that
No, according to XiaoLe, it is related to wifi driver or chip which isn't controlled by us.

> works for all devices. Also, we have a guideline related to performance that
> stated if the user needs to wait for more than 1 second, we should provide
> some kind of visual feedbacks.

Comment 17

[Harly Hsu[:harly]]

I have tested on Nexus 5 running on Android, it took almost 19 seconds after user turned on Wifi from notification tray, and it will display a notification saying that there are Wifi network available. However, it is a bit too long, so I am thinking let's use 10 seconds for now, but we still need to display some sort of visual feedback. I am thinking is it possible to add a animation to the button on the notification tray similar to what we have on the status bar? (see video for reference https://youtu.be/FZGWxNiNbT4)

Comment 18

[Henry Chang [:hchang]]

I don't know the reason that this bug was filed and set as a blocker.

If the reason is 

1. "Why the settings app pops up?", 

then just never ever automatically launch the settings app after enabling 
wifi through the utility tray and problem solved.

If the reason is 

2. "Sure I know it may pop up but it pops up too soon (or too late.)", 

then we have to find out the correct and exact timing to launch the 
settings app automatically. Unfortunately I don't have a answer to this. 
I mean the well-define timing like "after the first-run scan and we still
cannot connect to any of the known APs."

If the reason is 

3. "It pops up in the correct timing (whatever) but it gets re-connected to wifi too slow!"

then we should stop being worried about the timeout value or thinking of the
new UX. Just focus on making wifi connection faster.

Comment 19

[Ken Chang[:kenkai]]

Here is the summary and I don't think this is a blocker.
1. Currently, we set 2s as the timeout of scanning wifi network.
2. Device have to jump to setting app After timeout.
=> So the situation described in this bug is the right scenario.
Aries cannot connect to a wifi in 2s. Then Aries jumps to setting app.

Another question is why Aries isn't able to find a network in 2s? it is a hardware/BSP relevant bug.
If we believe 2s is the appropriate timeout period for users to wait for a wifi connection,
then I don't think we should change it according to Aries' hardware scenario. 
That means we don't need to change any thing unless we would like to change the timeout period
defined by UX.

Comment 20

[BMO Automation]

Firefox OS is not being worked on