1458665 - Slack's red line delineating unread messages jumps around instead of scrolling smoothly

Status: RESOLVED DUPLICATE of bug 1464568

(Core :: Layout, defect)

Description

[Chris Peterson [:cpeterson]]

I'm seeing a Slack scrolling glitch in Firefox Nightly. When I switch to a Slack channel with unread messages, there is a red line delineating read and unread messages. When I then scroll the message frame, the red line jumps around instead of scrolling smoothly. Once the red line scrolls out of and back into view, it will then scroll smoothly instead of jumping.

I think this is a recent regression in Nightly 61, but the bug is hard to reproduce because it depends on someone else sending new unread messages to a channel.

I joined the Mozilla Slack's #random channel, hoping to receive enough unread messages to bisect the bug in a reasonable time. But even #random is not active enough for bisect the bug in a practical way. Is there an even more active channel, maybe on a different Slack server?

Comment 1

[Chris Peterson [:cpeterson]]

Karl, I *think* this Slack bug might be a regression from CycleCollectedJSContext bug 1455210. I bisected the regression range using mozregression, but I'm not very confident in this regression range because I might not have been testing the right STR. Here are the correct STR:

STR:
1. Switch to a quiet channel.
2. Wait for a chatty channel's name to be highlighted when it has an unread messages.
3. Switch to the unread channel.
4. Slowly scroll the red line up and down, but do not let it scroll out of view.

RESULT:
The red line jumps up and down instead of scrolling smoothly.

If you in the chatty channel when new unread messages arrive, Slack still shows the red line but it will scroll smoothly. The key is that you must switch to the chatty channel *after* the unread messages arrive for the red line to jump up and down.

Comment 2

[Karl Tomlinson (:karlt)]

Hmmm.  Changes for bug 1455210 were confined to worker threads.
The changes that weren't confined to debugging worker threads were just the removal of null checks, and so any errors in assumptions would lead to crashes.

Comment 3

[Chris Peterson [:cpeterson]]

I've tried to bisect this bug a few times now, but have a hard to reproducing reliably. I sometimes only see the jumpy red line on the second unread message in a browser session.

The earliest Nightly where I have definitely reproduced the bug is 2018-04-24 and the earliest changeset is b63e4bff951e97ce23e5673cb55a990a1bbb1a3c (bug 1455210 again). But it is possible there are earlier affected builds and I was just not able to reliably reproduce the problem.

Comment 4

[Chris Peterson [:cpeterson]]

I've tried to bisect this bug about five times and three times I landed on the same pushlog with CycleCollectedJSContext bug 1455210. If anyone else wants to try bisecting this bug, I can help.

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b63e4bff951e97ce23e5673cb55a990a1bbb1a3c&tochange=eb34acceb9dcba6faff9eee5e8c9183755ddd37a

Comment 5

[Chris Peterson [:cpeterson]]

I can reproduce this bug on both Windows and macOS.

Comment 6

[Chris Peterson [:cpeterson]]

Hmm. I am no longer able to reproduce this problem. I don't know if Firefox changed or the site changed. I'm going to close this bug WORKSFORME for now.

Comment 7

[Chris Peterson [:cpeterson]]

Reopening because I can reproduce this bug again, though only about 50% of the time instead of 90+%.

Comment 8

[Mike Taylor [:miketaylr]]

Hi Brindusa, could you help find reliable STR? Thanks!

Comment 9

[Brindusa Tot, Desktop QA]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0

I can easily reproduce this issue on latest Nightly 62.0a1, build ID 20180520220103, with the steps provided by Chris in comment 1:

Steps to reproduce:
1. Switch to a quiet channel.
2. Wait for a chatty channel's name to be highlighted when it has few unread messages.
3. Switch to the unread channel.
4. Slowly scroll the red line up and down, but do not let it scroll out of view.

RESULT:
The red line jumps up and down instead of scrolling smoothly.

Comment 10

[Hani Yacoub, Desktop QA]

I did a regression range on Windows 10 x64 and here is the regression window:

Last good revision: c4027f932a5276de4d704103e0d0f0361b94d61a
First bad revision: 26b85ad253292610b73779c14549ba5674b898bc
Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=c4027f932a5276de4d704103e0d0f0361b94d61a&tochange=26b85ad253292610b73779c14549ba5674b898bc

Comment 11

[Chris Peterson [:cpeterson]]

Emilio, Hani suspects your fix for SVG text bug 1421807 might have caused this Slack regression. Do you think it could be the cause?

I tried to bisect this regression before. I think my bisection was wrong because the bug is tricky to reproduce. I landed on a different changeset from the same date Hani did, though, which suggests we are close to the true regression range.

Comment 12

[Emilio Cobos Álvarez (:emilio)]

Sounds highly unlikely, since that patch only prevents us from creating svg frames in shadow DOM / XBL / display: contents to avoid crashes.

The first is still disabled on nightly by default, and the second is not accessible to content.

Comment 13

[Cameron McCormack (:heycam)]

I still see this sometimes.

Another thing I see which may be the same bug is on MozReview, where the animated spinners for loading parts of a patch jump around when I scroll the page.

Comment 14

[Cameron McCormack (:heycam)]

(In reply to Cameron McCormack (:heycam) from comment #13)
> I still see this sometimes.

This was with a few day old Nightly.

I'm told this bug is now fixed by 1464568, so marking this a dupe of that one.