443648 - Acid3 Favicon / Site Icon does not match reference rendering

Status: RESOLVED DUPLICATE of bug 281150

(Firefox :: Tabbed Browser, defect)

Description

[Paul Stone]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9) Gecko/2008061015 Firefox/3.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1a1pre) Gecko/2008070202 Minefield/3.1a1pre

When displaying the Acid3 test, Firefox shows Hixie's 'red cat of failure' as the favicon. The HTML in the reference rendering explicitly sets the favicon to an invalid URL using the following code:

<link rel="icon" href="http://example.invalid/">

Although no favicon is explicitly specified in the Acid 3 test, Firefox does try to fetch /favicon.ico as it does on all sites. On acid3.acidtests.org, this returns a 404 HTTP response with the red cat png as the content.

Hixie states on his blog:

If a browser passes all 100/100 subtests and gets the rendering pixel-for-pixel correct (including the favicon!), then it has passed the standards-compliance parts of the Acid3 test.

I'm not sure exactly what spec would cover this.





Reproducible: Always

Steps to Reproduce:
1. Go to acid3.acidtests.org
2.
3.
Actual Results:  
Image returned in 404 is displayed as favicon

Expected Results:  
No favicon should be displayed

Comment 1

[Met - Martin Hassman]

Confirming based on discussion http://krijnhoetmer.nl/irc-logs/whatwg/20080325#l-475

"<Hixie> if you see that used as a favicon.ico, it's a bug "

Comment 2

[Ryan Flint [:rflint] (ping via IRC for reviews)]

We rely on onerror being fired from the favicon's image element as the signal to flip back to the default favicon, so bug 299138 is to blame here.
We could probably work around this by improving the favicon service a bit (adding a load callback, f.e.) and forcing all icons to be set through it. Even if bug 299138 is fixed, it's probably not a bad idea to do that anyway.

Comment 3

[Bill Gianopoulos [:WG9s]]

In my opinion this is a pretty lame requirement for test passage in absence of a similar requirement that any test failure MUST result in the red cat failure icon being displayed.

Browsers that do any of the following pass this requirement:

 - don't support favicons at all
 - don't permit favicons that are that large (it is 150x150 pixesl)
 - don't support png images as favicons
 - don;t support png images at all

Is there a spec someplace that says what a browser is supposed to do if the server supplies fallback images for 403/404 errors?

I have seen webservers that are configures to return customized error pages for 403/404 errors in url paths other than /images, and for such errors in the /images path, return a 1x1 transparent gif image.  Is the browser supposed to ignore this image and use it's default error handling?  Is there a spec for this?

Comment 4

[Bill Gianopoulos [:WG9s]]

Another issue is that because of what is defined as passing, we actually pass this becuase we show exactly the same favicon on the reference image and it does say:

If a browser passes all 100/100 subtests and gets the rendering pixel-for-pixel
correct (including the favicon!), then it has passed the standards-compliance
parts of the Acid3 test.

Comment 5

[Bill Gianopoulos [:WG9s]]

(In reply to comment #3)
> Is there a spec someplace that says what a browser is supposed to do if the
> server supplies fallback images for 403/404 errors?
> 
> I have seen webservers that are configures to return customized error pages for
> 403/404 errors in url paths other than /images, and for such errors in the
> /images path, return a 1x1 transparent gif image.  Is the browser supposed to
> ignore this image and use it's default error handling?  Is there a spec for
> this?

Ok this part of my comment is way off the mark.  I misunderstood the issue.  I thought the server was returning the red cat failure icon as a 404 error message because it got a 404 error trying to access the file specified on the page as the icon.  That is not the case at all.  The web page is telling the browser not to use the default site icon, but to use an image from non-existent website as the source of the icon.

Since the browser cannot get that icon it seems to fall back to the default behavior of displaying the default site icon.  This would certainly seem to not be correct.  If it can't display the icon specified on the page it should not display a site icon at all.

Comment 6

[Lars Gunther]

> If it can't display the icon specified on the page it should not
> display a site icon at all.

Why? Would not a user prefer a generic site icon to no icon at all? And where *is* the spec about this?

Comment 8

[Bill Gianopoulos [:WG9s]]

I don;t understand at all how this bug is a duplicate of bug 281150.  Bug 281150 is about a favicon image being displayed if the image file is returned in a response form the server that has a 404 error code.

This bug is about the /favion.ico file being displayed if the image specified by a <link rel=icon> can not be displayed because the hostname can not be resolved.

Comment 9

[Dão Gottwald [:dao]]

(In reply to comment #8)
> This bug is about the /favion.ico file being displayed if the image specified
> by a <link rel=icon> can not be displayed because the hostname can not be
> resolved.

That's not my understanding of this bug, and not my understanding of what Acid 3 tests. http://acid3.acidtests.org/favicon.ico should (according to Hixie) not be displayed as the favicon because it has a 404 header. That doesn't mean that we shouldn't try to fetch /favicon.ico in the first place.

Comment 10

[Bill Gianopoulos [:WG9s]]

OK I guess the url http://acid3.acidtests.org/favicon.ico does return a 404 error, but I \we need to find out why the test excepts the favicon.ico file to not display.  Is it becuase it returns with a 404 error (which currently only prevents images form displaying in IE6 and IE 7 and then only if friendly HTML error pages are being displayed) or is is it not supposed to be even attempting to display the site favicon.ico file in cases where the icon specified in the <link rel=icon> can not be displayed.

Comment 11

[Bill Gianopoulos [:WG9s]]

OK. I guess this IS a dupe.  I had emailed Hixie earlier today about this and just got tan e-mail reply.  He says it should not display specifically becuase of the 404 error.