1125835 - Design a good error page

Status: RESOLVED FIXED

(Firefox for iOS :: Browser, defect)

Description

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

With bug 1109649 we are displaying all the 'raw' data from a webkit error.

For example, this happens when you connect to an invalid HTTPS URL:

code: -1200
domain: NSURLErrorDomain
userInfo: Optional([_WKRecoveryAttempterErrorKey: , NSErrorFailingURLStringKey: https://www.mozilla.org:80/, NSErrorFailingURLKey: https://www.mozilla.org:80/, NSLocalizedRecoverySuggestion: Would you like to connect to the server anyway?, NSLocalizedDescription: An SSL error has occurred and a secure connection to the server cannot be made.])
localizedDescription: An SSL error has occurred and a secure connection to the server cannot be made.
localizedRecoveryOptions: nil
localizedRecoverySuggestion: Optional("Would you like to connect to the server anyway?")
localizedFailureReason: nil
recoveryAttempter: nil
helpAnchor: nil

There is a lot of info there. We need to decide what to show and how to present that to the user.

Comment 1

[Aaron]

I am going to merge the tests of GCDWebServer to WebServerTests.swift, Should I working on it?

Comment 2

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

(In reply to Aaron from comment #1)
> I am going to merge the tests of GCDWebServer to WebServerTests.swift,
> Should I working on it?

No please wait with that.

Note that this bug is more about designing a HTML template for displaying errors.

Comment 3

[Nick Alexander :nalexander [he/him]]

darrin: tecgirl: this needs UX love.

Comment 4

[Robin Andersen [:tecgirl]]

(In reply to Nick Alexander :nalexander from comment #3)
> darrin: tecgirl: this needs UX love.

:nalexander / :wesj Do we have a list that outlines all of the error cases?

Comment 5

[Wesley Johnston (:wesj)]

You might look at the strings for desktop/Android to see what kind of things can happen. Not sure how many of these are exposed to us on iOS right now:

http://mxr.mozilla.org/mozilla-central/source/browser/locales/en-US/chrome/overrides/netError.dtd#33

Comment 6

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

The strings are provided by iOS. Not by us. I think there are generally two cases:

errors that we can recover from. (the NSError will have a recovery message included like 'Try Again') - those would also need some button or link in the page.

errors that are fatal.

I also am pretty sure that every error has a short (title) string and a longer description.

We should confirm all of the above by printing some errors first so that :tecgirl can see what they would look like.

Comment 7

[Robin Andersen [:tecgirl]]

:st3fan, :nalexander, was there any movement on this error list? I have an idea of what we can do but want to make sure I'm aware of all the circumstances.

Comment 8

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

In general we have two things that we can display:

 * The URL of the site that we are trying to load. Either the full one or we can pick just the hostname from it. ("There was a problem loading www.apple.com")
 * The NSError that WebKit gives us.

The first is always present. The latter too, but may have different bits of information.

In general the error contains an iOS error code (a number) and the following localized texts:

 * localizedDescription
 * localizedFailureReason
 * localizedRecoverySuggestion
 * localizedRecoveryOptions

The first, localizedDescription, is always present. This is a short string like for example:

 "The request timed out."
 "Not allowed to use restricted network port"
 "An SSL error has occurred and a secure connection to the server cannot be made."

The rest is optional. Sometimes the localizedRecoverySuggestion is available. For example when connecting to a bad secure server:

  description: "An SSL error has occurred and a secure connection to the server cannot be made."
  recoverySuggestion: "Would you like to connect to the server anyway?"

However ... there is no public API that we can use to actually recover. So I think we cannot use this just yet.


Summarizing, I think unfortunately our error pages can only have three things:

 * The URL or Hostname of the page we were trying to load (note that the full URL will also be in the location bar)
 * The localizedDescription
 * The iOS Error Code (which may be useful - sometimes people can google for it to get more detailed info)




Technical details:

When an error occurs, we get an NSError that has the usual localized* descriptions. There is also a dictionary in the userInfo field of the nSError that has one interesting item:

 _WKRecoveryAttempterErrorKey=<WKReloadFrameErrorRecoveryAttempter: 0x7ff0b1b50830>

Looking at the WebKit source code, this WKReloadFrameErrorRecoveryAttempter instance has a attemptRecovery method. Which is not documented but I assume this continues or retries the operation.

We will have to file a bug with Apple to get this exposed publicly.

Comment 9

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

Interesting, I just caused a DNS lookup failure, and I am getting the following back:

localizedDescription: The operation couldn’t be completed. (NSURLErrorDomain error -999.)
localizedFailureReason: nil
localizedRecoverySuggestion: nil
localizedRecoveryOptions: nil

This is a pretty horrible error message.

Safari shows comething different: "Safari cannot open the page because the server cannot be found."

What I am going to suggest is that we default to the NSError.localizedDescription, except for a number of cases where we know we can supply a better error message (based on the NSURLErrorDomain).

So we need to keep a list of error codes vs error messages for those that we want to override.

Comment 11

[Robin Andersen [:tecgirl]]

Attachment: errorTemplate.pdf

Error Template specs (pdf)

Comment 12

[Robin Andersen [:tecgirl]]

Attachment: errorTape.zip

striped tape assets

Comment 13

[Robin Andersen [:tecgirl]]

Attachment: errorTemplates.zip

template examples

Comment 14

[Wesley Johnston (:wesj)]

Attachment: PR https://github.com/mozilla/firefox-ios/pull/466

This may need some more iteration with UX as well.

Comment 15

[Wesley Johnston (:wesj)]

Also, tablets are looking awful. Looking at that now...

Comment 16

[Wesley Johnston (:wesj)]

Cleaned up tablets a bit.

Also need to keep these out of storage.
Also need to tweak on the 4s a bit I think (reduce some top padding).

Comment 17

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

I really like this approach, I hope we can use this.

I did find a serious issue that we probably need to resolve before landing
 this. You can reproduce as follows:

1) Go to http://people.mozilla.org/~sarentz/t/errors.html
2) Tap on the third link (SSL Connect to bad port 80)

You may have to tap the link twice. (That could be a hint why this is
happening)

What happens next is that the browser at *very* rapid pace repeatedly makes
HTTP requests. Even if you navigate away from the page, it keeps doing this.
Hitting the stop button makes not difference.

Comment 18

[Wesley Johnston (:wesj)]

Without looking I'm guessing that the error page is throwing an error :) which starts an infinite loop. I'm going to look at fixing that, but also a mitigation... (i.e. if we're showing an error page for an error page, show something generic?)

Comment 19

[Wesley Johnston (:wesj)]

Hmm.. I was sorta right. The original click on the link takes a long time to error out. I'm not sure why.

Hitting reload on it while its in progress seems to trigger two failures in provisional navigation. One of those is because cancelling a load (i.e. hitting stop) fires the error handler. I caught those and made them not show error pages anymore.

The reload request also fires some new load events, which (this time) fail really quickly then and shows the correct error. I think trying to show two errors at once for the same page was causing an infinite error page loop before. I added an exit out if we try to show an error page for an error page.

Comment 20

[Wesley Johnston (:wesj)]

Also, git talked me into running 'git pull' which tried to merge with your old branch. I cleaned things back up here, but there's some extra deletions going on to do it.

Comment 21

[Robin Andersen [:tecgirl]]

(In reply to Wesley Johnston (:wesj) from comment #14)
> Created attachment 8605993 [details] [review]
> PR https://github.com/mozilla/firefox-ios/pull/466
> 
> This may need some more iteration with UX as well.

Looks good. One nit: when rotating device, the stripes don't automatically expand the width. If I tap refresh, they will.

Comment 22

[Robin Andersen [:tecgirl]]

(In reply to Stefan Arentz [:st3fan] from comment #17)
> I really like this approach, I hope we can use this.
> 
> I did find a serious issue that we probably need to resolve before landing
>  this. You can reproduce as follows:
> 
> 1) Go to http://people.mozilla.org/~sarentz/t/errors.html
> 2) Tap on the third link (SSL Connect to bad port 80)
> 
> You may have to tap the link twice. (That could be a hint why this is
> happening)
> 
> What happens next is that the browser at *very* rapid pace repeatedly makes
> HTTP requests. Even if you navigate away from the page, it keeps doing this.
> Hitting the stop button makes not difference.

Shouldn't the error template render for the last two errors? It did not for the last two tests (HTTP bad port and Random Failure). 

Also, triggering the loop was amusing. My console blew up!

Comment 23

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

Wes, can you needinfo me when I can look at this again?

Comment 24

[Wesley Johnston (:wesj)]

Comment on attachment 8605993 [details] [review]
PR https://github.com/mozilla/firefox-ios/pull/466

Ready for review again. I think the header errors you saw were fixed by our other recent fix for fixed position headers. The redirect error from the people page actually isn't in good sentence case. Let get this in and fix that in follow ups.

Comment 25

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

Comment on attachment 8605993 [details] [review]
PR https://github.com/mozilla/firefox-ios/pull/466

Lets land this and see how it is received by our testers.