Closed Bug 1474402 Opened 2 years ago Closed 2 years ago

z-index ordering paint glitches when dragging img's

Categories

(Core :: Web Painting, defect, P2)

61 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla63
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- unaffected
firefox61 --- verified
firefox62 --- verified
firefox63 --- verified

People

(Reporter: robert, Assigned: mattwoodrow)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

Attachments

(1 file)

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
Assignee: nobody → matt.woodrow
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.
Blocks: RDLbugs
Has Regression Range: --- → yes
Has STR: --- → yes
Keywords: regression
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 mwoodrow@mozilla.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
Ever confirmed: true
https://hg.mozilla.org/mozilla-central/rev/3f8d4ac2adae
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
Flags: qe-verify+
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?
Flags: needinfo?(matt.woodrow)
(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.
Flags: needinfo?(matt.woodrow)
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.
Attachment #8990819 - Flags: review?(mstange)
Attachment #8990819 - Flags: approval-mozilla-release?
Attachment #8990819 - Flags: approval-mozilla-beta?
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+
Verified as fixed on Nightly 63.0a1(20180716100102) and Beta 62.0b8(20180712042337).
Status: RESOLVED → 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.
Flags: qe-verify+
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+
Flags: qe-verify+
Verified, that the issue is no longer reproducible on FF release 61.0.2(20180807170231).
Flags: qe-verify+

(In reply to Robert Schultz from comment #0)

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://worldofsolitaires.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.

hey guys,
i already had this on my h4 in my CSS, so i get that you need to use position on it as i was using it!:

position:relative;z-index:100;so this edit didnt help…:
.producthome h4 {position:relative;z-index:100;}

ralphs edit did though! the top -50px worked :wink: thanks!!
what would one do if they want the img to centre horizontally and vertically?

Ps RE - IE8
by the way its not the RGBA value that i am trying to get working in IE8 -
i have already got that working ( you can use a conditional statement- look at my code at the top - do you see my header has an RGBA value and its transparent in IE8?
:wink:

You need to log in before you can comment on or make changes to this bug.