Make error pages look less like Windows and more like Camino/Aqua

VERIFIED FIXED in Camino1.5

Status

Camino Graveyard
General
--
enhancement
VERIFIED FIXED
12 years ago
11 years ago

People

(Reporter: Smokey Ardisson (offline for a while; not following bugs - do not email), Assigned: Jon Hicks)

Tracking

({fixed1.8.1})

unspecified
Camino1.5
PowerPC
Mac OS X
fixed1.8.1
Dependency tree / graph

Details

(URL)

Attachments

(5 attachments, 4 obsolete attachments)

The new "prettier" error pages look like they were produced somewhere in the
bowels of the "Drab Grey Factory" in Redmond.  And the alert icon has ugly,
jaggy edges.  The favicon is sort of orangish-yellow rather than the old, bright
yellow one smfr added a couple months ago.

I'm on a pretty flaky connection right now so I'm seeing these things
constantly, thus the ire. :-(

Please tell me it's possible to tweak the CSS to go back to a blue-and-white
theme that looks like it fits in Camino and Aqua (last time I checked in on the
"prettier error pages" bug, it was going to be possible for apps to customize
the CSS themselves; I hope that's still the case with the final resolution of
the bug).

Comment 1

12 years ago
Yeah we can theme the page with a better icon and a better warning site icon,
will look into this when I have time.
Depends on: 312501
As mentioned in bug 312501, I did some investigation of this and we're getting
all the crappy Windows- and jaggy-icon-style crap from embed.jar, so we need bug
302309 fixed or another way to tell Camino not to grab certain items from embed.jar.
Depends on: 302309
It'd be good if we could do this for 1.0. I understand we depend on the other bugs, but if Epiphany can create their own error pages, we should be able to as well.
Target Milestone: --- → Camino1.0
I guess Epiphany figured out a way to override the crappy Classic error page stuff that lives in embed.jar?  ChPe, can you tell us what you guys did?

(And if so, maybe the same methods could help up with bug 248160....)
(In reply to comment #4)
> I guess Epiphany figured out a way to override the crappy Classic error page
> stuff that lives in embed.jar?  ChPe, can you tell us what you guys did?
> 
> (And if so, maybe the same methods could help up with bug 248160....)

I couldn't find any way to override (or even register any additional) chrome URLs from an embedding application; and I needed to substitute mozilla-style i18n with standard gettext i18n. So I chose to do it this way:
implement an nsIAboutModule, registered for "about:neterror", which writes the error page from C++ code. The code is @ http://cvs.gnome.org/viewcvs/epiphany/embed/mozilla/EphyAboutModule.cpp .
(In reply to comment #5)
> implement an nsIAboutModule, registered for "about:neterror", which writes the
> error page from C++ code. The code is @
> http://cvs.gnome.org/viewcvs/epiphany/embed/mozilla/EphyAboutModule.cpp .

Thanks! 

Mike, Simon, is the Epiphany work-around something that's feasible to do for 1.0?

Comment 7

12 years ago
Not gonna happen for 1.0.
Target Milestone: Camino1.0 → Camino1.1

Comment 8

12 years ago
Can we just get a not-so-ugly icon to ship with 1.0 for now (since we've already got a maxi-branch anyway), and then do the Right Thing with the icon for 1.1?

Comment 9

12 years ago
Yeah, like the one in bug 312501.  Nice.
Bug 330421 should let us fork the error page CSS at least on the 1.8 branch :-)
Depends on: 330421
We'd like to fix this for 1.1 using embed-replacements stuff (sub in our own css files to theme the pages).
Assignee: mikepinkerton → nobody
Keywords: helpwanted
QA Contact: general
(Assignee)

Comment 12

11 years ago
Aside from the /!\ icon which used to have pixellated edges, I think the error page looks quite OS X. It's very similar to a lot of pages from the Apple website. 

Having said that, here's a suggestion for some tweaks to the css file that might make it look less drab: http://www.hicksdesign.co.uk/clients/camino/ErrorPage/error.html 
Keywords: helpwanted
Sam has some more detailed feedback somewhere, but the one thing that jumps out is that the "alert badge" on the Camino icon should be in the lower right instead of the top right ;)
Yeah, sorry this took so long. We talked about it a while ago but I neglected to post comments.

As Smokey said, the alert icon feels like it should be at the bottom right of the Camino icon (since that's where alerts are OS wide, normally).

Besides that, we want to get a bit less grey if that's possible, mainly with the background (not the text). Lightening it up would be fine even if it stays grey, just something to make it not as dark and grey. :)

Otherwise, the one Bon Echo reference... ;)

Finally, and not really for you, but rather an implementation detail, we'll need to convert the background image to a data URI in the CSS file so we don't have to link the new background image in embed.jar.
(Assignee)

Comment 15

11 years ago
OK, here's a new version with less grey, and the error icon moved (I'd never noticed that there was a convention for that). I've also introduced more colour.

http://www.hicksdesign.co.uk/clients/camino/ErrorPage/error.html

No problem about converting the images to Data URIs, I was leaving that until it was approved. Also, if Camino allowed me to view rendered source, I wouldn't have had to use Firefox to grab some sample markup! ;o)

(In reply to comment #15)
> http://www.hicksdesign.co.uk/clients/camino/ErrorPage/error.html

We like just about everything about this design. The only changes we'd make are to remove the bullets altogether (so there's just paragraphs of text) and add a bit more spacing between the paragraphs to compensate.

With those changes, we're ready to go with this and you can attach the CSS to this bug. :)

Thanks Jon!

Comment 17

11 years ago
(In reply to comment #16)
> (In reply to comment #15)
> > http://www.hicksdesign.co.uk/clients/camino/ErrorPage/error.html
> 
> We like just about everything about this design. The only changes we'd make are
> to remove the bullets altogether (so there's just paragraphs of text) and add a
> bit more spacing between the paragraphs to compensate.

That feels like a strange idea, as it is a list of points the user can check. Keeping the bullet (but I would just a square list-marker, not an image) enhances this concept visually.

Comment 18

11 years ago
The image-with-arrow bullet looks too much like the gray circular buttons (in iTunes etc) that are clickable. Just use standard bullet points (gray if they become too heavy).
(Assignee)

Comment 19

11 years ago
Created attachment 240636 [details]
Revised netError.css file

Here's the updated css file, with the bullets removed, and the image converted into a data URI.

Regarding different colour bullets to the text - I would need to either be able to change the XHTML markup or use an image to accomplish this. Or is there a -moz property that I'm not familiar with?

Bullets can easily be added back in if need to be. Personally, I feel that square bullets look more 'Windows' than the grey background :)
(Assignee)

Comment 20

11 years ago
P.S http://www.hicksdesign.co.uk/clients/camino/ErrorPage/error.html is updated too.
Comment on attachment 240636 [details]
Revised netError.css file

r=me

(In reply to comment #19)
> Regarding different colour bullets to the text - I would need to either be able
> to change the XHTML markup or use an image to accomplish this. Or is there a
> -moz property that I'm not familiar with?

No, I'm pretty sure we can't change the color of the bullets without editing the xhtml, which is something we were trying not to do so we could get updates from core as necessary.

Simon, given the above, is it alright to not have bullets at all? I personally think this looks great.
Attachment #240636 - Flags: superreview?(sfraser_bugs)
Attachment #240636 - Flags: review+
Comment on attachment 240636 [details]
Revised netError.css file

This needs to land at embed-replacements/skin/classic/global/netError.css (mind the camelCaps)
(In reply to comment #19)
> Regarding different colour bullets to the text - I would need to either be able
> to change the XHTML markup or use an image to accomplish this. Or is there a
> -moz property that I'm not familiar with?

This rule seems to work, if we want bullets (uncle google pointed me to ua.css):

*|*::-moz-list-bullet {
  color: firebrick;
}

Choose a better color, of course ;)

Comment 24

11 years ago
(In reply to comment #23)

> *|*::-moz-list-bullet {
>   color: firebrick;
> }
> 

yes, that is the property.

> Choose a better color, of course ;)
> 
:-)
I'll attach a screenshot with the listmarker set to grey ('gray'). You could of course use any of the valid list makers (disk, circle, ..). I don't remember offhand if there are any -moz specific list markers.

A small nitpick, when viewing the latest sample, the <button> is slightly misaligned (too much left margin). Or is that because you use a <input type="button"> nested inside the <xul:button>? I would then catch the margins from forms.css.

Comment 25

11 years ago
Created attachment 240695 [details]
sample for the list marker

it is just a sample, one could make it blue...

In my previous comment 
> yes, that is the property
should read: that is the selector (!)

Comment 26

11 years ago
Created attachment 240697 [details]
better screenshot

Using Jon's stylesheet, but with grey listmarker
Attachment #240695 - Attachment is obsolete: true

Comment 27

11 years ago
Why the sharp-cornered squares, and not circles?

Comment 28

11 years ago
Created attachment 240705 [details]
screenshot with disc

In reply to comment 27

No particular reason other than my  distraction.

Note: with Jon's stylesheet the white-space between the list items might be a tad too large.

Comment 29

11 years ago
I think the discs need to be a tad larger, and perhaps a little ligher gray. But overall, looks good.

Comment 30

11 years ago
Created attachment 240707 [details]
Screenshot, bigger disc, lighter grey

Different Error Page, the disc is a bit bigger, lighter grey (#999 instead of 'gray' - #808080;)

When I look at this error page, I think the white space between the list items should be less.
The original netError.css has 0.5em bottom margin, Jons latest has 1.5em bottom margin.

rules
*|*::-moz-list-bullet {
  color: #aaa;
  font-size: 1.2em
}
(Assignee)

Comment 31

11 years ago
Ah, so there is a moz selector for bullets!

If we're going back to using bullets, yes the margin needs to be less again.

Comment 32

11 years ago
Created attachment 240714 [details]
netError.css used

The stylesheet I've used
We might also consider prettifying config.css (the about:config warning) in a similar way in another bug; if so, someone should file it.

Comment 34

11 years ago
(In reply to comment #33)
> We might also consider prettifying config.css (the about:config warning) in a
> similar way in another bug; if so, someone should file it.
> 

done: bug 355080
Comment on attachment 240636 [details]
Revised netError.css file

We discussed this at this morning's meeting, and we want to use philippe's bullets (but go back to the sane "section" spacing that Jon had before dropping the bullets).
Attachment #240636 - Flags: superreview?(sfraser_bugs)
(Assignee)

Comment 36

11 years ago
Created attachment 241193 [details]
netError.css file with previous spacing restored

Here's the css again, with Philippe's bullets and the spacing we had previous to removing the bullets
Comment on attachment 241193 [details]
netError.css file with previous spacing restored

That's actually your error.html sample ;)
Attachment #241193 - Attachment is obsolete: true
(Assignee)

Comment 38

11 years ago
Created attachment 241212 [details]
the REAL netError.css

whistles and shuffles feet...
Attachment #241212 - Flags: superreview?(mikepinkerton)
Attachment #241212 - Flags: review+
Created attachment 241222 [details]
Screenshot using attachment 241212 [details]
Attachment #240636 - Attachment is obsolete: true
Attachment #240714 - Attachment is obsolete: true
Comment on attachment 241212 [details]
the REAL netError.css

sr=pink
Attachment #241212 - Flags: superreview?(mikepinkerton) → superreview+
Whiteboard: [needs checkin]
Assignee: nobody → jon

Comment 41

11 years ago
Checked in on trunk and 1.8branch.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
Whiteboard: [needs checkin]
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.