STR: - Load https://www.pangaeabern.ch/ Expected result: coffee cup is shown as background to the "Reservation" section. Actual result: Coffee cup is always shown in front until you've scrolled past the "Reservation" section. See attached screenshot. I can provide the GPU section of my about:support if required - I'm using a GTX 770 on Linux with the proprietary driver though.
Also broken on my Mac Book Pro (Retina, mid 2015), so shouldn't be only your graphic card/drivers.
OS: Linux → All
Hardware: x86_64 → Desktop
bad = just wait a bit and the coffee pic is shown over everything else mozregression --repo mozilla-inbound --good 2018-09-14 --bad 2018-09-16 --pref gfx.webrender.all:true -a https://www.pangaeabern.ch/ > 4:53.17 INFO: Last good revision: be6801cdeb537afa655bbd67d12ead8dc01c6c38 > 4:53.17 INFO: First bad revision: 302dcd8139426cfe25b9d2685800809c2d603658 > 4:53.17 INFO: Pushlog: > https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=be6801cdeb537afa655bbd67d12ead8dc01c6c38&tochange=302dcd8139426cfe25b9d2685800809c2d603658 > 302dcd813942 Andrew Osmond — Bug 1485420 - Part 2. Make ClipManager trim clip chains which can be merged with the display item. r=mstange > a3ea43b5e6d8 Andrew Osmond — Bug 1485420 - Part 1. Expose WebRender bindings to merge a clip rect with a display item. r=mstange
The image  appears even without scrolling down the page. It is stored inside a div with a transform, which in turn is inside a div with a fixed position. If I remove the transform or fixed position, it seems to correct the problem. Additionally, not applying the clip optimization to the image itself also appears to correct the problem. Investigation continues.  https://static.wixstatic.com/media/960d37e6303c48bca4481915762dec95.jpg/v1/fill/w_2722,h_1480,al_c,q_90,usm_0.66_1.00_0.01/960d37e6303c48bca4481915762dec95.jpg
Assignee: nobody → aosmond
(In reply to Andrew Osmond [:aosmond] from comment #3) > The image  appears even without scrolling down the page. It is stored > inside a div with a transform, which in turn is inside a div with a fixed > position. If I remove the transform or fixed position, it seems to correct > the problem. Additionally, not applying the clip optimization to the image > itself also appears to correct the problem. Investigation continues. Note that bug 1498873 fixes problems with fixed positioning inside transforms and similar stuff, not sure if it affects the page here though.
Emilio, I don't think it is related. I did apply your patch, but sadly it did not resolve the problem. Another data point: If I disable APZ, while still applying the optimization, the problem goes away.
(In reply to Andrew Osmond [:aosmond] from comment #5) > Emilio, I don't think it is related. I did apply your patch, but sadly it > did not resolve the problem. Gah, too bad, I guess it was worth a shot, since that patch fixes a few clipping-related assertions in DL code :)
It appears that if we have only one clip in the clip chain, and we separate out the leaf, I changed the behaviour such that it will no longer set a scroll ID in the new ItemClips object it is applying. Ensuring we do the same thing in that case fixes the problem. Patch forthcoming...
Status: NEW → ASSIGNED
If we remove the leaf of the clip chain and merge it with the clip rect of the display item, we only set a scroll ID if there was at least one more item in the clip chain. If there was not, it was left unset. Sometimes this results in the wrong scroll behaviour of an item, so if we remove the entire clip chain, we should still set the scroll ID for the ASR for the leaf.
I didn't build this into a reftest yet because my patch didn't fix what I thought would be a reduced test case (non-WR and Chrome render as expected).
(In reply to Andrew Osmond [:aosmond] from comment #10) > Created attachment 9019441 [details] > Reduced (related?) test case, v1 > > I didn't build this into a reftest yet because my patch didn't fix what I > thought would be a reduced test case (non-WR and Chrome render as expected). Seems to be the fixed element causing the problem.
status-firefox64: affected → disabled
status-firefox65: --- → affected
status-geckoview62: unaffected → ---
Turns out, the bug in my kind-of-reference test case is a regression from the summer: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d08944831e26fc9ec613e1fa2dc35d00332586ac&tochange=5b15326286d466b5cf4889160cc09b59bdde08fd https://github.com/servo/webrender/compare/3829687ffbe8d55885d71a3d5e5e79216251548f...8e697f8cb1f1aab2e5f6b9b903eb7191340b10c5
Created https://bugzilla.mozilla.org/show_bug.cgi?id=1503447 for the WR API inconsistency with regards to clip and scroll nodes, which is relevant to this issue.
Will follow up with this again once we finish the refactoring in bug 1503447. It will probably fix this problem implicitly.
This got fixed by bug 1503447.
Status: ASSIGNED → RESOLVED
Last Resolved: 4 months ago
No longer depends on: 1503447
Resolution: --- → DUPLICATE
Duplicate of bug: 1503447
Fixed in 65 in bug 1503447.
status-firefox65: affected → fixed
You need to log in before you can comment on or make changes to this bug.