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

Issue 603118 link

Starred by 5 users

Issue metadata

Status: Fixed
Owner:
Closed: May 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Regression



Sign in to add a comment

<link rel=import> resource downloaded twice

Reported by markovuk...@gmail.com, Apr 13 2016

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2705.0 Safari/537.36

Example URL:
https://polymerelements.github.io/polymer-starter-kit/

Steps to reproduce the problem:
1. Load the page
2. Open Chrome dev tools
3. You will see that elements.html file was downloaded twice

What is the expected behavior?
File was downloaded only once

What went wrong?
Elements.html file was downloaded twice.

Did this work before? N/A 

Chrome version: 52.0.2705.0  Channel: n/a
OS Version: OS X 10.11.3
Flash Version: Shockwave Flash 21.0 r0
 
Components: UI>Browser>Downloads

Comment 2 by y...@yoav.ws, Apr 13 2016

Cc: y...@yoav.ws
Status: Untriaged (was: Unconfirmed)
Summary: <link rel=import> resource downloaded twice (was: File downloaded twice)
I see this happening in Chrome 52 but not in 49. Potentially related to loading of <link rel=import>.

Comment 3 by mmenke@chromium.org, Apr 13 2016

Components: -Internals>Network -UI>Browser>Downloads Blink>Loader
Nothing to do with downloads or the network stack.
Cc: hirosh...@chromium.org yhirano@chromium.org
Labels: -Type-Bug Type-Bug-Regression
Owner: japhet@chromium.org
Status: Assigned (was: Untriaged)
This is a regression in M51.

Bisect range:
https://chromium.googlesource.com/chromium/src/+log/e7e19cb2ab8b42feb7fa9d25fd313ec14d51b28b..13fe4645b7199ed2da4f1810d4c96262eaecea5f

The only loader-related change in that range is
http://crrev.com/1bef485 Don't duplicate ResourceRequests and ResourceLoaderOptions on ResourceLoader by japhet.

Nate, could you take a look?

Cc: kinuko@chromium.org

Comment 6 by joco@google.com, May 1 2016

I'm seeing the same in a production project. Repro is quite simple:

1. "cat > x.html" with this minimal content:
<!DOCTYPE html>
<html>
<head><link rel="import" href="y.html"></head>
<body></body>
</html>

2. Run "python -m SimpleHTTPServer" and load up the page

3. You see y.html downloaded twice both in Chrome devtools' network tab and in the webserver's console.

I put a script with an alert into y.html, which is only shown once, so at least that's correct.
Labels: -Pri-2 Pri-1
This is negatively affecting production apps that are using Polymer and HTML Imports.
Cc: kenjibaheux@chromium.org
 Issue 602526  has been merged into this issue.
Labels: M-51
Labels: -Pri-1 -OS-Mac OS-All Pri-2
Fix up at https://codereview.chromium.org/1972923004/.

I'm pretty confident this bug is only present when devtools is open. Dropping back to P2 accordingly.
Project Member

Comment 11 by bugdroid1@chromium.org, May 13 2016

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

commit 91ebc4432e63a720d84f38db343b65a0334d0273
Author: japhet <japhet@chromium.org>
Date: Fri May 13 16:17:12 2016

X-DevTools-Emulate-Network-Conditions-Client-Id header shouldn't block cache reuse

This was regressed in https://chromium.googlesource.com/chromium/src/+/1bef485187d2a5eff4fd471cbb0ec97e61759811,
which caused the header to be present on Resource's
m_resourceRequest, where previously it was added to a copy
of that object.

BUG= 603118 
TEST=RawResourceTest.CanReuseDevToolsEmulateNetworkConditionsClientIdHeader

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

[modify] https://crrev.com/91ebc4432e63a720d84f38db343b65a0334d0273/chrome/browser/devtools/devtools_network_transaction.cc
[modify] https://crrev.com/91ebc4432e63a720d84f38db343b65a0334d0273/third_party/WebKit/Source/core/fetch/FetchUtils.cpp
[modify] https://crrev.com/91ebc4432e63a720d84f38db343b65a0334d0273/third_party/WebKit/Source/core/fetch/RawResource.cpp
[modify] https://crrev.com/91ebc4432e63a720d84f38db343b65a0334d0273/third_party/WebKit/Source/core/fetch/RawResourceTest.cpp
[modify] https://crrev.com/91ebc4432e63a720d84f38db343b65a0334d0273/third_party/WebKit/Source/core/inspector/InspectorInstrumentation.cpp
[modify] https://crrev.com/91ebc4432e63a720d84f38db343b65a0334d0273/third_party/WebKit/Source/core/inspector/InspectorInstrumentation.h
[modify] https://crrev.com/91ebc4432e63a720d84f38db343b65a0334d0273/third_party/WebKit/Source/core/inspector/InspectorResourceAgent.cpp
[modify] https://crrev.com/91ebc4432e63a720d84f38db343b65a0334d0273/third_party/WebKit/Source/platform/network/HTTPNames.in

Status: Fixed (was: Assigned)
Given that this appears to only happen when devtools is open, I'm disinclined to merge the fix to M51. If there is evidence it's happening without devtools open, let me know.

Comment 13 by joco@google.com, May 13 2016

Tested my repro from comment 6, it really only happens with devtools. Thanks for the fix.
 Issue gerrit:4216  has been merged into this issue.

Sign in to add a comment