[Affected versions]:
Nightly 67.0a1

[Affected platforms]:
Platforms: Windows

[Steps to reproduce]:

1. Open the Firefox browser and set the gfx.webrender.all.qualified - true
2. Reach https://www.samsung.com/ro/
3. Scroll from the top to the Watches thumbnail and place the mouser cursor on top of the image.

Expected Result:
The Watches from the thumbnail should not jiggle when coming into view.

Actual Results:
The watches and other pictures from the website are jiggling when coming into view.

This issue was tested on windows 10 with Nvidia GT 730 as well as Nvidia GT 1030.

I don't think I can reproduce now that bug 1453935 has landed.

Not sure if this is the same bug, but some thumbnails are still jiggling when hovering with webrender on (and do not with off)

For instance on this site (particularily the bigger ones:
https://news.err.ee/

Reopening to include err.ee issue.

I tested this site numerous times, but I think I finally reproduced the behavior we actually have concerns about. In the screencast, Firefox 65.0 + Basic compositor is on the left, and Firefox 67.0 (20190225102402) + WebRender is on the right. What I originally thought was the problem was us snapping the image +/- 1 pixel within a constant/defined bounding box, which I can reproduce on Chrome, Firefox with and without WebRender. However the real concern which is hopefully more clear in this screencast is the fact that the image's bounding box moves during the transform.

Reproduces for me on Linux at 67% zoom. On hover out, I can see the transform cause us to display the image out at width X, width X - 1, and finally width X.

We see this even with non-WebRender in release, depending on the zoom level. For me I saw this at two different zooms as recorded in the video. It is worse with WebRender because it happens at more zoom levels, but I don't think we can block on it given we already see it today.

They no longer seem to resize but the image still can snap after the animation. Needs further investigation as to why, as we no longer snap the animation itself anymore.

Andrew, where is this at now?

Not fixed, needs more investigation now that the other snapping work got in.

Want to look at this again soon?

I found bug 1611601 helped with some cases of this on news.err.ee in my local build, but not all. There must be other root causes.

I've been working to reduce this although I note it now has the same behaviour as basic compositor for me right now. Chrome handles the handle with far less jerking movements, although I would note that does badly on particular images on the page that we do well.

After discussing this more with Andrew, I am marking this as fixed as we have improved it as much as we can in WR and issues can be reproed in basic and in Chrome.