Images coming from imgix as 1x1

crestenstclair commented 9 years ago

Currently, we're using the imgix library to build URLs. The images are coming back in the correct size, but for some reason the browser thinks the image is only 1x1 Natural when I hover over the link.

Additionally: this only happens on some of our computers.

Any thoughts?

crestenstclair commented 9 years ago

[Link](http://albertio.imgix.net/user-assets/bethperna/3bd53710-34a5-4b13-9c7a-109c2d672174-A. P. Exam Scores.png?ixjsv=1.2.0&w=0.5):

![bacon](http://albertio.imgix.net/user-assets/bethperna/3bd53710-34a5-4b13-9c7a-109c2d672174-A. P. Exam Scores.png?ixjsv=1.2.0&w=0.5)

goldendase commented 9 years ago

I should note that the image is actually sized with 0.5px by imgix in this case. It doesn't interpret the value as a percentage as per the docs. We've also eliminated styling, JS, plugins, and browser issues as the possible source of the error here.

jayeb commented 9 years ago

Hey folks, thanks for bringing this up. This doesn't look to me like an imgix.js bug in particular, but possibly something to do with our back-end. In the interest of keeping the GitHub issues for this project clean and focused, I'm gonna close this ticket and suggest we move to our support system instead. Would one of you mind writing to support@imgix.com with this issue? I'll make sure the ticket gets picked up as soon as it comes in.

jayeb commented 9 years ago

Ach, I spoke too soon. I see the problem now, re-opening this ticket. Sorry for the hassle.

jayeb commented 9 years ago

Can you be more specific about which browsers/systems you're seeing this behavior in?

goldendase commented 9 years ago

We've seen this behavior on:

Chrome, Safari, Firefox (all latest versions)

as well as:

OS X (Mav and Capitan) and Ubuntu 14.04 and Ubuntu 15.04. So pretty much everywhere.

jayeb commented 9 years ago

The link you left above is serving the image at the correct size, so something must be going on in-page. Can you send me a link to the page that's displaying the issue, or perhaps provide some more details about how you're using imgix.js?

goldendase commented 9 years ago

[REDACTED], then click the "Preview" button in the top left. If you inspect element above where it says "Based on these probabilities" you'll see imgix importing it as 0.5px wide.

jayeb commented 9 years ago

I hate to be this guy, but I can't repro on my machine :disappointed: The image appears correctly in context: http://cl.ly/image/1Q291X2J3e1l And the inspector reports dimensions of 401px × 71px: http://cl.ly/image/441J242D3w2z

Perhaps there's some kind of race condition happening? I'm gonna look into your JS and see if anything stands out.

goldendase commented 9 years ago

Nah, it's minified code. We've eliminated race condition as a possibility as well... We have the image get included after a 5 second setTimeout in the div and it still sizes 0.5w for most everyone here. Also, the people that it doesn't happen for aren't ever able to get it 'wrong'. If it was a timing issue, they'd eventually hit the negative case.

jayeb commented 9 years ago

What can you tell me about this method? As far as I can tell, it's the only place in your code using imgix.js.

function() {
    var e = .01 * Math.round(this.props.imageSize) || 1,
        t = new c["default"].URL(p["default"].IMAGE_CDN_URL + this.props.imageUrl).setWidth(e).getURL();
    return l["default"].createElement("img", {
        className: "imgix-image",
        src: t,
        ref: "img"
    })
}

Where does the value for this.props.imageSize come from, and what range of values does it cover?

Also, can you send me a screenshot of the image size as reported by your inspector?

goldendase commented 9 years ago

The inspector reports size of 1 x 0px. Image size is always 50 in this case (it's loaded from the DB and we've verified with debugger that it is always indeed 50). We've also just straight up hardcoded it to return the exact URL from this function with w=0.5 to no success. Does just including the npm imgix package run any postprocessing on the pages (does it listen to events or w/e)? Otherwise, this is probably a backend issue as the inspector also says "Natural: 1x1 px"

jayeb commented 9 years ago

No, including imgix.js on the page doesn't listen to any events by default.

If you view the image directly, everything looks right, correct? http://albertio.imgix.net/user-assets/bethperna/3bd53710-34a5-4b13-9c7a-109c2d672174-A.%20P.%20Exam%20Scores.png?ixjsv=1.2.0&w=0.5

goldendase commented 9 years ago

Yup, it does... It's only the embedding in an img that causes chaos... We've gone through several arguments with culprits suspected being imgix, styling, browser issues, plugins, etc and revisited all these several times over... It does seem that somehow, sometimes, most users see this image scaled down (by imgix) to 0.5px (basing this mostly on the fact that the inspector reports 1x1 as the natural size).

jayeb commented 9 years ago

Can you send me a screenshot of the image size as reported by your inspector?

Also, can you find this image request in your network tab and send me all of the request and response data?

goldendase commented 9 years ago

[redacted]

jayeb commented 9 years ago

That Content-DPR: 802 header is fishy. We're looking into it.

goldendase commented 9 years ago

Also note: [redacted] The width is exactly 0.500 pixels with height auto-scaled when I'm asking for w=0.5 as query param. No way that's coincidence...

jayeb commented 9 years ago

Sorry, you lost me there. Where are you getting the 0.500px value from?

goldendase commented 9 years ago

Bottom right of screenshot - see the blue area with 0.500 x 0.078? That's the dim of the img node in pixels. I just confirmed - the single person on the team for whom this does not happen still has the content-dpr 802 in his headers.

jayeb commented 9 years ago

Can you confirm that single team member's browser version? I suspect they just have a browser that doesn't interpret the Content-DPR header.

It looks like we're sending that browser back when we shouldn't be an confusing the browser. It thinks it's rendering a 401px-wide, 802-DPR image, so it's rendering it at 0.5px wide.

We're figuring out the fix now. I'll keep you posted.

goldendase commented 9 years ago

Awesome, thanks for the fast and consistent response and not dumping me into support :)! His Chrome is Version 45.0.2454.101 (64-bit). He also tried it in Firefox Dev Edition where he still sees it totally normal. I tried it in vanilla firefox, where the error does occur. I'll try it in dev edition now.

jayeb commented 9 years ago

Alright @goldendase, the issue has been resolved and appears to be working correctly in Chrome 47-beta and Firefox 42.

This whole mess was the result of two small bugs in the new Client-hints support we rolled out on Wednesday, compounded by some unexpected behavior from Chrome and Firefox:

The value we were calculating for the DPR value was wrong, obviously (If you know of a device that has an 800+ DPR, let me know so I can buy one). This miscalculation was due to a fairly mundane logic error in our code related specifically to w values below 1.
We were serving images with a Content-DPR header even when the client wasn't requesting any client hints.
Firefox appears to be respecting the Content-DPR header, which is news to me. As far as we're aware, Firefox's Client-hints implementation is stuck in committee.
The browsers were using the Content-DPR value we were providing to make an inference about the size of the image provided, despite not having the expected headers in the request, or the relevant <meta> tag in the page's head. It's unclear to me whether this is expected behavior for the browser or some forgotten edge-case bug.
It also seems that Chrome was stripping Content-DPR headers out of requests in the beta version of Chrome 46 rather than just ignoring them is it would in older versions (presumably it was easier for them to switch the feature on and off this way), so our testing of our own client-hint support before was quietly missing this particular case.

Like I said at the top, the bugs on our end have been fixed and everything appears to be functioning properly now. Let me know if you still see a problem on any of the browsers in your group.

wuservices commented 9 years ago

@jayeb I hit this too today and support sent me to this as the post mortem. I mentioned to support that it's important for us to never see Content-DPR in an image response unless we explicitly request it somehow. I wasn't aware that the browser would look for that header and resize the image appropriately, but if we ever see that in a response header, it would break our site right now.

The reason is that we're transitioning to high DPR images but all our images aren't actually high DPR. Therefore if I have an image that's supposed to be 940 px on screen but the source image isn't high DPR, an imgix.js request will have something like dpr=2&fit=max so the returning image will only be 940 px. If you return Content-DPR: 2 in the response, Chrome would render the image at half the size which is not what we want.

I'm about to roll out Client Hints so I'll have the <meta> tag in the head. However this caught my eye in your writeup:

The browsers were using the Content-DPR value we were providing to make an inference about the size of the image provided, despite not having the expected headers in the request, or the relevant tag in the page's head

Is your intent to include the Content-DPR header in the response if the client does send something like DPR: 2 in the request? I would hope for no because that would break us for the reason I mentioned above.

jayeb commented 9 years ago

@wuservices If the client sends a DPR: n header, and the imgix URL you're requesting includes a ch=DPR parameter (see our docs), we'll send the Content-DPR header in the response. If both of the above conditions aren't met, we will not send the Content-DPR header in the response.

goldendase commented 9 years ago

@jayeb Looks like we're all good now. Thanks for the quick turnaround. Nice catch on the Content-DPR header!

wuservices commented 9 years ago

@jayeb Thanks for clarifying. That behavior sounds good. It also looks like you're awesomely being smart enough to compensate for images that are too small with ch=DPR also whereas I was getting Content-DPR > 1 returned when the image wasn't actually big enough before - at least in some cases.

imgix / imgix.js

Images coming from imgix as 1x1 #70