STR: * Open https://medium.com/@schauertime/the-dinner-party-metaphor-3b4da1457569 What happens: The cover/hero/huge image at the top isn't rendered properly. Happens on the latest Nightly. Works fine on Chrome and stable Firefox. I have only tested on Nightly on Windows.

So this image loads fine in Safe Mode, in Normal mode with H/W accel turned off (Basically unchecked 'use hardware acceleration when available' and restarted) the image loads fine, with that option checked, the image doesn't load. So I just talked to :Cork on IRC and he said this might be an issue with my card or driver or some such configuration. Since Chrome also hopefully uses H/W accel and it renders the image fine, it has my card/driver combo blacklisted. Then probably we need to update our blacklist to match that. Another thing which is intriguing is how stable Firefox renders the image fine. That would be possible only if stable Firefox has a separate blacklist than Nightly (and that stable Fx blacklist has my combo). Anyway, I've posted my about:support. Happy to answer any other questions.

Milan, can you help here?

I ran into something like this (see https://bugzilla.mozilla.org/show_bug.cgi?id=1077636#c7), with nightly, on the Mac

I'm seeing another glitch on my cover picture here : https://ello.co/sawrubh. On Chrome, the cover image renders properly. In Nightly, there's some glitch on the right side of the image.

Seth, in the context of our recent "animated images may get displayed before they're fully downloaded", could we be running into something like that for non-animated images? This bug is on Windows, I got a similar problem in OS X (see comment 6), could we be ending up in the image cache without the full image somehow?

(In reply to Milan Sreckovic [:milan] from comment #8) > Seth, in the context of our recent "animated images may get displayed before > they're fully downloaded", could we be running into something like that for > non-animated images? This bug is on Windows, I got a similar problem in OS > X (see comment 6), could we be ending up in the image cache without the full > image somehow? It's actually the normal case that imgRequests are stored in the ImageLib cache as soon as we start the load - before we even receive any data! That's unlikely to be the problem here. If ImageLib *were* behind this bug, I'd expect the cause to be a failure to send invalidations when the image gets fully decoded. That is, we decode the image partially and paint, and then decode some more, but somehow we fail to notify the layout system that it needs to invalidate. I don't think that's what's happening, though, because then the bug shouldn't be affected by whether hardware acceleration is on. Maybe the invalidation isn't getting propagated to the layers system, so we're painting a layer that contains old data? Or maybe this is purely some sort of rendering issue? Unfortunately I can't reproduce any of the test cases given so far here. (OS X 10.9, current Nightly.)

Thanks Seth. Pretty sure now that this is a duplicate of 1085187. Reproducing this depends a lot on the aspect ratio of the browser before we load the page.

Made this a duplicate of a newer bug because the other one has a reduced testcase.