Closed Bug 1083113 Opened 7 years ago Closed 6 years ago
Hovering over images doesn't work on e
.g . 4chan
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:36.0) Gecko/20100101 Firefox/36.0 Build ID: 20141014030201 Steps to reproduce: I set the option on 4chan to show full-size images on hover, HTTPS was also enabled. I went onto a /g/ thread and noticed the issue. Admittedly I thought this was caused by an unofficial Firefox build I used to use. Actual results: Firefox either shows a section of an image upon hovering it or hasn't decoded it properly. This doesn't occur for every image. Expected results: Images should render the same as clicking it.
Ys, it's broken, image loading and decoding is partial or missing. Regression range: good=2014-09-26 bad=2014-09-27 http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9e3d649b80a2&tochange=818f353b7aa6
I'll take a look at this. It's not obvious to me why this is happening. Bug 1069369 seems to have triggered multiple bugs that probably all have the same underlying cause as this one.
Tracking since this is a recent regression we should be able to revert or find a forward fix before Beta.
Seth - this is a pretty ugly glitch to ship, I realize we can't backout bug 1069369 for stability concerns, so do you have any other ideas or WIP to get try builds to test on that might address this issue?
We're out of time for 35, this has to be a wontfix. Will make a note in release notes about it and ni? on Tyler so UA is aware this might come up on release feedback.
This seems to be working for me on 36.0a2 (2015-01-01), but is not working on 35. Both on Mac OS X/10.10.2.
(In reply to gregg from comment #7) > This seems to be working for me on 36.0a2 (2015-01-01), but is not working > on 35. Both on Mac OS X/10.10.2. That's what I would expect. A lot of the code involved here got totally rewritten in 36. Because of that, it's generally impossible to share any fixes between 35-and-before and 36-and-after. =(
Seth, I am going to assign this bug to you. Feel free to reassign if you think someone could fix this bug faster.
Assignee: nobody → seth
On Linux, if I force acceleration on (layers.acceleration.force_enabled = on), I get this bug. Turning acceleration off (GPU Accelerated Windows 0/1 Basic) prevents this bug from appearing. This is using Mesa 10.4 and Intel HD 4600 graphics.
This seemd to be fixed by Bug 1098958 in Firefox36 beta. Could you try Firefox36 beta, Aurora37.0a2 and Nightly38.0a1. https://www.mozilla.org/en-US/firefox/channel/#beta https://www.mozilla.org/en-US/firefox/channel/#developer https://nightly.mozilla.org/
It wasn't fixed in any recent Nightly build but I'll test it. I won't clear the [needinfo] for now.
Confirmed fixed, tested in Nightly 20150116.
Can someone from QE check if it is also fixed in 36 and 37? Thanks
Confirming fixed for 36 and 37!
A flavor of this seems to have reappeared in 36. Running 36.0.4 right now, GeForce 560GT with nVidia driver version 347.52. Hardware acceleration enabled in the options pane causes images, especially those found on the front page of reuters.com to render partially black. Turning hardware acceleration off works around the issue.
(In reply to spizzbool from comment #18) > A flavor of this seems to have reappeared in 36. Running 36.0.4 right now, > GeForce 560GT with nVidia driver version 347.52. Hardware acceleration > enabled in the options pane causes images, especially those found on the > front page of reuters.com to render partially black. Turning hardware > acceleration off works around the issue. Please, could you file a new bug report with a testcase (URL, html file).
Yes, that's definitely a different bug. Sounds like it belongs in the Graphics :: Layers component.
You need to log in before you can comment on or make changes to this bug.