1661595 - Section of page disappears after scrolling into view

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Sam Johnson]

Attachment: Screen Recording 2020-08-27 at 5.55.49 PM.mov

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:82.0) Gecko/20100101 Firefox/82.0

Steps to reproduce:

1. Visit https://developer.mypurecloud.com/forum/t/problem-with-the-transcription-of-an-interaction/8507
2. Scroll down so the comments section is visible.

Actual results:

Moments after the comments section is visible within the viewport, the entire section disappears. See attached screen recording showing this behavior.

Expected results:

The comments section should not disappear when it is scrolled into view. The correct behavior is observed in Chrome and Safari.

Comment 1

[Sam Johnson]

Attachment: about:support

A few items of note:

• This happens regardless of whether WebRender is enabled.
• This happens regardless of whether desktop zooming is enabled.

Comment 2

[Sam Johnson]

I tried running a mozregression and found the issue occurs as far back as the oldest build that runs on this machine (which was a build from 2016), so this is not a recent regression.

I did notice that the comment(s) that disappear depends on window size. At some sizes, both comments disappear. At other sizes, only the first one disappears. At other sizes, only the second one disappears.

Comment 3

[Alice0775 White]

I can reproduce the issue on Nightly82.0a1 Windows10.

Comment 4

[Jonathan Kew [:jfkthame]]

I'm not sure this is a Layout issue; it seems to be something the site is doing with JS, whereby it is dynamically changing the page when the comments are scrolled into view, and removing content(!)

Inspecting the area where the "missing" comment was, I see just an empty <div> with the (rather curious) class="cloaked-post" and an explicit min-height so that it still takes up space.

I don't know what the site is really trying to do here.... it seems kinda broken.

Comment 5

[Boris Chiou [:boris]]

So this could be a dom issue. Not sure. Perhaps cc more people, and mark as S3 for now.

Comment 6

[Boris Chiou [:boris]]

Change to S2 for now because this seems a data loss.

Comment 7

[Sean Voisen (:svoisen)]

Confirming that the site is doing something differently via JS in Firefox vs. Chrome as mentioned in comment 4. In Firefox it is hiding the comments as cloaked-post but not applying the same logic for some reason in Chrome. My guess is there is a compat issue with IntersectionObserver usage, as they are probably applying some logic based on viewport intersection.

Maybe someone on the webcompat team has a better way of simplifying this?

Comment 8

[Daniel Holbert [:dholbert]]

Yeah, this needs some arcane reverse-engineering to figure out what the site's trying to do and why it's behaving differently. :-/ I took a look in a debugger for a bit, and learned the following:

• UA spoofing doesn't seem to make a difference, so this isn't UA sniffing (thank goodness, kind of).
• the function e.cloak = function (e, t) {...} in this JS file is the relevant JS function here (it results in adding cloaked-post to the element in question, via a few subsequent steps)
• In Chrome, that function is simply never called.
• There is also a preventCloak function, which I initially suspected as being involved, but AFAICT that's never called in Chrome (or Firefox) either.
• In Firefox, cloak is called via what looks like an onscroll handler -- a function called scrolled that chains off an object. Its definition starts out as scrolled:function(){var i=this;if(!this.isDestroyed&&!this.isDestroying&&!(0,H.isWorkaroundActive)()) and it's defined in that same JS file. (It contains some JS that does return (0, q.cloak) (e, i) which is what triggers the cloak() call.) In Chrome, this scrolled function is never invoked for some reason.

Comment 9

[Daniel Holbert [:dholbert]]

Unfortunately, the callstack above scrolled is 11 stack-frames of JQuery stuff, and I'm not familiar with debugging JS/JQuery code really, so I'm hoping maybe twisniewski or someone on the webcompat team who's got more experience with arcane JS debugging can take a look. :)

Comment 10

[Sean Voisen (:svoisen)]

It's maybe possible that bug 1665447 will help with or fix this.

Comment 11

[Sam Johnson]

Thanks for pointing that out! Unfortunately, I'm still seeing the issue on today's Nightly, which I believe has the patch from bug 1665447 included.

Comment 12

[Sean Voisen (:svoisen)]

I'm no longer able to reproduce this in Nightly 84. Would you mind testing again to see if it still reproduces for you with the latest Nightly?

Comment 13

[Sam Johnson]

It looks like the page has changed and no longer exhibits this issue.