1686376 - Table elements suddenly disappear on scroll

Status: RESOLVED WORKSFORME

(Web Compatibility :: Site Reports, defect)

Description

[Karl Dubost💡 :karlcow]

Steps to reproduce

1. With Firefox Nightly 86 on Android
2. go to https://tplfvg.it/it/il-viaggio/costruisci-il-tuo-orario/?description=%2010&search-lines-by-description
3. wait for the page to load
4. scroll down to the orange bar "10 | CIRCOLARE DESTRA: Ospedale-Pla…"
5. Tap on the bar
6. A table of data appears
7. slightly scroll the table toward the top

Expected:
see the next rows of data

Actual:
Some sections of the table disappear

Note:
This seems to not reproduce on all devices. I have been able to reproduce on a pixel 2 device with a clean profile.

The performance profile illustrating what is happening. The loss of the table happens in between 7s and 8s on the timeline.
https://share.firefox.dev/2MYFXnU

Comment 1

[Timothy Nikkel (:tnikkel)]

The things that don't show up are position: sticky, that probably has something to do with it.

Comment 2

[Timothy Nikkel (:tnikkel)]

Seems to work fine if I disable webrender.

Comment 3

[Jamie Nicol [:jnicol] out of office until 6th Jan]

Mozregression gives this: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ae315341bc721084298fd39f6669bc47456a0fc5&tochange=83bf4fd3b1fbca9dcbe23de9d1a1503eed62569a

In which bug 1500644 seems most suspicious, but I would guess that means it's been an issue in Fenix for longer. It's at least a lead for where to start debugging this. Disabling the dynamic toolbar in Fenix might make it go away. (which might be why it only reproduces on some of your devices, Karl?)

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Comment 5

[Sotaro Ikeda [:sotaro]]

Attachment: temporal patch - Disable setting DynamicToolbarMaxHeight

With the patch, the problem was addressed. From it, enabling DynamicToolbar seemed to trigger the problem.

Comment 6

[Sotaro Ikeda [:sotaro]]

Attachment: reduced page

Created from the page. I still saw the problem around table header's rendering.

Comment 7

[Sotaro Ikeda [:sotaro]]

Attachment: video of symptom

Took a video by using Attachment 9200824 [details]. From it, rendering order of table header was changed during scrolling.

Comment 8

[Sotaro Ikeda [:sotaro]]

:gw, do you know if there is already a bug like comment 7? sticky element seems to be related.

Comment 9

[Glenn Watson [:gw]]

I'm not aware of any other bugs related to sticky elements, though it seems likely that's related based on the above comments.

Comment 10

[Hiroyuki Ikezoe (:hiro)]

Yeah, we have special handling if position: sticky elements' target scroll container is the root one when the dynamic toolbar is moving (since the lements need to get stuck on the root scroll container). I wonder whether this issue is in APZ or WebRender invalidation stuff.

Comment 11

[Chris Peterson [:cpeterson]]

I can still reproduce this bug in Fenix 100.

Comment 12

[Thomas Wisniewski [:twisniewski]]

This is a bug which feels likely to affect more than just this one site, but since it only affects Android and only certain devices, we'll set webcompat P2 priority for now.

Comment 13

[James Graham [:jgraham]]

Since we only have one report here, I'm going to move this into Web Compatibility :: Site Reports for now; we can clone it back into core if we manage to reproduce it.

Speaking of which, can anyone still reproduce this bug? :cpeterson you seem to have been the last to successfully reproduce it, does it still occur?

Comment 14

[Chris Peterson [:cpeterson]]

(In reply to Chris Peterson [:cpeterson] from comment #11)

I can still reproduce this bug in Fenix 100.

I can't reproduce this bug in Fx 124, so I'll resolve it as WORKSFORME.

Comment 15

[Hiroyuki Ikezoe (:hiro)]

Botond told me that bug 1854010 might fix this. It would be nice someone confirms it. :)