1186324 - Favicon requests are made to root path even if an explicit load direction exists

Status: UNCONFIRMED

(Firefox :: Tabbed Browser, defect)

Description

[Tolis Emmanouilidis]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.134 Safari/537.36

Steps to reproduce:

Add the following tag in the HTML header of a site: 
<link rel="icon" type="image/x-icon" href="/myapp/theme/images/favicon.ico">

Open the browser and navigate to the page containing the tag. Then close the browser, reopen it, navigate to the page again and press Ctrl + F5 multiple times.


Actual results:

Firefox creates some requests to the root path, in order to get the favicon.

"GET /favicon.ico HTTP/1.1" 302 - "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0" 


Expected results:

According http://www.w3.org/TR/html5/links.html#rel-icon "In the absence of a link with the icon keyword, for Documents obtained over HTTP or HTTPS, user agents may instead attempt to fetch and use an icon with the absolute URL obtained by resolving the URL "/favicon.ico" against the document's address, as if the page had declared that icon using the icon keyword."

So, I believe that when a link with the icon keyword exists in the page, Firefox should not try to get the favicon from the root path

Comment 1

[Marco Bonardo [:mak]]

Places only stores the favicon as requested by the browser, so the code doing this lives in browser.

http://mxr.mozilla.org/mozilla-central/source/browser/base/content/tabbrowser.xml#946

I think it may have been done on purpose to try to provide an alternative when the defined icon cannot be loaded (404 or other network error), but I'm not sure, there's not comment in the code regarding that.

Comment 2

[Marco Bonardo [:mak]]

would you mind checking what IE, Safari and Chrome do with your testcase?

Comment 3

[Tolis Emmanouilidis]

(In reply to Marco Bonardo [::mak] from comment #2)
> would you mind checking what IE, Safari and Chrome do with your testcase?

Thank you for looking this issue.

About my testcase:
In Chrome, I don't see any request in the root path. Always, the address defined in the link tag is being used. Also, I have noticed that every time I refresh the page with Ctrl + F5, Chrome performs a new request to fetch the favicon. On Firefox this does not happen. I have to keep Ctrl + F5 pressed for some time and perform many requests to make it fire the favicon GET request. It seems that Firefox caches the favicon image and does not fetch it on every Ctrl + F5.

Comment 4

[adan2jp]

This case happens when Firefox load a page from cache.

I wrote <link rel="icon" type="image/x-icon" href="/xxxx/favicon.ico"> in Head element.
But, Firefox tries load favicon.ico from root.

Comment 5

[u657957]

Firefox 74.0 exhibits this behaviour too. Intermittent requests are made for 'favicon.ico' at the host's root (i.e. GET /favicon.ico) despite the source document specifying alternate, non-root href paths via rel="icon".

Some additional investigation details are available at https://github.com/grocy/grocy/pull/692

Comment 6

[Dave Townsend [:mossop]]

Attachment: test_icon.html

I created a basic testcase and was unable to reproduce this. Are there any additional things needed to reproduce this?

Comment 7

[u657957]

Attachment: test-1.html

Comment 8

[u657957]

Attachment: test-2.html

Comment 9

[u657957]

(In reply to Dave Townsend [:mossop] (he/him) from comment #6)

Created attachment 9137845 [details]
test_icon.html

I created a basic testcase and was unable to reproduce this. Are there any additional things needed to reproduce this?

Thanks - I've taken your file and developed a minimal repro case. This required copying it into two files, and running a small local web server for Firefox to make requests to.

Repro steps:

1. Download attachments test-1.html, test-2.html
2. Begin a local basic Python3 web server

python3 -m http.server --bind 127.0.0.1 8000

3. Navigate Firefox to the first test file

firefox http://127.0.0.1:8000/test-1.html

4. Open the Web Developer 'Network' tab by pressing `CTRL+Shift+E'
5. Update the address in the browser to 'http://127.0.0.1:8000/test-2.html' and press 'Enter'
6. Press the 'Go back one page' button to navigate back to 'test-1.html'
7. Press the 'Go forward one page' button to return to 'test-2.html'

Expected Behavior:

• After navigating forwards to 'test-2.html' at step 7, a single favicon request is made to 'subdir/favicon.subdir.ico'

Actual Behavior:

• After navigating forwards to 'test-2.html' at step 7, two favicon requests are made -- one to 'favicon.ico', and one to 'subdir/favicon.subdir.ico'

Comment 10

[u657957]

I think the problem here relates to the way that addRootIcon is called from LinkHandlerChild.onPageShow.

To resolve a previous bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1483910) the seenTabIcon flag is cleared during the onPageHide event handler. When a page-back and then subsequent page-forward event occurs, the page is hidden, the flag is cleared, and then when the page is re-opened, onPageShow is called and will call addRootIcon as explained previously.