Closed Bug 729898 Opened 8 years ago Closed 7 years ago

Make better error indicator pages

Categories

(Firefox OS Graveyard :: General, defect, P4)

ARM
Gonk (Firefox OS)
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: cjones, Assigned: fabrice)

References

Details

(Keywords: polish, Whiteboard: visual design)

Attachments

(3 files)

Given conditions at the demo next week, it's not entirely un-possible that we'll hit a network error when trying to load content from the internet.  When that happens in b2g, we end up using what appears to be some toolkit-fallback error pages, which aren't optimized for touch or small screens and kind of look like ass.

We should polish these up, but this is lower priority than all other UX stuff at this point.
Chris, can you send examples of current error screens? I haven't seen them yet.
Fennec has mobile-friendly versions of these pages. We should just reuse them.
Attached patch patchSplinter Review
Assignee: nobody → fabrice
Attachment #600057 - Flags: review?(jones.chris.g)
Attached image screenshot: before
Attached image screenshot: after
Comment on attachment 600057 [details] [diff] [review]
patch

OK!  Step in the right direction.
Attachment #600057 - Flags: review?(jones.chris.g) → review+
Fabrice, how much of this bug did your patch cover? Is this bug fixed?
What's the latest status on this bug?
This bug covers the usual network error pages (eg Server not found, unregistered protocol).

It does not provide the error pages related to certificate errors.

Also, I'm not sure why I did not close it when landing on mozilla-central...
A Pivotal Tracker story has been created for this Bug: http://www.pivotaltracker.com/story/show/36335885
ahem, excuse the comment spam.
We're discussing visual polish to Gecko's default error pages here:

https://github.com/mozilla-b2g/gaia/issues/5067

It looks like the styles we want to edit live at: b2g/chrome/content ?

What's the process for driving a tweak? Provide the new CSS and have one of the devs on this thread implement?
(In reply to Josh Carpenter [:jcarpenter] from comment #13)
> We're discussing visual polish to Gecko's default error pages here:
> 
> https://github.com/mozilla-b2g/gaia/issues/5067
> 
> It looks like the styles we want to edit live at: b2g/chrome/content ?

That's correct.

> What's the process for driving a tweak? Provide the new CSS and have one of
> the devs on this thread implement?

Yes, but if you have the css you can probably even provide a patch :P
Here are the error designs: https://www.dropbox.com/sh/57puqw6dr0dlus3/L6YX6IRTb3

A few things to note:

1. We would want to have 2 different types of "404" errors. One for the browser and the other for apps. The one of the apps would be styled in the way the rest of the system dialogs are styled. The browser 404 would be in browser. This is to create the illusion that the apps are not webpages.

2.@jcarpenter The wording may need to be revised / shorten for mobile. Currently using what we use in Firefox desktop.

3.@fabricedesre it was mentioned in one of the bugzilla bugs that the assets for the current design can be found in b2g/chrome/content
I can't seem to see this folder, is B2G the same folder that contains the GAIA folder?
Keywords: polish
Whiteboard: polish, visual design
(In reply to Patryk Adamczyk [:patryk] UX from comment #15)
> Here are the error designs:
> https://www.dropbox.com/sh/57puqw6dr0dlus3/L6YX6IRTb3
> 
> A few things to note:
> 
> 1. We would want to have 2 different types of "404" errors. One for the
> browser and the other for apps. The one of the apps would be styled in the
> way the rest of the system dialogs are styled. The browser 404 would be in
> browser. This is to create the illusion that the apps are not webpages.

That's clearly at risk for v1.

> 2.@jcarpenter The wording may need to be revised / shorten for mobile.
> Currently using what we use in Firefox desktop.
> 
> 3.@fabricedesre it was mentioned in one of the bugzilla bugs that the assets
> for the current design can be found in b2g/chrome/content
> I can't seem to see this folder, is B2G the same folder that contains the
> GAIA folder?

No, it's not part of gaia, but in the platform, at https://mxr.mozilla.org/mozilla-central/source/b2g/chrome/content/ (see netError.xhtml and netError.css)
> Here are the error designs: https://www.dropbox.com/sh/57puqw6dr0dlus3/L6YX6IRTb3

Looks great!

> 1. We would want to have 2 different types of "404" errors. One for the browser and the 
> other for apps. The one of the apps would be styled in the way the rest of the system 
> dialogs are styled. The browser 404 would be in browser. This is to create the illusion that 
> the apps are not webpages.

We're tackling the same issue today, here: https://bugzilla.mozilla.org/show_bug.cgi?id=798722#c8

Here's what Ben has said:

> The Gaia window manager doesn't display gecko error messages for apps & bookmarks like the
> browser app does, it instead catches an "error" event and acts accordingly.
> 
> The API which provides these events currently only sends two types of error, "fatal" and 
> "other". When it receives a "fatal" error the app closes and the transitive message is 
> displayed saying that the app experienced a problem and closed. When it receives an "other" 
> error it currently displays a slightly scary looking (and not properly designed) "This app
> is having problems; This app is not loading properly" screen with a big sad face.

So my understanding is you can style these as needed for Browser, and we'll come up with a different treatment for other apps, in bug 798722.

Fabrice, correct me if I'm wrong? Or if the premise of 798722 is wrong?
It looks like you are correct. I didn't know that we had special events for errors in OOP apps. So if this bug focus on the errors in the browser tabs, we can do something.
I exported the assets here: https://www.dropbox.com/sh/orycxuowe2lsewp/3mL7blxZVN having some trouble previewing the CSS, the xhtml keeps on spitting out errors when I launch in the browser, so I can't really test it :S If I create a detailed spec, can you try to implemented?
Given that in the case of the "untrusted" and "known attack site" errors I think we currently just get a generic "invalid URL" error, I'm not sure whether it's actually possible to distinguish errors enough to apply the designs specified for those two.

Fabrice, is it just that those error pages are missing for B2G or is there actually currently no way to know when to display them? Also, could we make the "proceed" button work, allowing the user to proceed anyway?
Do we have a design for the "working offline" page as part of this work? Bug 805564 points out that the text doesn't make sense for B2G.
Priority: -- → P4
Whiteboard: polish, visual design → visual design
Fabrice, what's the status of this bug?  Is there anything you need to help implement it?
Flags: needinfo?(fabrice)
I'm closing this bug since the relevant patch landed. Please open follow up if needed.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(fabrice)
Resolution: --- → FIXED
(In reply to Fabrice Desré [:fabrice] from comment #23)
> I'm closing this bug since the relevant patch landed. Please open follow up
> if needed.

ok thanks Fabrice!
You need to log in before you can comment on or make changes to this bug.