Closed Bug 1020872 Opened 10 years ago Closed 6 years ago

[OFFLINE EXPERIENCE] The offline error is not displayed if the device is connected to a wifi network without internet

Categories

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

Other
Other
defect
Not set
normal

Tracking

(b2g-v1.3 affected, b2g-v1.4 affected, b2g-v2.0 affected)

RESOLVED WONTFIX
Tracking Status
b2g-v1.3 --- affected
b2g-v1.4 --- affected
b2g-v2.0 --- affected

People

(Reporter: rafael.marquez, Unassigned)

Details

(Whiteboard: [systemsfe])

*Pre-requisites :
Data disabled
Wifi enabled and device connect to a wifi network without internet connection


*Procedure:
1. Go to HomeScreen
2. Try to open Marketplace app while the devices is connected to a wifi network without internet connection

*Expected result:
A error screen "No access to the internet right now with the button "Check Settings" is displayed

*Actual result
The offline error is not displayed. The device, continuous loading for many minutes but it doesn't display the error
We have the same behavior if we try to open a web page in the browser
Whiteboard: [systemsfe]
Michael, do you know the proper component?
Flags: needinfo?(mhenretty)
Stephen, quick before you switch to an iPhone.... ;)


Looks like timeout errors are not propagating to b2g correctly. Do you know who could help us with this issue? Or what component it belongs in?
Flags: needinfo?(mhenretty) → needinfo?(sworkman)
Some thoughts/questions:

1. How long did you wait for the timeout? Since we're connected to wifi, the only way to detect that we're not connected to the internet is to wait for DNS/Socket/HTTP timeouts. 5 minutes for HTTP on its own.

2. Were you able to connect to marketplace in the same session? I.e. did you switch networks to one without wifi? Or were you on the same wifi network and disable internet connectivity on the wifi side?

If so, it's possible that bug 939318 may be related. In that bug Daniel is working on resetting some of our cached state (DNS cache, HTTP connection pool, proxy config etc.) at network change events. It's possible that you may be experiencing stale cache information. Note, that bug is specifically for Windows and common code; the FxOS-specific parts are next on Daniel's list. Also note that if you're maintaining the connection to wifi, but dropping internet on the wifi side then this bug may not help ... but we should still be seeing timeouts in that case.

If you can, please play around with different scenarios of internet/no-internet including no internet from bootup. Document all of these scenarios and this will help diagnosis.

3. NSPR_LOG_MODULES=nsHttp:5 We'll need that to get a peek at what's happening in Necko. Hopefully, we'll be able to see if the time out is happening or not.

4. I assume the Necko client is DocShell here - you're just loading an HTML page, right?
Flags: needinfo?(sworkman)
blocking-b2g: --- → 2.0?
Any news about it?
My test is simple.
I am connected to a wireless network which has no internet. When I try to open a webpage the device remains loading the webpage during 2 or 3 min
Does this happen on 1.4?
Keywords: qawanted
(In reply to Jason Smith [:jsmith] from comment #5)
> Does this happen on 1.4?

Negative.
On 1.4 the message "Unable to connect" appears in both the browser and the Marketplace app.

Device: Buri 1.4
Build ID: 20140611000202
Gaia: d1cf95dc5e8b2f52148487291318542f1396608e
Gecko: a8bb6b76696b
Version: 30.0 (1.4) 
Firmware Version: v1.2device.cfg
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
Occurs on 2.0 but not 1.4

Adding regressionwindow-wanted tag
Flags: needinfo?(jmitchell)
Assignee: nobody → rkunkel
Assignee: rkunkel → nobody
QA Contact: rkunkel
While attempting to find a regression window it was found that the issue will reproduce on the latest v1.4 Buri build:

Environmental Variables:
Device: Buri 1.4
BuildID: 20140612000202
Gaia: 7fc73d4cb1bece31f50e8ccf6fb98af3984a9ebf
Gecko: bcd308fbbf38
Version: 30.0
Firmware Version: V1.2-device.cfg

-

1. Connect to a remote network access without internet connection
2. Attempt to open marketplace
3. Observe "Unable to connect" page takes between 2 and 3 minutes to fully load. (Comment #4)
Flags: needinfo?(jmitchell)
Removing Regression keyword - not proven to be a regression yet

QA-Wanted to do the rest of the branch checks - starting with Buri 1.3
Flags: needinfo?(jmitchell)
Keywords: regressionqawanted
This issue does NOT reproduce on the latest v1.3 Buri build:

Environmental Variables:
Device: Buri 1.3
BuildID: 20140612024004
Gaia: 20cce4e5dd3ca7dfffc82ce1dce71741dd446952
Gecko: 233d0d0ea774
Version: 28.0
Firmware Version: V1.2-device.cfg

-

The "Unable to connect" page takes less than 7 seconds to load

1) Adding regression, regressionwindow-wanted keywords
2) Starting regression window
blocking-b2g: 2.0? → 1.4?
Hi Rafael,

