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)
Tracking
(b2g-v1.3 affected, b2g-v1.4 affected, b2g-v2.0 affected)
RESOLVED
WONTFIX
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
Reporter | ||
Updated•10 years ago
|
Whiteboard: [systemsfe]
Comment 2•10 years ago
|
||
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)
Comment 3•10 years ago
|
||
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)
Reporter | ||
Updated•10 years ago
|
blocking-b2g: --- → 2.0?
Reporter | ||
Comment 4•10 years ago
|
||
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
Comment 6•10 years ago
|
||
(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
Comment 7•10 years ago
|
||
Occurs on 2.0 but not 1.4 Adding regressionwindow-wanted tag
Flags: needinfo?(jmitchell)
Keywords: regression,
regressionwindow-wanted
Updated•10 years ago
|
Assignee: nobody → rkunkel
Updated•10 years ago
|
Assignee: rkunkel → nobody
QA Contact: rkunkel
Comment 8•10 years ago
|
||
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)
status-b2g-v1.4:
--- → affected
status-b2g-v2.0:
--- → affected
Flags: needinfo?(jmitchell)
Keywords: regressionwindow-wanted
Comment 9•10 years ago
|
||
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: regression → qawanted
Comment 10•10 years ago
|
||
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
status-b2g-v1.3:
--- → unaffected
Updated•10 years ago
|
blocking-b2g: 2.0? → 1.4?
Comment 11•10 years ago
|
||
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)
Reporter | ||
Comment 12•10 years ago
|
||
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)
Comment 13•10 years ago
|
||
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?
Reporter | ||
Comment 14•10 years ago
|
||
I don't know which else I can do.
Comment 15•10 years ago
|
||
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)
Comment 16•10 years ago
|
||
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.
Keywords: regressionwindow-wanted → qawanted
Updated•10 years ago
|
QA Contact: rkunkel → lmauritson
Comment 17•10 years ago
|
||
(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)
Comment 18•10 years ago
|
||
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)
Comment 19•10 years ago
|
||
(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.
Comment 20•10 years ago
|
||
(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
Updated•10 years ago
|
Flags: needinfo?(jmitchell)
Comment 22•10 years ago
|
||
(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?
Comment 23•10 years ago
|
||
Josh - Regression Window Wanted should have been added here again post the needinfo request here.
Flags: needinfo?(jmitchell)
Comment 24•10 years ago
|
||
Gregor, Please reassign.
blocking-b2g: 1.4? → 1.4+
Flags: needinfo?(anygregor)
Comment 25•10 years ago
|
||
(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)
Updated•10 years ago
|
Keywords: regressionwindow-wanted
Comment 26•10 years ago
|
||
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)
Keywords: regressionwindow-wanted
Comment 27•10 years ago
|
||
So we're absolutely sure then that this doesn't repro on 1.3? Can we double check?
Keywords: qawanted
Updated•10 years ago
|
Flags: needinfo?(jmitchell)
Comment 28•10 years ago
|
||
(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
Updated•10 years ago
|
Flags: needinfo?(jmitchell)
Updated•10 years ago
|
Flags: needinfo?(jmitchell)
Comment 29•10 years ago
|
||
So are you saying this is reproducing on 1.3 or not?
Flags: needinfo?(lmauritson)
Comment 30•10 years ago
|
||
(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)
Comment 31•10 years ago
|
||
(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.
Comment 32•10 years ago
|
||
Clearing blocking flag since this is a long standing issue.
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Updated•10 years ago
|
Flags: needinfo?(anygregor)
Comment 33•6 years ago
|
||
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.
Description
•