New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 598198 link

Starred by 5 users

Issue metadata

Status: Archived
Owner: ----
Closed: May 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 3
Type: Bug-Regression



Sign in to add a comment

Rendering of cached images is blocked by AJAX requests

Reported by sampo.ni...@wellmo.com, Mar 27 2016

Issue description

Chrome Version       : 49.0.2623.75 (64-bit)
URLs (if applicable) : http://sampo.kapsi.fi/queue/
Other browsers tested:
    Firefox: OK
         IE: OK


What steps will reproduce the problem?
(1) Open http://sampo.kapsi.fi/queue/
(2) Click on "Start test"  (This starts 20 concurrent slow AJAX requests, and immediately adds an <img> element that points to an image that is already in the browser cache)

What is the expected result?
The image is rendered immediately, since it's already in the browser cache.

What happens instead?
The image is rendered only after 15-18 AJAX requests have received their responses.  The image is as that point retrieved from the cache (not the server) and rendered.


It seems that Chrome adds all image load requests to the request queue, even though the image is already in the cache and does not need a request to the server.  Thus rendering of the image is blocked until sufficiently many previous requests have been processed.  This happens both when the image is cached using far-future cache headers and when using a cache manifest.

I've tested this on Chrome 49/Linux, Chrome 49/Win, Chromium 48/Linux and Chrome 49/Android 5.1.1 (on Samsung Galaxy S6)

All other browsers I've tested (Firefox, IE10, Android 4.4 native browser) render the image immediately.

This is especially troublesome for mobile web apps.  Our web app uses the cache manifest to store locally all images it uses.  When the app starts, we launch several AJAX requests to update data from our server.  It then renders a page (depending on how it was launched), but images on that page won't render until some of the AJAX requests have been completed.  On cellular networks this can take several seconds when it needs to initialize the network connection first.

The only workaround I've come up with is to create <img> elements pointing to each image the may app use before launching the AJAX requests.  The <img> elements don't even need to be added to the DOM.  This causes the image to be fetched from the browser cache, and after that rendering it is no longer blocked by the AJAX requests.  This can be tested on the page by either re-doing the test or by clicking "Create img element" first.  (Performing an AJAX request to the image does not help - the example page does that to ensure the image is in the browser cache.)

 
Components: Blink>HTML>Image
Labels: -Type-Bug M-51 OS-Linux OS-Mac OS-Windows Type-Bug-Regression
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue on Windows 7, Mac 10.10.5, Ubuntu 14.04 using 49.0.2623.75, latest stable 49.0.2623.110, canary 51.0.2692.0 as per tseps in comment #0.

This is regression issue broken in M-36.

Please find below bisect info:
Last good build:36.0.1934.0
First bad build:36.0.1935.0

MANUAL CHANGE LOG:
https://chromium.googlesource.com/chromium/blink/+log/c46054d2d370739b7eec8584eaa7c332ea8eed34..8547cfffb1ec64a10a09317e869231ecc4f5d0ec?pretty=fuller&n=10000

CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/f8c6c344f13d64c5e20a7b2a6ccbdd3eeaf7b8d3..6f451a479d2a50960c9250d58d6884254004c999

BLINK CHANGELOG URL:
http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog_blink.html?url=/trunk&range=171186%3A171183

Unable to find suspect from above CLs. Hence, marking it as untriaged.
Could anyone from dev team look into this issue please.

Comment 2 by tkent@chromium.org, Mar 31 2016

Components: -Blink>HTML>Image Blink>Image Blink>Loader
Cc: bmcquade@chromium.org pmeenan@chromium.org rdsmith@chromium.org
Status: Available (was: Untriaged)
This is an interesting case for resource prioritization. I am able to repro.

Even though the resource is in the disk cache, it sits in the per-domain queue behind other resources not in the cache, and is starved.

Seems like we should be checking the disk cache eagerly before letting a request sit in the per-domain queue behind requests that can't be satisfied from cache.

Randy, Pat, do you see a way to address this case?
This work is in flight
https://codereview.chromium.org/1706903003/
Components: -Blink>Image -Blink>Loader Internals>Network
Owner: pmeenan@chromium.org
Status: Assigned (was: Available)
Great, thanks! In that case, assigning to Pat. Pat, can you confirm that this issue is fixed by your change?
I presume my work will also fix this (since I'm moving throttling under the disk cache) but Pat's will probably land earlier.  Still, if there's a lot to do on https://codereview.chromium.org/1706903003/, feel free to reassign it to me and it should be dealt with by handling  issue 600839 .

Owner: rdsmith@chromium.org
Reassigning to rdsmith@

His work on prioritization/fetch changes will eliminate the throttling as well as obsolete the changes I was working on.  The hooks for my changes are actually about to get removed so it's probably a dead end at this point.

Owner: ----
Status: Available (was: Assigned)
Sadly, I don't think I'm going to be getting back to this anytime soon.

Cc: -rdsmith@chromium.org
Status: Archived (was: Available)
Artchiving this, but we are doing work on prioritization that may fix this.

Sign in to add a comment