Closed Bug 1109649 Opened 5 years ago Closed 5 years ago

Display page loading errors

Categories

(Firefox for iOS :: Browser, defect)

All
iOS 7
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 1125835
Tracking Status
fennec + ---

People

(Reporter: st3fan, Assigned: bnicholson)

References

Details

Attachments

(1 file)

46 bytes, text/x-github-pull-request
Details | Review
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'.
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)
Flags: needinfo?(sarentz)
(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!
Assignee: nobody → chuongmozilla
OS: Mac OS X → iOS 7
Hardware: x86 → All
Assignee: chuongmozilla → nobody
(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.
Flags: needinfo?(sarentz) → needinfo?(chuongmozilla)
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.
Flags: needinfo?(chuongmozilla)
I want to take this.
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.
Flags: needinfo?(dhenein)
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.
(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.
Flags: needinfo?(dhenein)
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.
(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)
(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.
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.
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?
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?
Attached file Pull Request
Attachment #8552654 - Flags: review?(sarentz)
Assignee: nobody → luanjiwu
Mentor: sarentz
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.
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.
I filed 1125835 as a followup bug.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Attachment #8552654 - Flags: review?(sarentz)
Aaron, I'm sorry we reverted your patch. The team thought it would be good to rethink how we want to handle this bug.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
It's OK :]
I will find myself a new bug to work on, any suggestion?
Blocks: iosv1
Blocks: iosbrowsingui
No longer blocks: iosv1
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.
Assignee: luanjiwu → bnicholson
Mentor: sarentz
I assume we'll want something for v1.
tracking-fennec: --- → ?
tracking-fennec: ? → +
Blocks: 1125835
Status: REOPENED → RESOLVED
Closed: 5 years ago5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1125835
You need to log in before you can comment on or make changes to this bug.