What did you do?

See this codepen: https://codepen.io/erinknowles/pen/KKPaYWx
Note I've seen this bug in jsfiddle and locally also, and tested it in other browsers. I have not tested this on other OSes.

What happened?

If you hover over the div in Firefox (I'm using version 68.0.2 64bit) you'll see small flickering lines appear during the transition, disappearing when the transition is finished.

Here is a screenshot: https://i.postimg.cc/qvrHrNKr/renderingbug.png
Here is the same screenshot with the lines circled: https://i.postimg.cc/CM82KFSx/renderingbug-circle.png
There's a vertical line just to our right of the kitten, and a horizontal line at the top of the kitten's arms.
All lines when they appear span the full height or width of the container.

Note that the lines don't seem to appear if background-size is set to cover, or, when set to 100% if the image is the same aspect ratio as the div.

This issue doesn't seem to occur when scaling <img>s or SVG images.

What should have happened?

Element should have scaled without lines appearing.

Is there anything else we should know?

This isn't an MDN-related bug, but anyhow, I think the fix is quite quick...

What version of Firefox are you seeing this problem in? I can't seem to reproduce it in the latest Firefox Nightly, which suggests to me that it has been fixed.

I did replace the first CSS rule with this:

div {
	height: 400px;
	width: 500px;
	background: url('http://placekitten.com/400/500');
	background-size: 100%;
	transition: all 1s;
}

So that I could see image more clearly.

Hi, thanks for the reply. As I said in my report, I'm using Firefox 68.0.2 (which I believe is the latest version) and that the issue does not occur when you set the size of the container to the same aspect ratio as the image (ie height: 400px and width: 500px on an 400x500px image).
Could you also let me know which versions of Firefox are affected so I can pass that on?
Thanks.

OK, thanks. This does sound like it could use some further investigation, so I've moved this bug into a more suitable bugzilla component so the engineers who really know this stuff in detail can look at it.

I don't see this on Linux + WebRender on Nightly.

Is there any chance you could attach your about:support? Also if you could test https://nightly.mozilla.org to see if it's fixed already it'd be great.

We want to find the text inside the input that the user types, but not stuff
like the placeholder. So check that the anonymous subtree is editable, or skip
it otherwise.

Whoops, sorry, wrong bug.

Comment on attachment 9088680 [details]
Bug 1576308 - Simplify some code added in bug 1490974.

Revision D43743 was moved to bug 1576817. Setting attachment 9088680 [details] to obsolete.

Comment on attachment 9088681 [details]
Bug 1576308 - Only allow finding editable anonymous nodes in form controls.

Revision D43744 was moved to bug 1576817. Setting attachment 9088681 [details] to obsolete.

I don't see the issue on Linux without WebRender either. colorandcontrast, are you still able to reproduce the issue? If so, can you please paste about:support?

Moving to GFX, it looks like a graphics issue to me.

colorandcontrast, does the problem still happen? Can you post about:support to this bug?

:aosmond, can you comment to this bug?

IMPORTANT UPDATE: I just tried Firefox Nightly (version 74.0a1 (2020-01-31) (64-bit)) and the bug is NOT occurring anywhere that I've seen it so far, including in the codepen in my original post.

Attachment 9123884 [details] says that the problem happened with BasicCompositor(software composition).

colorandcontrast, can you also provide about:support of nightly? Thanks!

In your release configuration, you have disabled hardware acceleration and on nightly it is enabled (and you get advanced layers / d2d drawing), hence why the bug goes away. Unless there is a specific bug that regressed this, I suspect this will go away with WebRender Basic. In the meantime, if you are able to re-enable hardware acceleration in your preferences (or set layers.acceleration.disabled to true) you should stop seeing the issue.

For the regression window, please use -pref layers.acceleration.disabled:true with mozregression to ensure we always get the basic compositor.

(In reply to Andrew Osmond [:aosmond] from comment #17)

For the regression window, please use -pref layers.acceleration.disabled:true with mozregression to ensure we always get the basic compositor.

Hello! Attaching the regression range:
Last good revision: 7ef8450810693ab08e79ab0d4702de6f479e678c (2018-04-30)
First bad revision: d2a4720d1c334b64d88a51678758c27ba8f03c89 (2018-05-01)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7ef8450810693ab08e79ab0d4702de6f479e678c&tochange=d2a4720d1c334b64d88a51678758c27ba8f03c89

Thanks for the regression window! I can reproduce this issue with enabling layers.enable-tiles-if-skia-pomtp on Linux.

bug 1727876