User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.17 Safari/537.36 Steps to reproduce: Visit: https://worldofsolitaire.com Click and drag a card around the screen. Actual results: Starting with Firefox 61, some times the painting glitches and the card appears underneath other cards. A moment later the screen paints correctly. Expected results: The dragged card should remain above all other cards as it's z-index is higher. Happens for me with Firefox 61.0.1 64-bit on Windows 7. Oddly it doesn't appear to be happening on my Mac box or Windows 10 box. A simplified codepen/jsbin test case that shows the problem is forthcoming, but first I need to come up with a hack/workaround so my Firefox users don't see the problem anymore.
Component: Untriaged → Layout: Web Painting
Priority: -- → P2
Product: Firefox → Core
Can't reproduce it with Nightly. Will use mozregression to determine when the fix took place.
Whoops, disregard my nightly comment. The "layout.display-list.retain" flag was some how set to "false" which caused the problem to go away. Setting that flag to true shows the problem happening under nightly as well, on my machine.
Ignore my previous comment, I may have been in the wrong window as I can't reproduce under nightly. I will use mozregression to determine more precise info and report back once I have something more concrete.
Update: I have confirmed it DOES still happen in nightly, just harder to trigger. If you click a card and start dragging it, then just don't move the mouse at all for several seconds (while still holding down on the card) then start moving it again then that almost always shows the painting glitch. Also just to be clear, setting "layout.display-list.retain" to false fixes the problems.
Working with Matt Woodrow on IRC we were able to come up with a workaround. I'm about to deploy the workaround to the website, so I have created a standalone test case: https://codepen.io/Sembiance/pen/Xagzog On the code pen drag the pink card, it should always appear over-top the green cards, but sometimes it doesn't in Firefox 61.
Has Regression Range: --- → yes
Has STR: --- → yes
status-firefox61: --- → affected
status-firefox62: --- → affected
status-firefox63: --- → affected
status-firefox-esr52: --- → unaffected
status-firefox-esr60: --- → unaffected
Comment on attachment 8990819 [details] Bug 1474402 - Disable TryUpdateTransformOnly when we have RDL enabled since it can cause sorting issues. https://reviewboard.mozilla.org/r/255852/#review262792 LGTM.
Attachment #8990819 - Flags: review+
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/3f8d4ac2adae Disable TryUpdateTransformOnly when we have RDL enabled since it can cause sorting issues. r=miko
Status: UNCONFIRMED → ASSIGNED
status-firefox61: affected → fix-optional
Ever confirmed: true
Status: ASSIGNED → RESOLVED
Last Resolved: 8 months ago
status-firefox63: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
Matt, is this fix something you're intending for uplift to 62, or do you think it's best to let it ride to release with 63?
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #10) > Matt, is this fix something you're intending for uplift to 62, or do you > think it's best to let it ride to release with 63? It's super low risk, and affected a real site (though a workaround has been deployed), so I think we should definitely take it. I've talked to Ryan about considering it for a ridealong in 61.0.2 too, if such a thing ends up existing.
Comment on attachment 8990819 [details] Bug 1474402 - Disable TryUpdateTransformOnly when we have RDL enabled since it can cause sorting issues. Approval Request Comment [Feature/Bug causing the regression]: RDL [User impact if declined]: Incorrect z-order sorting in some dynamic modification cases, fixes itself fairly quickly though. [Is this code covered by automated tests?]: No. [Has the fix been verified in Nightly?]: Yes, by me. [Needs manual test from QE? If yes, steps to reproduce]: No. [List of other uplifts needed for the feature/fix]: None. [Is the change risky?]: No. [Why is the change risky/not risky?]: Just disables a tricky optimization path that doesn't play well with RDL, falls back to the normal code that we use the rest of the time. [String changes made/needed]: None.
Comment on attachment 8990819 [details] Bug 1474402 - Disable TryUpdateTransformOnly when we have RDL enabled since it can cause sorting issues. I had a look at the test case and it works in nightly. Let's uplift for beta 8.
Attachment #8990819 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
status-firefox62: affected → fixed
Verified as fixed on Nightly 63.0a1(20180716100102) and Beta 62.0b8(20180712042337).
status-firefox62: fixed → verified
status-firefox63: fixed → verified
I verified that the problem is fixed on my website and the test case with win64 Firefox 62.0b12(20180726161819) THANK YOU all very much!
Since 61 is only marked as fix-optional, I'm removing the qe-verify+ flag. Please mark it back if it gets fixed in 61 as well.
Comment on attachment 8990819 [details] Bug 1474402 - Disable TryUpdateTransformOnly when we have RDL enabled since it can cause sorting issues. Simple RDL regression fix verified on Nightly and Beta. Approved for 61.0.2.
Attachment #8990819 - Flags: approval-mozilla-release? → approval-mozilla-release+
status-firefox61: fix-optional → fixed
Verified, that the issue is no longer reproducible on FF release 61.0.2(20180807170231).
status-firefox61: fixed → verified
You need to log in before you can comment on or make changes to this bug.