Closed Bug 303193 Opened 19 years ago Closed 18 years ago

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

Categories

(Camino Graveyard :: General, enhancement)

Product:
Camino Graveyard
Component:
General
Platform:
PowerPC
macOS
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Camino1.5

People

(Reporter: alqahira, Assigned: jon)

References

(
URL
)

Details

(Keywords: fixed1.8.1)

Attachments

(5 files, 4 obsolete files)

better screenshot
40.36 KB, image/png
Details
screenshot with disc
44.03 KB, image/png
Details
Screenshot, bigger disc, lighter grey
43.29 KB, image/png
Details
the REAL netError.css
13.21 KB, text/css
alqahira
: review+
mikepinkerton
: superreview+
Details
Screenshot using attachment 241212
60.49 KB, image/png
Details 
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).
Yeah we can theme the page with a better icon and a better warning site icon,
will look into this when I have time.
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?


Not gonna happen for 1.0.
Target Milestone: Camino1.0 → Camino1.1
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?
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
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 
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.
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!
(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.
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).
Attached file Revised netError.css file (obsolete) — 
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 :)
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 ;)
(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.
Attached image sample for the list marker (obsolete) — 
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 (!)
Attached image better screenshot — 
Using Jon's stylesheet, but with grey listmarker
Attachment #240695 - Attachment is obsolete: true
Why the sharp-cornered squares, and not circles?
Attached image 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.
I think the discs need to be a tad larger, and perhaps a little ligher gray. But overall, looks good.
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
}
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.
Attached file netError.css used (obsolete) — 
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.
(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)
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
Attached file the REAL netError.css — 
whistles and shuffles feet...
Attachment #241212 - Flags: superreview?(mikepinkerton)
Attachment #241212 - Flags: review+

        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

    
    

    
  
Checked in on trunk and 1.8branch.
Status: NEW → RESOLVED
Closed: 18 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.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: