1109649 - Display page loading errors

Status: RESOLVED DUPLICATE of bug 1125835

(Firefox for iOS :: Browser, defect)

Description

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

Currently we just get a delegate callback when the page failed to load. We need to find out how much usable information is in the NSError and if we can present that nicely in-content.

There are two kinds of errors: things that happen while loading a page. Like bad SSL certs or a connection refused. And there are also errors that happen before loading a page. Like 'bad url'.

Comment 1

[Chuong Vu]

I think the two main delegate callback methods that we should start off with are:

1. webView:didFailNavigation:withError:
2. webView:didFailProvisionalNavigation:withError:

The latter I was able to use when we enter an invalid url and a request time out. Does anyone have advice on how we can reproduce the other events such as bad SSL, connection refused etc...? I am having trouble finding sample websites where we can reproduce the other situations.

Also how should we be displaying the errors? Should we follow how Safari does it? (Printing the error message in the center)

Comment 2

[Richard Newman [:rnewman]]

(In reply to Chuong Vu from comment #1)

> The latter I was able to use when we enter an invalid url and a request time
> out. Does anyone have advice on how we can reproduce the other events such
> as bad SSL, connection refused etc...?

Ideally we'd like the test suite to not require access to live sites, so this question should really be "how do we write a test for this?".

I'm not definite on the answer to that, but presumably we can host a server in test code and have it simulate whatever error conditions we wish, just as we do for JS unit tests in mainline Firefox:

https://developer.mozilla.org/en-US/docs/Httpd.js/HTTP_server_for_unit_tests


StackOverflow turns up some good options:

http://stackoverflow.com/questions/10807480/stubbing-mocking-up-webservices-for-an-ios-app


Manual testing should be as simple as running something like:

https://github.com/nodeapps/http-server

-- you can manually create a PEM cert which is expired or missing a root, launch the server, browse to it from the simulator, and verify that you get an appropriate SSL-related callback.


You'll soon see why automating this is worthwhile, I think!


> Also how should we be displaying the errors? Should we follow how Safari
> does it? (Printing the error message in the center)

I think that's a reasonable starting point, but I'd probably point to desktop/Android Firefox for inspiration over Safari.

The important thing is that we can iterate once we have something working; UX will get involved and start doing what they do best!

Comment 3

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

(In reply to Chuong Vu from comment #1)

...

> Also how should we be displaying the errors? Should we follow how Safari
> does it? (Printing the error message in the center)

Chuong would you mind focussing on displaying the errors? I think if you just show them like Safari does, centered with a bigger font size and maybe within a simple box, that would be a great start. Right now we show nothing so having some feedback on errors would be good to have.

Don't worry too much about the style of things or the wording of error presentation.

I am curious though what kind of information we have about errors. Is there always a localized error message available? What other info does the NSError contain that we could display?

We would be very happy with a simple first iteration.

Comment 4

[Chuong Vu]

Stefan,

That sounds like a great idea. Unfortunately I won't be able to jump onto this for at least another week. So if anyone wants to jump on this, please free feel to do so.

Comment 5

[Aaron]

I want to take this.

Comment 6

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

Looping in Darrin.

Darrin, do you think we can give luanjiwi some ideas of how common error pages would look on iOS? Or is it too early for that?

Otherwise I suggest that luanjiwi just follow the hints in comment #3 and not worry too much about the style of error pages.

Comment 7

[Aaron]

I am aaron in irc.
I will display errors in my way for now, once you give me some advices, then I will follow it.

Comment 8

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Stefan Arentz [:st3fan] from comment #6)

> Otherwise I suggest that luanjiwi just follow the hints in comment #3 and
> not worry too much about the style of error pages.

That is a good plan. Get something started and then we can iterate.

Comment 9

[Aaron]

Should I also build the test server to test all kind of errors, or just make it works, then you can lead me the way.

Comment 10

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

(In reply to Aaron from comment #9)
> Should I also build the test server to test all kind of errors, or just make
> it works, then you can lead me the way.

Aaron I am working on integrating a Python web server in the unit test framework. So we will be able to use that for tests. In the meantime I would suggest to test a bit manually for some common scenarios like:

* getting a timeout from on http://www.mozilla.org:1234
* getting a DNS error on http://thisdoesnotexist.nl
* getting an invalid ssl response on https://www.mozilla.org:80/ (note the port)
* getting an invalid response on http://www.mozilla.org:443/ (note the port)

Comment 11

[Aaron]

(In reply to Stefan Arentz [:st3fan] from comment #10)
> (In reply to Aaron from comment #9)
> > Should I also build the test server to test all kind of errors, or just make
> > it works, then you can lead me the way.
> 
> Aaron I am working on integrating a Python web server in the unit test
> framework. 

Wow, Awesome, I can write a little Python, I can help if you need any.

>So we will be able to use that for tests. In the meantime I would
> suggest to test a bit manually for some common scenarios like:
> 
> * getting a timeout from on http://www.mozilla.org:1234
> * getting a DNS error on http://thisdoesnotexist.nl
> * getting an invalid ssl response on https://www.mozilla.org:80/ (note the
> port)
> * getting an invalid response on http://www.mozilla.org:443/ (note the port)

Working on it, I will make it the same as Safari.

Comment 12

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

Keep an eye on bug 1123430 which has a patch to include the GCDWebServer. (Python turned out to be very diffiult to include). I'll be happy to help write a bunch of unit tests for this.

Comment 13

[Aaron]

Had got the patch, I will write some unit tests for this.
Python is more easy to built and configure a server, I think, pity.

BTW
There is already a web server on Mac OS X, is it possible that we could use it for test?

Comment 14

[Aaron]

Need some help here.

I use NSError.code provided by error delegates of WKNavigationDelegate to generate the error message.
I searched Apple's document found NSError.code is under kCFErrorDomainCFNetwork domain.

Is it right? I have pulled a request, thinking I can get some advices, but sill not. 
Not knowing if it is correct, I also can't write unit tests for it. 

I want to take another bug while this one is unsolved, is that ok?

Comment 15

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

Attachment: Pull Request

Comment 16

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

Aaron, I'll take a detailed look in a bit. I think you are on the right track and I hope to merge this soon. Maybe after a few minor changes.

Comment 17

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

I am going to merge this with the comment that this is not perfect but it will give us a much better idea of what kind of usable information WebKit errors contain. I am also going to file a followup but to turn these error messages into a more final design.

Comment 18

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

I filed 1125835 as a followup bug.

Comment 19

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

Aaron, I'm sorry we reverted your patch. The team thought it would be good to rethink how we want to handle this bug.

Comment 20

[Aaron]

It's OK :]
I will find myself a new bug to work on, any suggestion?

Comment 21

[Brian Nicholson (:bnicholson)]

I'll take a look at this. We'll probably need some kind of about: hackery to put the error page in the history stack.

Comment 22

[Brian Nicholson (:bnicholson)]

I assume we'll want something for v1.