Quick question about the network you were connecting to.

While testing this issue with a properly configured router without internet, the "Unable to connect" error pages displays as expected.

While testing this issue with a router incorrectly configured for guest access, this issue will reproduce as in your report. 

This was the cause for the conflicting results in comment #8 and comment #6

Under what configuration and network mode is your connection to the DuT?
Flags: needinfo?(rafael.marquez)
1º. Offline experience was developed in version 2.0. If you run the same test in previous branches, it is impossible to have the same result as me.

2º I have a router with a wifi network set. The router is not connected to internet. It is no bad configuration. Simply nothing connected to the router.
Flags: needinfo?(rafael.marquez)
We have to decide on the use-case we want to solve here and then decide if 1.4 is affected.
QA, can you help out on specifying the bug we have to fix for 1.4 and file a followup for 2.0 if necessary?
I don't know which else I can do.
Is this what we bug is about?

2º I have a router with a wifi network set. The router is not connected to internet. It is no bad configuration. Simply nothing connected to the router.

Steve, what is the expected behavior here?
Flags: needinfo?(sworkman)
QA Wanted - can we explicitly call out the difference in the behavior seen on 1.4 vs. 2.0 right now? The comments above imply that there should be a difference, but the testing might not be in alignment with that analysis.
QA Contact: rkunkel → lmauritson
(In reply to Gregor Wagner [:gwagner] from comment #15)
> 2º I have a router with a wifi network set. The router is not connected to
> internet. It is no bad configuration. Simply nothing connected to the router.
> 
> Steve, what is the expected behavior here?

tl;dr - If the phone is connected to wifi, but wifi is not connected to the internet, I wouldn't be surprised to see long timeouts.

Some details:
There are a couple of things I would expect here, depending on how the phone/router was connected previously. Note though that I'm speaking about Gecko behavior - the notification in the UI is Gaia-specific, I believe. And you might want to check with someone who works on NetworkManager.js which is B2G specific.

1. If the router was connected to the internet before, and then disconnected, it's probable that the phone's network config has not changed. In this case, the phone may be trying to reach the DNS server to get name resolution and is timing out. OR, it may already have an IP address for marketplace and is timing out trying to reach that. In both cases, potentially long timeouts.

2. If the router was not connected to the internet before and the phone was switched on in this way, I'm not 100% sure. It depends on how the Wifi connection is setup. It's possible that the router is assigning a DNS server along with an IP address, in which case we'd still see the DNS timeout. If no DNS is assigned, I'd expect a quicker timeout here.

I'd like to get input from someone who's worked on NetworkManager.js to find out what happens at that level. But as far as Gecko is concerned, if the phone is connected to WiFi, at some level it is connected and may not know that it doesn't really have a connection to the internet.

Needinfo:jessica who most recently patched NetworkManager.js. Jessica, can you tell us how NetworkManager.js works if the phone is connected to wifi, but there is no internet connection from wifi? Also, what happens in the lower layers if there is a change in network? (Please needinfo someone else if you're not the right person to answer this :) ).
Flags: needinfo?(sworkman) → needinfo?(jjong)
From NetworkManager's pint of view, once wifi (or data call) state changes to CONNECTED, routes are set accordingly and the 'Services.io.offline' flag is toggled to false, no matter the internet is reachable or not. Setting 'Services.io.offline' to false, means that gecko is in online mode, so DNS Service, sockets, and other network services will work as usual. In this case, the phone relies on socket timeouts to know whether internet is reachable or not.

NetworkManager will also start a captive portal detection once wifi gets CONNECTED, but I don't think it affects any of the behaviour here.

Note that, when wifi state turns to DISCONNECTED, 'Services.io.offline' flag is toggled again to true.

CCing :vchang to see if he has anything to add. :)
Flags: needinfo?(jjong)
(In reply to Jessica Jong [:jjong] [:jessica] from comment #18)

Thanks Jessica!

> In this
> case, the phone relies on socket timeouts to know whether internet is
> reachable or not.

I would expect 2-3 min timeouts for that.

> NetworkManager will also start a captive portal detection once wifi gets
> CONNECTED, but I don't think it affects any of the behaviour here.

Good to know.
(In reply to Jason Smith [:jsmith] from comment #16)
> QA Wanted - can we explicitly call out the difference in the behavior seen
> on 1.4 vs. 2.0 right now? The comments above imply that there should be a
> difference, but the testing might not be in alignment with that analysis.

To clarify the results, a router that is simply disconnected from the internet but otherwise accessible will not cause any issues on the device. The error message about not being able to connect will appear after only a moment.
This can be seen in this video: http://youtu.be/IMHNA8Xh5oM

Connecting to a router with a guest portal that is not signed in to will cause the device to continue "loading" and will never show any error messages about not being able to connect. My guess would be that "connected" returns true, but because the guest portal redirects to the login page until the user logs in the marketplace app will never get the information it is seeking.
This can be seen here: http://youtu.be/9a0BWrLj_ws

There is no difference between 1.4 and 2.0 in either case. They both act the same as the other in the same situation.

Variables for devices used:

Device: Buri 1.4
BuildID: 20140618000203
Gaia: 3bdd037ec1a11abebe16a5d7f6ff0d863e80bc07
Gecko: 523491fa3339
Version: 30.0 (1.4) 
Firmware Version: v1.2device.cfg


Device: Buri 2.0
BuildID: 20140618000202
Gaia: 83844c7679b3b9f6e7f1116c1eeec2d1e7a64eec
Gecko: 55679dc2e72b
Version: 32.0a2 (2.0) 
Firmware Version: v1.2device.cfg


Device: Flame 1.4
BuildID: 20140618000203
Gaia: 3bdd037ec1a11abebe16a5d7f6ff0d863e80bc07
Gecko: 523491fa3339
Version: 30.0 (1.4) 
Firmware Version: v121-2


Device: Flame 2.0
BuildID: 20140618000202
Gaia: 83844c7679b3b9f6e7f1116c1eeec2d1e7a64eec
Gecko: 55679dc2e72b
Version: 32.0a2 (2.0) 
Firmware Version: v121-2
Flags: needinfo?(jmitchell)
Keywords: qawanted
Flags: needinfo?(jmitchell)
Moving to 2.0? based on comment 12.
blocking-b2g: 1.4? → 2.0?
(In reply to Preeti Raghunath(:Preeti) from comment #21)
> Moving to 2.0? based on comment 12.

comment 12's testing is invalid. comment 20 just proved this is a regression between 1.3 --> 1.4.
blocking-b2g: 2.0? → 1.4?
Josh - Regression Window Wanted should have been added here again post the needinfo request here.
Flags: needinfo?(jmitchell)
Gregor,

Please reassign.
blocking-b2g: 1.4? → 1.4+
Flags: needinfo?(anygregor)
(In reply to Jason Smith [:jsmith] from comment #23)
> Josh - Regression Window Wanted should have been added here again post the
> needinfo request here.

Acknowledged!
Flags: needinfo?(jmitchell)
This issue goes back as far as I can test in central-hamachi-eng.

When connected to a router that is simply unplugged from the internet the "No connection" warning shows immediately.

When connected to a router with a guest portal (And not having entered the password) the marketplace app appears to load indefinitely.

Device: Buri Master
BuildID: 20140123122803
Gaia: 00d8d05f0d0730a3cbf17635ad6a6b197a2ce7c9
Gecko: c0df37c18e54
Version: 29.0a1 (Master) 
Firmware Version: v1.2device.cfg
Flags: needinfo?(jmitchell)
So we're absolutely sure then that this doesn't repro on 1.3? Can we double check?
Keywords: qawanted
Flags: needinfo?(jmitchell)
(In reply to Jason Smith [:jsmith] from comment #27)
> So we're absolutely sure then that this doesn't repro on 1.3? Can we double
> check?

The following is true on 1.3:

When connected to a router that is simply unplugged from the internet the "No connection" warning shows immediately.

When connected to a router with a guest portal (And not having entered the password) the marketplace app appears to load indefinitely.

My evidence can be seen here: http://youtu.be/mnjxox_GQo0

Device: Buri 1.3
BuildID: 20140619024031
Gaia: 5f4211ac94cc158a07269d0a0beca3c7937d78cc
Gecko: 64c14d11b5cf
Version: 28.0 (1.3) 
Firmware Version: v1.2device.cfg
Flags: needinfo?(jmitchell)
Flags: needinfo?(jmitchell)
Keywords: qawanted
So are you saying this is reproducing on 1.3 or not?
Flags: needinfo?(lmauritson)
(In reply to Jason Smith [:jsmith] from comment #29)
> So are you saying this is reproducing on 1.3 or not?

The result is the same as on the other builds I tested, so yes. 
I felt "this" was ambiguous as there appeared to be conflicting results based on router setup, so I wanted to be clear.
Flags: needinfo?(lmauritson)
(In reply to Lionel Mauritson from comment #30)
> (In reply to Jason Smith [:jsmith] from comment #29)
> > So are you saying this is reproducing on 1.3 or not?
> 
> The result is the same as on the other builds I tested, so yes. 
> I felt "this" was ambiguous as there appeared to be conflicting results
> based on router setup, so I wanted to be clear.

I went and confused myself...
If you mean the issue where it loads forever based on a simply disconnected router, then NO it does NOT occur on 1.3.
If you mean the issue where it loads forever based on being connected to a guest portal, then YES, it DOES occur on 1.3.
Clearing blocking flag since this is a long standing issue.
blocking-b2g: 1.4+ → ---
Keywords: regression
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Flags: needinfo?(anygregor)
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.