292646 - Use Error Pages Instead of Drop-down Sheet

Status: VERIFIED FIXED

(Camino Graveyard :: General, enhancement)

Description

[Samuel Sidler (old account; do not CC)]

Instead of using the drop-down sheet we use (the requested page could not be
found/timeout/etc), let's use actual pages and no place the drop down error.

This allows users to continue browsing without having to click "okay" when a
page times-out. The error page would give a simple explanation as to what
happened and would be distinguishable from most pages.

For the record, the new Safari RSS does this.

Comment 1

[Mike Pinkerton (not reading bugmail)]

i'm sure this is a dupe.

Comment 2

[Jasper]

Yeah we had/havea bug exactly like this but I can't find it anywhere.

Doing this is just a matter of setting a pref and perhaps removing some code and
a nib file :)

 pref("browser.xul.error_pages.enabled", true);

Some guys are now bussy redesigning the eror page (bug 280190) so we should look
very nice if we enabled this. I'd vote for it.

Comment 3

[Samuel Sidler (old account; do not CC)]

I searched and couldn't find it, but yes, please dupe it if you do.

Comment 4

[Mike Pinkerton (not reading bugmail)]

we should be doing this for 09.

Comment 5

[Mike Pinkerton (not reading bugmail)]

i set the pref so that we can get testing on it. i'll remove the nib and error
handling code when we are sure that we want to keep this on.

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

The two bugs this bug now blocks can be marked FIXED when we're certain that
we're keeping the error pages and not reverting to sheets.

Comment 7

[Chris Casciano]

whats the impetus for removing the pref?

Comment 8

[Marcello Testi]

Did you make sure the new pages are localizable?

Comment 9

[Paul Borokhov (lensovet)]

(In reply to comment #5)
> i set the pref so that we can get testing on it. i'll remove the nib and error
> handling code when we are sure that we want to keep this on.

does this mean that the current (new) behavior will be the ONLY option? if so,
i'm not too excited about it. just like with the new bookmarks and history
handling, there are times when you don't want the current page cleared and
reloaded if you get an error (and have to use the back button).

Comment 10

[Ulrik Sverdrup]

can we customize the error pages for camino?

As of now, they are neither clear nor good-looking. It would be great if the
alert could be centered and use the Camino icon (yes, I know that's how Safari
does it)

The first times I saw the messages I didn't know where they came from, even
though I knew I just enabled them. It's important that you understand if it was
a website that loaded or not; something - App icon, white-on-black text that
it's a browser error - would make the user experience so much better. 

Comment 11

[Samuel Sidler (old account; do not CC)]

(In reply to comment #10)
> can we customize the error pages for camino?
> 

Please see bug 280190 for the relavent information about customizing and (in
general) beautifying the error pages.

Comment 12

[Ulrik Sverdrup]

Attachment: Screenshot of Error message page with Camino icon - a sketch

Look what a difference an application icon makes.

Sketch done by modifying netError.xhtml from moz source. Can Camino
indepentently set "browser.xul.error_pages.location" and display a custom error
page like this one?
Is there a way we can reference the camino icon from a png file, or does it
have to be available as a chrome:// location?

Comment 13

[Ulrik Sverdrup]

(In reply to comment #12)
I'm sorry for not reloading this bug properly before submitting that last comment.

Comment 14

[Josh Aas]

I propose we keep error pages on and remove the option to do it with dialogs. We
get some size benefits, and we don't have to maintain the dialog option that
way, which I suspect we won't once its not default. We need to make a decision
here. How the error pages look is another bug. Mike? Simon? Say the word and
lets clean this up and close it.

Comment 15

[Chris Casciano]

I have a real issue with the design where the error isn't seen in context once
the swith is made here.

Often, in my tabbed browsing behavior, that context is NOT the page that I may
vist 2 or 5minutes later that I've opened in a background tab, but its the page
in the top tab that I am opening the link from. For example, take the
circumstance of doing a google search and opeing search result in background
tabs. I may open 4 results from the first page of results, 3 more from the
second, spin through the next couple pages, then when satisfied I have what I
need I'll close that top pad and go browsing the opened content.

In the current model, if there is an error with a server not being contacted I
can act on that error by doing things like opening a different result or htting
the google cache link instead because I see the error in the context i'm working in.

I'm sure I will forever be on the opposite side of the masses on this one, and
there are other situations that I've hit where the alert is preferable (they
usually are the result of broken web apps and failed redirects where the action
isn't to reload the broken page, but re-perform the action on the previous one).
I also realize there may be some added cost in size and down the line in time
for maintanance and localization, but until something more is done to make me
aware that an error has happened on the 4th of 7 tabs i've opened from that top
page I am strongly against removing the alert dialog as an option.

Comment 16

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #15)

> there are other situations that I've hit where the alert is preferable (they
> usually are the result of broken web apps and failed redirects where the action
> isn't to reload the broken page, but re-perform the action on the previous one).

When a form submission times out :-(  That's probably a bug that should be
fixed, though, at least to the extent of retaining the form data when hititng
back...

> but until something more is done to make me
> aware that an error has happened on the 4th of 7 tabs i've opened from that top
> page I am strongly against removing the alert dialog as an option.

Doesn't the little yellow /!\ icon cover that bit?

Comment 17

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #16)
> (In reply to comment #15)
> 
> > there are other situations that I've hit where the alert is preferable
> > usually are the result of broken web apps and failed redirects where action
> > isn't to reload the broken page, but re-perform action on the previous one.
> 
> When a form submission times out :-(  That's probably a bug that should be
> fixed, though, at least to the extent of retaining the form data when hititng
> back...

My issue is covered by Bug 299008.  Perhaps there are bugs for the other issues
you mentioned?

Comment 18

[Mike Pinkerton (not reading bugmail)]

let's get this off the radar. we're sticking with error pages, but let's not
worry about getting rid of the code just yet.