Issue 131567 in chromium: iframes load/reload trigger /favicon.ico request on parent page

[chro...@googlecode.com]

Status: Unconfirmed
Owner: ----
Labels: OS-Android Pri-2

New issue 131567 by diego.pe...@gmail.com: iframes load/reload trigger
/favicon.ico request on parent page
http://code.google.com/p/chromium/issues/detail?id=131567

Chrome Version:
Application Version (from "Chrome Settings > About Chrome"):
URLs (if applicable): Version 19.0.1084.54 (Mac OS X)

From "Android Settings > About Phone/Tablet"
Build number: S7-301uV100R002C170B009
Device: Huawei Mediapad (hws7300u)
Browser: Chrome Beta 0.18.4409.2396

Behavior in Android Browser (if applicable):

iframes embedded in HTML pages trigger /favicon.ico requests in parent
pages.

Steps to reproduce:
1. load in the browser an HTML page containing an iframe
2. refresh/reload the iframe window manually or using a script
3. check the logs for triggered /favicon.ico requests (unwanted)

Expected result:
iframes load/reload don't trigger /favicon.ico request on parent page

Actual result:
iframes load/reload trigger /favicon.ico request on parent page

This has been tested on Chrome for Linux, Mac, Windows and Android.
It get worst on Android were three request are triggered for each iframe
load/reload in the page, since ADs like to do this stuff it seems to me
this is a big penalty for the browser.

These are the fake requests I get from Chrome/Beta in my logs:

[06/Jun/2012:17:03:25 +0200] "GET /favicon.ico HTTP/1.1" 404 183
[06/Jun/2012:17:03:25 +0200] "GET /apple-touch-icon-precomposed.png
HTTP/1.1" 404 197
[06/Jun/2012:17:03:25 +0200] "GET /apple-touch-icon.png HTTP/1.1" 404 189

[chro...@googlecode.com]

Comment #1 on issue 131567 by paulir...@chromium.org: iframes load/reload

trigger /favicon.ico request on parent page
http://code.google.com/p/chromium/issues/detail?id=131567

This superfluous favicon request behavior was discussed on
https://github.com/h5bp/html5-boilerplate/issues/1103
Some test code available there.

[chro...@googlecode.com]

Updates:
Status: ExternalDependency
Labels: Type-Bug Area-UI Feature-Navigation

Comment #2 on issue 131567 by srika...@chromium.org: iframes load/reload

trigger /favicon.ico request on parent page
http://code.google.com/p/chromium/issues/detail?id=131567

Being tracked in relation to http://b/issue?id=5826308

[chro...@googlecode.com]

Updates:
Status: Untriaged
Cc: android-...@chromium.org jap...@chromium.org arus...@chromium.org
Labels: -OS-Android -Area-UI -Feature-Navigation -Mstone-18 OS-All
Area-WebKit WebKit-Loader Mstone-X

Comment #4 on issue 131567 by pe...@chromium.org: iframes load/reload

trigger /favicon.ico request on parent page
http://code.google.com/p/chromium/issues/detail?id=131567

Making this a bit more generic. The redundant favicon.ico loading happens
all across Chromium, whereas the apple-touch-icon(-precomposed).png is
Android's part (as Android enabled TOUCH_ICON_LOADING), but they use the
same code paths. Loading of these icons seems to be triggered by WebKit's
IconController.

Filing this under WebKit for the time being, although it may very well be
networking.

[chro...@googlecode.com]

Comment #5 on issue 131567 by arus...@chromium.org: iframes load/reload

trigger /favicon.ico request on parent page
http://code.google.com/p/chromium/issues/detail?id=131567

WebKit's IconController is fine -- IconController::startLoader() is aware
whether the loader is loading a main frame (in this case it deals with the
IconDatabase that doesn't appear to be enabled) or something else (in this
case it ignores the request).

The root causes:
- We update the set of favicon URLs every time any (sub-/main) frame
didStopLoading(), and
- We do not cache (probably rightfully so) "missing" favicons / failed HTTP
requests.

The sequence of events:
- ChromeRenderViewObserver::DidStopLoading() is getting called for _any_
frame;
- It grabs the set of icon URLs for the _main frame_ and sends it over with
UpdateFaviconURL;
- FaviconHandler::OnUpdateFaviconURL effectively resets the set of
candidates and triggers the history queries.

If the pages contains more than one frame, then DidStopLoading() will be
called 1) multiple times during the loading and 2) whenver any of the
frames is updated.
This triggers spurious history fetches, but because we do not cache
_missing_ favicons, this effectively causes a full HTTP request.

Also, I suspect (but don't have it confirmed) is a "racing" condition of
sorts: while FaviconHandler is busy HTTP-downloading favicons, the frames
on the page could keep reporting DidStopLoading(), which resets the set of
candidates, and we keep re-requesting the same exact URLs we have just
attempted to request.

I have a number of ideas of what and how to fix, but I'm not sufficiently
competent to know what is expected.

[chro...@googlecode.com]

Comment #6 on issue 131567 by arus...@chromium.org: iframes load/reload

trigger /favicon.ico request on parent page
http://code.google.com/p/chromium/issues/detail?id=131567

Moving the OnUpdateFaviconURL from DidStopLoading() to DidFinishLoad()
removed the every-iframe-changes-the-set-of-favicon-urls issue.

I need some input from WebKit people to understand if this is going to be
very painful on specific sites, and there was a deep reason it was done on
didStopLoading and not on didFinishLoad.

https://chromiumcodereview.appspot.com/10831163

[chro...@googlecode.com]

Comment #12 on issue 131567 by ahr...@gmail.com: iframes load/reload

trigger /favicon.ico request on parent page
http://code.google.com/p/chromium/issues/detail?id=131567

so with june 7,2012 date on the first entry on this page, i am surprised.
the multiple download requests from favicon.ico or wherever thankfully
prompted the message query to allow or deny, which i denied. the point is,
this problem still exists. not a techie but still need to let the tech
community know...thanks for that!


--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[chro...@googlecode.com]

Comment #13 on issue 131567 by CSRed...@gmail.com: iframes load/reload

trigger /favicon.ico request on parent page
http://code.google.com/p/chromium/issues/detail?id=131567

this problem still exists

[chro...@googlecode.com]

Comment #14 on issue 131567 by Milandsa...@gmail.com: iframes load/reload

trigger /favicon.ico request on parent page

https://code.google.com/p/chromium/issues/detail?id=131567

This problem *still* exists and I've noticed it also influences sites using
the HTML5 History API. Every time a new state is pushed the favicon(s) are
re-loaded.

[chro...@googlecode.com]

Comment #15 on issue 131567 by aalavant...@gmail.com: iframes load/reload

trigger /favicon.ico request on parent page
https://code.google.com/p/chromium/issues/detail?id=131567

This problem still exists. Why isn't anyone fixing it?

[chro...@googlecode.com]

Updates:
Labels: -Cr-Blink

Comment #16 on issue 131567 by dtapu...@chromium.org: iframes load/reload

trigger /favicon.ico request on parent page
https://code.google.com/p/chromium/issues/detail?id=131567

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #17 on issue 131567 by mwpowell...@gmail.com: iframes load/reload

trigger /favicon.ico request on parent page
https://code.google.com/p/chromium/issues/detail?id=131567

I recently submitted a similar issue. It suddenly, recently broke under
Windows. Fix this issue please, it's a silly one to expect it not to be
an "opt-in" type of feature. i.e. web site should work regardless of
favicon.ico bug.