684329 - Show error message after a disconnection ; Pancake should be more online/offline aware

Status: RESOLVED FIXED

(Pancake Graveyard :: Native iOS Wrapper, defect)

Description

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

1. log into iApp with proper credentials
2. disconnect the device from the network
3. go back to the iApp and logout

Expected: iApp quits
Actual: iApp remains

Note:
1 Privacy Policy tries to go to the URL even though there's no connection
2. Other selections such as the logout does nothing

iPad 2, iOS 4.3.5, Pancake .10, Production: 09022011, 13:04PDT

Comment 1

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Yes, we need a fail page with a reload button. This needs to go in the next release.

Comment 2

[Stuart Parmenter]

We should probably make the website offline aware in some form (even if it is just redirect you to a new "please reconnect" your internet site)

Comment 3

[Olivier Yiptong [:oyiptong]]

Could show a modal dialog that gives the option to try to reconnect

Comment 4

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

I'm ready to implement this but I am not totally sure how yet.

I think this is a good first approach:

First of all, we have three kinds of things that we load:

1) The three pages that make up the Pancake app (main, drawer, top)
2) Invisible AJAX requests that the above pages make to the Pancake server
3) The web browser

I think this bug only applies for 1 and 2 for now.

So, if there is a network connection but the main Pancake pages fail to load, what do we do?

I think we should do two separatr things for 1 and 2:

1 happens when the app starts up. So if any of the main pages fail then I think it is ok to show the full screen 'network error' page.

2 happens when the app has already loaded. So maybe it is better to just show a modal dialog then? I'm not sure what the options should be there though.

Comment 5

[Sam Foster [:sfoster] (he/him)]

the plan for #2 is to have a temporarily-unavailable handler in each of the *.app.js files which puts up an overlay with a message, and starts a (possibly-decaying) poll to attempt to discover when the network and/or pancake servers are contactable again.

We'll need a simple endpoint to poll to determine this - we'll send a HEAD request I guess and treat any non 0 response as success for now. 

We'll use the same xmessage mechanism as elsewhere to signal the unavailable state, so we should be able to take input from native app too. 

The goal is to not kick the user back to the start/login screen for a temporary outage (e.g. tunnnel/router reboot/whatever) and allow them to resume where they left off as long as their session is still good.

Comment 6

[Sam Foster [:sfoster] (he/him)]

In order to make the different UIWebViews and the account menu etc. unavailable when the network is unavailable, it seems like a native, modal overlay might work better than the in-page html overlays. 

See: https://bugzilla.mozilla.org/show_bug.cgi?id=745752 for the existing implementation. 

I currently publish a connection:change message: 

xmessage.sendMessage("top", "connection:change", [{ connected: false }]);
// connected:true to take down the modal

...and relay that to each of the uiwebviews. But I could just send it to native to trigger the dialog. 

For the 'try again' button, send a 'connection:try' message to main and it'll attempt a request to /ping. The way it works right now is it only sends connection:change if the outcome is different. Maybe I can send the connected value to the sendMessage callback too so the native app can update the modal even if the connection was unsuccessful.

Comment 7

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

The last iOS build has support for the above.

Some notes:

The FE does not fail immediately at the time it makes a request. I tried to shut down the server and then pull to refresh for example. It eventually finds out that the backend is down, but it take a little time.

When the FE sends the connection:change message with connected: false, we show a modal dialog. When the user hits the Try Again button, we call /ping.html to see if the backend is back. If that call succeeds, we dismiss the dialog and let the FE know by calling connection:try. THings come back to normal then.

When the modal dialog is up, the app keeps running. All the webviews are still there, timers running, events flowing etc. There is no way to suspend them.

Comment 8

[Sam Foster [:sfoster] (he/him)]

This now works as expected: 
If you pull to refresh (or click anything to results in a request to the server) and it gets a bad (0 or > 500) response, a message is sent to native which causes the 'no connection, try again' modal to show. *no* polling or background checking takes place, the user needs to hit try again; if a request to /ping.html is successful (> 0 and < 500) a message is sent to native to pull down the modal. 

Note that we can't replay the original request that failed. So if they were doing pull-to-refresh, when the modal comes down they'll have an empty page and will need to pull to refresh again to repopulate the page. 

Note also that we don't currently monitor network status on the device. We could and could use the same mechanism to prompt the front-end to re-try if we detect a change.

Comment 9

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Hmm not sure if this is correct but I think the detection we use is somehow too 'sensitive'. I'm getting the Network Needed page even though I am fully online. When I click it away I see the main screen already successfully loaded.

Comment 10

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

I think this happens because /lattice/stats returns a 500. I don't think this network availability check should trigger in case of server errors. It should only detect requests that fail to execute completely?

Filed https://bugzilla.mozilla.org/show_bug.cgi?id=766444 for the lattice issue.

Comment 11

[Sam Foster [:sfoster] (he/him)]

I changed it to just treat the following as network/connection errors: 

0: This happens when the request could not be completed
502: Bad Gateway
503: Service Unavailable

I've seen 502 and 503 responses from proxies when the server couldnt be contacted. These aren't (or shouldn't be) server generated errors so I think they should be OK? 
Perhaps we need to treat 504 Gateway Timeout the same way. 

See: https://bitbucket.org/mozillapancake/pancake/changeset/54ea884d6a80

Comment 12

[Sam Foster [:sfoster] (he/him)]

We now send the response status code along with the connected: true/false property in the connection:change message. So we could look at that to determine which message to show if we wanted.

Comment 13

[Sam Foster [:sfoster] (he/him)]

I've done all I can do with this in the FE. The message now has a status code which will be 0 for no response / incomplete request, and 500+ for error responses (see above)

Comment 14

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

I think at this point I don't want to introduce any more logic to the iOS app. The above change fixes the problem that server result in the app going offline so i think that is all we want at this point. The 502 and 503 responses are thrown by upstream proxies so those should trigger the app going offline.

Lets open a new bug on how to deal with server errors. I think we should have a different strategy there. Like for example retrying the request or showing a more friendly dialog in the app?