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

Issue 615473 link

Starred by 1 user
Status: Fixed
Owner:
█ y...@yoav.ws
Last visit > 30 days ago
Closed: May 2016
Cc:
pucchakayala@chromium.org
█ mbarowsky+blinkimage@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: All , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Unsupported image types are requested from <picture> element

Reported by staley.d...@gmail.com, May 27 2016 
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.63 Safari/537.36

Example URL:
http://output.jsbin.com/nolowop

Steps to reproduce the problem:
1. Open Network Inspector
2. Load URL
3. Observe that Chrome requests a JPEG 2000 image.

What is the expected behavior?
Chrome requests only the WebP image.

What went wrong?
Chrome requests the JPEG 2000 image first, and then requests the WebP image when the JPEG 2000 request completes. This results in a duplicate network requests and wasted bandwidth.

This behavior does not occur in Firefox, but the inverse occurs in Safari where it will request the JPEG 2000 image and then the WebP image.

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? N/A 

Chrome version: 51.0.2704.63  Channel: stable
OS Version: OS X 10.11.4
Flash Version: Shockwave Flash 21.0 r0

Comment 1 by pucchakayala@chromium.org, May 27 2016

Labels: Needs-Feedback
This is what i am seeing on Mac OSX 10.11.5 - 51.0.2704.63

Can you please confirm if this is the behavior you were referring to ?
Screen Shot 2016-05-27 at 12.25.26 PM.png
170 KB View Download

Comment 2 by staley.d...@gmail.com, May 27 2016 

Yup, can confirm!
Project Member

Comment 3 by sheriffbot@chromium.org, May 28 2016

Labels: -Needs-Feedback Needs-Review
Owner: pucchakayala@chromium.org
Thank you for providing more feedback. Adding requester "pucchakayala@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 4 by cbiesin...@chromium.org, May 28 2016

Cc: y...@yoav.ws
Components: -Blink Blink>Image

Comment 5 by y...@yoav.ws, May 30 2016

Cc: -y...@yoav.ws pucchakayala@chromium.org
Labels: OS-All
Owner: y...@yoav.ws
Status: Started (was: Unconfirmed)
Project Member

Comment 6 by bugdroid1@chromium.org, May 30 2016 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/56bef09698c3f96a3b8a0f776f4d964bb49bb2a3

commit 56bef09698c3f96a3b8a0f776f4d964bb49bb2a3
Author: yoav <yoav@yoav.ws>
Date: Mon May 30 17:39:28 2016

Avoid downloading unsupported `<source>` types in HTMLPreloadScanner

The preloadScanner was picking non-matching sources as it was ignoring the `type` attribute.
That resulted in unnecessary download. This CL fixes that.

BUG= 615473 

Review-Url: https://codereview.chromium.org/2018353002
Cr-Commit-Position: refs/heads/master@{#396742}

[modify] https://crrev.com/56bef09698c3f96a3b8a0f776f4d964bb49bb2a3/third_party/WebKit/Source/core/html/parser/HTMLPreloadScanner.cpp
[modify] https://crrev.com/56bef09698c3f96a3b8a0f776f4d964bb49bb2a3/third_party/WebKit/Source/core/html/parser/HTMLPreloadScannerTest.cpp

Comment 7 by y...@yoav.ws, May 30 2016

Status: Fixed (was: Started)
Thanks for reporting! I believe the issue is fixed, but please verify and let me know if that's not case
►

Sign in to add a comment