867311 - Error page using Facebook and network drops

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: Preinstalled B2G Apps, defect)

Description

[Simon Callan, Telefonica]

Attachment: photo.jpeg

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31

Steps to reproduce:

Use facebook and view pages. Drop the network.


Actual results:

You get a browser error "Facebook is offline mode"


Expected results:

It should show a elegant/neater OS message e.g "App can't work offline"

Comment 1

[Simon Callan, Telefonica]

See attached image

Comment 2

[Jason Smith [:jsmith]]

Facebook technically makes use in-app offline error messages while using the app. Not during startup, however, because an internet connection is required during startup of the app.

This has no impact on the compatibility story and feels minor - there's zero user impact here. I think this is a WONTFIX for outreach, but I'll await opinions.

Comment 3

[Simon Callan, Telefonica]

Agree it's fairly minor, but it's been picked up a number of times by execs who think this supports the views that these are just mobile web sites running in a browser, without elegant error messages or caching when things go wrong

Comment 4

[Jason Smith [:jsmith]]

(In reply to Simon Callan, Telefonica from comment #3)
> Agree it's fairly minor, but it's been picked up a number of times by execs
> who think this supports the views that these are just mobile web sites
> running in a browser, without elegant error messages or caching when things
> go wrong

The only way we'll really provide a pure friendly offline error message designed by the app itself is to require any hosted app being preinstalled on device to have an appcache_path defined up front to provide an offline error page. Otherwise, we'll hit this problem with every hosted app.

In fact, doing an initial code inspection I did recently with Yuren revealed that pretty much every hosted app except notes wasn't making use of an appcache_path. So this same style of bug here I'd expect to happen with every single hosted app preinstall except notes.

Comment 5

[Andrew Williamson [:eviljeff]]

(In reply to Simon Callan, Telefonica from comment #0)
> Created attachment 743759 [details]
> photo.jpeg

This isn't the Facebook app - its the facebook website loaded in the browser.

Comment 6

[Jason Smith [:jsmith]]

(In reply to Andrew Williamson [:eviljeff] from comment #5)
> (In reply to Simon Callan, Telefonica from comment #0)
> > Created attachment 743759 [details]
> > photo.jpeg
> 
> This isn't the Facebook app - its the facebook website loaded in the browser.

Shouldn't matter actually - the facebook app is basically the mobile site with the webapp manifest data. So this same bug will happen with the facebook app.

Comment 7

[Andrew Williamson [:eviljeff]]

(In reply to Jason Smith [:jsmith] from comment #6)
> (In reply to Andrew Williamson [:eviljeff] from comment #5)
> > (In reply to Simon Callan, Telefonica from comment #0)
> > > Created attachment 743759 [details]
> > > photo.jpeg
> > 
> > This isn't the Facebook app - its the facebook website loaded in the browser.
> 
> Shouldn't matter actually - the facebook app is basically the mobile site
> with the webapp manifest data. So this same bug will happen with the
> facebook app.

We've tested it and the Facebook app doesn't exhibit this behaviour. If the reporter can confirm this is happening in the app we'll re-open.  Otherwise this needs moving to the browser component as a general issue.

Comment 8

[Jason Smith [:jsmith]]

(In reply to Andrew Williamson [:eviljeff] from comment #7)
> (In reply to Jason Smith [:jsmith] from comment #6)
> > (In reply to Andrew Williamson [:eviljeff] from comment #5)
> > > (In reply to Simon Callan, Telefonica from comment #0)
> > > > Created attachment 743759 [details]
> > > > photo.jpeg
> > > 
> > > This isn't the Facebook app - its the facebook website loaded in the browser.
> > 
> > Shouldn't matter actually - the facebook app is basically the mobile site
> > with the webapp manifest data. So this same bug will happen with the
> > facebook app.
> 
> We've tested it and the Facebook app doesn't exhibit this behaviour. If the
> reporter can confirm this is happening in the app we'll re-open.  Otherwise
> this needs moving to the browser component as a general issue.

I strongly doubt that's correct. Facebook doesn't preload an appcache as part of the app install, so you can definitely hit the generic no network error if you launch the app without a connection.

Comment 9

[Andrew Williamson [:eviljeff]]

(In reply to Jason Smith [:jsmith] from comment #8)
> (In reply to Andrew Williamson [:eviljeff] from comment #7)
> > (In reply to Jason Smith [:jsmith] from comment #6)
> > > (In reply to Andrew Williamson [:eviljeff] from comment #5)
> > > > (In reply to Simon Callan, Telefonica from comment #0)
> > > > > Created attachment 743759 [details]
> > > > > photo.jpeg
> > > > 
> > > > This isn't the Facebook app - its the facebook website loaded in the browser.
> > > 
> > > Shouldn't matter actually - the facebook app is basically the mobile site
> > > with the webapp manifest data. So this same bug will happen with the
> > > facebook app.
> > 
> > We've tested it and the Facebook app doesn't exhibit this behaviour. If the
> > reporter can confirm this is happening in the app we'll re-open.  Otherwise
> > this needs moving to the browser component as a general issue.
> 
> I strongly doubt that's correct. Facebook doesn't preload an appcache as
> part of the app install, so you can definitely hit the generic no network
> error if you launch the app without a connection.

If you test the app you'll see that a different screen is shown if an app is launched without a connection - one that fully explains in user friendly language that the app needs a network connection to function.

Comment 10

[Jason Smith [:jsmith]]

(In reply to Andrew Williamson [:eviljeff] from comment #9)
> (In reply to Jason Smith [:jsmith] from comment #8)
> > (In reply to Andrew Williamson [:eviljeff] from comment #7)
> > > (In reply to Jason Smith [:jsmith] from comment #6)
> > > > (In reply to Andrew Williamson [:eviljeff] from comment #5)
> > > > > (In reply to Simon Callan, Telefonica from comment #0)
> > > > > > Created attachment 743759 [details]
> > > > > > photo.jpeg
> > > > > 
> > > > > This isn't the Facebook app - its the facebook website loaded in the browser.
> > > > 
> > > > Shouldn't matter actually - the facebook app is basically the mobile site
> > > > with the webapp manifest data. So this same bug will happen with the
> > > > facebook app.
> > > 
> > > We've tested it and the Facebook app doesn't exhibit this behaviour. If the
> > > reporter can confirm this is happening in the app we'll re-open.  Otherwise
> > > this needs moving to the browser component as a general issue.
> > 
> > I strongly doubt that's correct. Facebook doesn't preload an appcache as
> > part of the app install, so you can definitely hit the generic no network
> > error if you launch the app without a connection.
> 
> If you test the app you'll see that a different screen is shown if an app is
> launched without a connection - one that fully explains in user friendly
> language that the app needs a network connection to function.

That's true *after* the user has logged into a facebook account, but not if they are not logged in.

Comment 11

[Andrew Williamson [:eviljeff]]

(In reply to Jason Smith [:jsmith] from comment #10)
> (In reply to Andrew Williamson [:eviljeff] from comment #9)
> > (In reply to Jason Smith [:jsmith] from comment #8)
> > > (In reply to Andrew Williamson [:eviljeff] from comment #7)
> > > > (In reply to Jason Smith [:jsmith] from comment #6)
> > > > > (In reply to Andrew Williamson [:eviljeff] from comment #5)
> > > > > > (In reply to Simon Callan, Telefonica from comment #0)
> > > > > > > Created attachment 743759 [details]
> > > > > > > photo.jpeg
> > > > > > 
> > > > > > This isn't the Facebook app - its the facebook website loaded in the browser.
> > > > > 
> > > > > Shouldn't matter actually - the facebook app is basically the mobile site
> > > > > with the webapp manifest data. So this same bug will happen with the
> > > > > facebook app.
> > > > 
> > > > We've tested it and the Facebook app doesn't exhibit this behaviour. If the
> > > > reporter can confirm this is happening in the app we'll re-open.  Otherwise
> > > > this needs moving to the browser component as a general issue.
> > > 
> > > I strongly doubt that's correct. Facebook doesn't preload an appcache as
> > > part of the app install, so you can definitely hit the generic no network
> > > error if you launch the app without a connection.
> > 
> > If you test the app you'll see that a different screen is shown if an app is
> > launched without a connection - one that fully explains in user friendly
> > language that the app needs a network connection to function.
> 
> That's true *after* the user has logged into a facebook account, but not if
> they are not logged in.

Please provide a screenshot of this happening.  We've tested and found everything as expected.

Comment 12

[Jason Smith [:jsmith]]

Attachment: Facebook No Connection

Comment 13

[Jason Smith [:jsmith]]

(In reply to Andrew Williamson [:eviljeff] from comment #11)
> 
> Please provide a screenshot of this happening.  We've tested and found
> everything as expected.

Then that's incorrect. I've confirmed exactly what I stated above.

Comment 14

[Andrew Williamson [:eviljeff]]

(In reply to Jason Smith [:jsmith] from comment #13)
> (In reply to Andrew Williamson [:eviljeff] from comment #11)
> > 
> > Please provide a screenshot of this happening.  We've tested and found
> > everything as expected.
> 
> Then that's incorrect. I've confirmed exactly what I stated above.

That screenshot is what we expected (and saw) and isn't the same as the one in comment #0.

Karen: has this screen been signed off as generally acceptable for offline?

Comment 15

[Jason Smith [:jsmith]]

(In reply to Andrew Williamson [:eviljeff] from comment #14)
> (In reply to Jason Smith [:jsmith] from comment #13)
> > (In reply to Andrew Williamson [:eviljeff] from comment #11)
> > > 
> > > Please provide a screenshot of this happening.  We've tested and found
> > > everything as expected.
> > 
> > Then that's incorrect. I've confirmed exactly what I stated above.
> 
> That screenshot is what we expected (and saw) and isn't the same as the one
> in comment #0.
> 
> Karen: has this screen been signed off as generally acceptable for offline?

Last time I checked, that decision is up to the TEF BD, who happens to be filer of the bug here. So no, that's not right.

Comment 16

[Simon Callan, Telefonica]

The issue is you get a browser error about Offline Mode. So, with data turned off

1. Load Facebook - you get log in page
2. Click Log In - you get friendly "Facebook requires an internet connection...." page
3. Click Try again - you get an unfriendly "Firefox is currently in offline mode..." - not something that is friendly - and all you can do is to back to the home screen and restart the app

Comment 17

[Jason Smith [:jsmith]]

Per discussion above after clarification I'll close this per Andrew's resolution given that the screenshot originally was during the browser. I'm going to followup though on our policy on first run offline experience, since that appears to be an area of contention.

Comment 18

[Simon Callan, Telefonica]

Sorry - I may have confused this. The issue is that the error appears inside the FB APP - but it looks like a browser error. i.e. to the user it looks like this is just a browser running the mobile web site, opposed to an app

Comment 19

[Karen Ward [:kward]]

This needs to be prioritized for V1.1.  Is there a milestone flag I should use?

Comment 20

[Jason Smith [:jsmith]]

(In reply to [e-mail] from comment #19)
> This needs to be prioritized for V1.1.  Is there a milestone flag I should
> use?

Tech evangelism doesn't have the b2g milestones that are used for certification, nor does it use the blocking flags B2G uses. The milestone you would use if it was available would be whatever QE milestone makes sense from LG's perspective.

See https://wiki.mozilla.org/Release_Management/B2G_Deadlines#1.1.

As for getting those blocking/milestone flags on TE, that would need to be a larger discussion. The discussions we had on this previously in various release cycles stated that we were against blocking on anything that was out of our control, which was why blocking flags are not included on TE bugs.

Comment 21

[Lisa Brewster [:adora]]

Attachment: Fixed as of Aug-21

This got fixed somewhere along the way.