1661316 - "Add to cart" button disappears on hover on gog.com

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Ksenia Berezina [:ksenia]]

Attachment: 91282215-b9b2d300-e791-11ea-829f-bd05d9ee6bcb.gif

This was originally reported in https://github.com/webcompat/web-bugs/issues/57125

STR:

1. Open https://www.gog.com/
2. In the slider hover on "Browse" or "Add to cart" button and observe the behaviour

Expected:
Button stays

Actual:
Button disappears

In addition, certain elements on the slides flicker after slider change (to reproduce click on arrows or on the slider control below)

From mozregression:

14:23.58 INFO: Last good revision: 5786eef0515a77d3fe7656c5bb1a7a5def4e0ab9
14:23.58 INFO: First bad revision: d67ac396d0f9d67c092672fcac1998edbbd07aed
14:23.58 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5786eef0515a77d3fe7656c5bb1a7a5def4e0ab9&tochange=d67ac396d0f9d67c092672fcac1998edbbd07aed```

Comment 1

[Ksenia Berezina [:ksenia]]

Hiro, would you be able too look into this?

Comment 2

[Alice0775 White]

reproduced on Nightly82.0a1 Windows10.

Comment 3

[Hiroyuki Ikezoe (:hiro)]

Looks like pretty much similar to bug 1659496, which means there is a pre-existing issue somewhere.

Comment 4

[Hiroyuki Ikezoe (:hiro)]

This is not a regression caused by bug 1656418. It's been a long standing issue. That said, this issue should block shipping partial pre-render feature (bug 1656473).

I did mozregression with layout.animation.prerender.partial:true. The range is;

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1f91961bb79ad06fd4caef9e5dfd546afd5bf42c&tochange=c616a6fd5e4b20cca139fcdd3957682afaa862b9

CCing Miko, I am almost 100% sure this issue is same as bug 1659496.

Comment 5

[Hiroyuki Ikezoe (:hiro)]

Forgot CCing to Miko. :)

Comment 6

[Alice0775 White]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #4)

I did mozregression with layout.animation.prerender.partial:true. The range is;

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1f91961bb79ad06fd4caef9e5dfd546afd5bf42c&tochange=c616a6fd5e4b20cca139fcdd3957682afaa862b9

Yes, I got
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=7fb001f811d183095e9cfdd958c9215484377396&tochange=d5e1ed773fefe2eb9d52402dd74b5fea19b8b4a4

Comment 7

[Jonathan Kew [:jfkthame]]

Marking as S2 (same as bug 1659496) for now, but maybe this can just be dup'd to the earlier bug?

Comment 8

[Hiroyuki Ikezoe (:hiro)]

Attachment: A reduced test case

Comment 9

[Hiroyuki Ikezoe (:hiro)]

Attachment: More reduced case

Comment 10

[Hiroyuki Ikezoe (:hiro)]

Comment on attachment 9172905 [details]
More reduced case

>.big-spots-wrapper {
> width:410vw;

This width value depends on environments, should be bigger, say 800vw.

Comment 11

[Hiroyuki Ikezoe (:hiro)]

As I wrote in bug 1659227 comment 17, using visibleRect fixes this issue.

Comment 12

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1661316 - Use `visibleRect` for partial pre-render check instead of `dirtyRect`. r?mattwoodrow

With RDL the dirty rect might be empty if the target transformed frame is
marked as mForceDescendIntoIfVisible.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/297fb1f347b0
Use `visibleRect` for partial pre-render check instead of `dirtyRect`. r=mattwoodrow

Comment 14

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/297fb1f347b0