Closed Bug 229737 Opened 21 years ago Closed 19 years ago

[RFE] Favicons for XUL error pages


(Core :: DOM: Navigation, enhancement, P3)






(Reporter: mxn, Assigned: mconnor)



(Keywords: fixed1.8)


(4 files, 3 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 Firebird/0.7

The XUL error pages that are still under construction should have favicons, to
make it easier to tell when an error has occurred in one of the open tabs.

Reproducible: Always

Steps to Reproduce:
1. Enable XUL error pages. (Set "browser.xul.error_pages.enabled" to "true")
2. Go to a website that'll time out, or to one that doesn't exist. (I provided a
URL above if you're out of ideas.)
3. Open a bunch of other tabs and do some regular browsing.

Actual Results:  
Once the original tab loads the XUL error page, the tab displays the normal page
proxy icon (which usually looks like a sheet of paper or a bookmark).

Expected Results:  
In order for the user to more quickly realize that there is a problem, the tab
with the XUL error page should have a special favicon (for example, a red circle
with a white "x" on it). The image itself should be part of the theme.

This would probably involve adding the following after the <style> tag:

<html:link rel="icon" href="chrome://global/skin/icons/luna-error-small.png"
type="image/png" />


<html:link rel="icon" href="chrome://global/skin/icons/neterror.png"
type="image/png" />

And adding an appropriate image to the default theme.
Whoops. Ignore the first line of code I gave.
Blocks: errorpages
doesn't need to be as complicated as that

if you have the scriptstatus extension for example, you could use this in


  <link href="chrome://scriptstatus/content/error.png" rel="icon" type="image/png"/>

obviously this would want something global, and guaranteed to be in any given theme
Confirming.  Sounds like a good idea to me!
Ever confirmed: true
-> All/All
OS: Windows 98 → All
Hardware: PC → All
This would be extra cool when bug 28586 is fixed. Maybe the standard document
favicon with an x, similar to IE's broken images?
->core (this lives in docshell)

See the URL for two possible icons (thanks to Wolf for the icons).  Which one
should we use?
Assignee: firefox → cst
Component: General → Embedding: Docshell
Product: Firefox → Core
Target Milestone: --- → mozilla1.8beta
Version: unspecified → Trunk
mconnor suggested asking Kevin and Stephen for UI questions.  
At the moment we use the exclaimation mark in a yellow triangle, but surely a
cross makes more sense when something hasn't loaded properly?
at the moment we use no favicon at all
Sorry, I was referring to the modal dialog which is currently the default way of
showing these errors.
Please use this image if you need something right away:
My personal pick is either the Red Circle w/ X from the URL, or the img from
Comment #11.

Though, is a Red Triangle with an ! platform convention anywhere for an "error"
Keywords: helpwanted
Target Milestone: mozilla1.8beta1 → Future
I have to agree, the circle with the X just looks better.

*** This bug has been marked as a duplicate of 280190 ***
Closed: 19 years ago
Resolution: --- → DUPLICATE
We have to reopen this bug because favicons won't be included within the patch
on bug 280190. The work on that should be done in this bug when bug 301119 is
fixed. Currently loading of favicons from a chrome URI isn't allowed.
Depends on: 301119
Resolution: DUPLICATE → ---
*** Bug 302797 has been marked as a duplicate of this bug. ***
Patch to use the favicon within netError.xhtml. This will be checked-in after
the fix of bug 301119.
Assignee: cst → hskupin
Attachment #191424 - Flags: review?(cbiesinger)
Neil, are you willed to use the same favicon for the SeaMonkey part?
CSS styles already exist for each theme in themes/ and toolkit/themes. We only
have to put warning-small.png into Toolkit (pinstripe, winstripe, qute) and
SeaMonkey (classic, modern) folders.
> CSS styles already exist for each theme in themes/ and toolkit/themes.

hm? how is CSS related to this bug?
(In reply to comment #20)
> > CSS styles already exist for each theme in themes/ and toolkit/themes.
> hm? how is CSS related to this bug?

They're a bad match. I only wanted to explain what things have to done during
the check-in.
Comment on attachment 191424 [details] [diff] [review]
Favicon for netError.xhtml
[See bug 429721]

clearing review request until bug 301119 comment 25 is sorted out.
Attachment #191424 - Flags: review?(cbiesinger)
Let's pull this in from Future. 
Flags: blocking-aviary1.5?
Priority: -- → P3
Target Milestone: Future → mozilla1.9alpha
Attached image generic icon from Kevin
Going to add this as a resource: URI that can be accessed from the error pages,
and figure out what to do about making this skinnable in 2.0
Assignee: hskupin → mconnor
Flags: blocking-aviary1.5? → blocking1.8b4+
Attached patch add data: URI favicon (obsolete) — Splinter Review
ok, so error pages can't get to resource: URIs either.	There was apparently a
concern that this would clobber the bookmark favicon, but I had no issues in
Firefox testing.  SeaMonkey should do their own testing if this breaks their
bookmarks code (though I can't imagine why)
Attachment #192791 - Flags: superreview?(
Attachment #192791 - Flags: review?(cbiesinger)
Whiteboard: [has patch][needs review biesi, sr neil]
Comment on attachment 192791 [details] [diff] [review]
add data: URI favicon

ok, the seamonkey bookmarks code can use document.documentURI to figure out
which url to set the icon for.
Attachment #192791 - Flags: review?(cbiesinger) → review+
Comment on attachment 192791 [details] [diff] [review]
add data: URI favicon

>+    <link rel="shortcut icon" href="data:image/png,%89PNG%0D%0A%1A%0A%00%00%00%0DIHDR%00%00%00%10%00%00%00%10%08%06%00%00%00%1F%F3%FFa%00%00%00%04gAMA%00%00%D6%D8%D4OX2%00%00%00%19tEXtSoftware%00Adobe%20ImageReadyq%C9e%3C%00%00%02%02IDATx%DAb%FC%FF%FF%3F%03%25%00%20%80%98p%883%EF%9Eissf%91%D0%EF%89%19%EC%ED%F8%0C%00%08%20%AC%06%1C_b%19%F9%F4%DE5%15kW%23%16N.%EE%F4%9E%24F%5D%5C%06%00%04%106%03X%1E%3Fz%3B%C1%DAY%87I%5B%9B%9B%C1%DE%3F%98%8D%8D%83%BB%1B%97%01%00%01%84a%C0%C9%B5Q%19%3F%BE~%12P%D5%95%60%60%FC%F9%86A%5D%93%99%9B%93%8B%CD%18%E8%0Acl%06%00%04%10%AA%017%CD%98%EE_9%D4b%EB%A8%C8%CC%F0%E7%3B%03%C3%BF%DF%0C%0C%3F%9E0%B8%04%05%09srqL%C6f%00%40%00%A1%18p%E6%8Ad%ED%BF%7F%FF%F9%15%B5%15%80%1A%DF2%84Ur%01%E97%0C%8A%1A2%8C%5C%3C%02j%7D)%ACV%E8%06%00%04%10%B2%01%CC7%2F_%2C%B6qVa%60%F8%FD%19h%FB%1F%88%E8%FF%7F%0C%0C%9FN08%FB%3B%F2%B3%B21%F7%A3%1B%00%10%40p%03%F6%CD6*be%FE%C5%23%A7*%C1%C0%F0%F3%1D%AA%AA%9F%1F%18%E4T%A5Y%F8%04E%E5%80a%E1%84%2C%05%10%400%03%D8%1F%3Fx%5Dg%E3%A2%CD%C8%F0%FB%0B%C2v8%00%BA%E2%EB%15%06%D7%20%7FaNn%EE%A9%C82%00%01%046%E0%F8r%D7%1Ennfn)%05a%14%DBW%B5%7FC%A8%FC%F1%9EAJ%E6%3B%AB%80%90%80%08%D0%15%1E0a%80%00%02%1Bp%F3%D2%F9d%5B'E%A0%ED%9F%80%96%FD%85%EB%01%07%22%B2%2B~%3Cep%0E%0A%E7gcg%9F%00%13%05%08%20%A6%C3K%BCf%0B%08%09%B1%8B%CBK%01%15%A0%FA%1D%C5%05PWHH%FFe%95%90%91%17%02%BA%22%10%24%04%10%40%2C%AF%9E%3EJ04%E4gb%60bd%60%E0W!%9C%7B%FE%BEa0%B6%D2%E6yt%F7V2%90%B7%1E%20%80X%24%E55%DEm%5E%B7Q%F4%F7%8A3%8C%C4%E6%40VVVv%20u%10%C4%06%08%20FJ%B33%40%80%01%00Tw%91%137*%08%19%00%00%00%00IEND%AEB%60%82" type="image/png" />
1. "shortcut" is a Microsoftism, "icon" suffices.
2. Please use a binary encoding for binaries.
3. That particular image appears to have an artefact on it, and is also not
256-colour safe.
4. Please update line 320 of navigator.js as per biesi's comment.
Attachment #192791 - Flags: superreview?( → superreview-
Comment on attachment 192791 [details] [diff] [review]
add data: URI favicon

OK, it transpires that the artefact gets hidden by the alpha transparency.
this addresses all but the 256 color-safe issue, which is an edge case
Attachment #192791 - Attachment is obsolete: true
Attachment #193389 - Flags: superreview?(
Comment on attachment 193389 [details] [diff] [review]
address Neil's comments, fix seamonkey's check
[(Core part) Checkin: Comment 32]

>-  var url = getWebNavigation().currentURI.spec
>+  var url = document.documentURI.spec
Actually you need
var url = content.document.documentURI;
Attachment #193389 - Flags: superreview?( → superreview+
Attachment #193389 - Flags: approval1.8b4?
Attachment #193389 - Flags: approval1.8b4? → approval1.8b4+
Whiteboard: [has patch][needs review biesi, sr neil] → [has patch][needs checkin]
Fixed, branch and trunk.
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
Keywords: fixed1.8
Whiteboard: [has patch][needs checkin]
mconnor, it doesn't look like you checked in the navigator.js change...
Target Milestone: mozilla1.9alpha → mozilla1.8beta4
Instead of the "data:image/png, etc" url, one could also use:
which is an allready existing icon in the current firefox theme, and also
refered to directly from the toolkit somewhere.
(if chrome access is allowed, see bug 301119)

Currently there is no way to set a favicon using a CSS rule
(may be something like : "body { icon: url("icon.png"); }" ??)
(In reply to comment #33)
> mconnor, it doesn't look like you checked in the navigator.js change...

ping? the xpfe part is still not checked in
xpfe patch checked in
Checking in xpfe/browser/resources/content/navigator.js;
/cvsroot/mozilla/xpfe/browser/resources/content/navigator.js,v  <--  navigator.js
new revision: 1.578; previous revision: 1.577

Checking in xpfe/browser/resources/content/navigator.js;
/cvsroot/mozilla/xpfe/browser/resources/content/navigator.js,v  <--  navigator.js
new revision: 1.577.2.1; previous revision: 1.577
Attachment #194182 - Attachment description: correct xpfe patch → correct xpfe patch [Checkin: Comment 38]
Attachment #193389 - Attachment description: address Neil's comments, fix seamonkey's check → address Neil's comments, fix seamonkey's check [(Core part) Checkin: Comment 32]
Attachment #191424 - Attachment description: Favicon for netError.xhtml → Favicon for netError.xhtml [See bug 429721]
Attachment #191424 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.