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

Issue 672694 link

Starred by 3 users
Status: Archived
Owner:
█ allada@chromium.org
Last visit > 30 days ago
Closed: Dec 2017
Cc:
█ brajkumar@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

link rel=preconnect not working

Reported by daniel.b...@gmx.de, Dec 9 2016 
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.75 Safari/537.36

Steps to reproduce the problem:
1. Goto https://jsfiddle.net/fdzc8nrz/4/
2. Open Dev Tools Network tab
3. Hit the load image button
4. Select the image request
5. Select the timing tab in the detail view
6. See that the image request caused a connection to the host, instead of the link rel="preload" node.

What is the expected behavior?
The connection should have already been established and the browser should not resolve DNS and establish a socket connection as part of the image request.

What went wrong?
The browser only establishes the connection once the image is loaded.

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 55.0.2883.75  Channel: stable
OS Version: OS X 10.12.1
Flash Version: Shockwave Flash 23.0 r0
Screen Shot 2016-12-08 at 7.17.19 PM.png
34.0 KB View Download

Comment 1 by daniel.b...@gmx.de, Dec 9 2016 

> instead of the link rel="preload" node
I obviously meant link rel="preconnect" node.

Comment 2 by nyerramilli@chromium.org, Dec 9 2016

Components: Platform>DevTools>Network
Labels: M-55

Comment 3 by kkaluri@chromium.org, Dec 12 2016

Labels: prestable-55.0.2883.75

Comment 4 by brajkumar@chromium.org, Dec 12 2016

Cc: brajkumar@chromium.org
Labels: Needs-Feedback
Tested this issue on Mac OS 10.12 using chrome latest stable M55-55.0.2883.87 by following steps mentioned in the original comment. Observed the connection have established once the image has loaded without DNS lookup.

daniel.baulig@ Attaching screen-shot, could you please confirm is this is the expected behavior of the issue?

Thanks!
Screen Shot 2016-12-12 at 4.54.38 PM.png
187 KB View Download

Comment 5 by daniel.b...@gmx.de, Dec 13 2016 

brajkumar@: yeah that looks right. 

One thing I did not outline in my repro steps is that you will have to make sure to run this test on a "fresh" instance of Chrome to prevent any already open connections to be reused. What I did to ensure this is close all Chrome tabs, then right click the Chrome symbol in the OSX dock, select quit. Wait until the Chrome icon disappears (if not pinned) and then re-open Chrome.

I just re-ran the test and it continues to not do the right thing for me (see attached screenshot).
Screen Shot 2016-12-13 at 1.40.39 PM.png
72.1 KB View Download

Comment 6 by chenwilliam@chromium.org, Dec 13 2016

Owner: allada@chromium.org
Status: Assigned (was: Unconfirmed)
allada@ can you take a look at this? It sounds like this might not be an actual DevTools bug but something with the Network layer so feel free to re-assign / re-categorize.

Comment 7 by dgozman@chromium.org, Dec 1 2017

Status: Archived (was: Assigned)
►

Sign in to add a comment