Open Bug 1615870 Opened 5 years ago Updated 2 years ago

Containers Cause Scrolling Issue with Slack Thread Right Sidebar

Categories

(Core :: Layout: Scrolling and Overflow, defect, P3)

73 Branch
defect

Tracking

()

People

(Reporter: ca.steve.foobar, Unassigned)

Details

Attachments

(3 files)

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

Steps to reproduce:

  1. Log into Slack.
  2. Start a thread or click on an existing thread.
  3. Type enough messages (or view enough existing messages) to cause the thread sidebar on the right side of the page to exceed the browser window size.

Actual results:

I noticed that I could not see the last message or the response box at the bottom of the scroll page in the thread sidebar on the right side of the page.

Expected results:

I should have been able to scroll to the bottom and see the last message, then type a response.

NOTE: When I logged into Slack WITHOUT the new slack login being inside a container and went to the same page, I was able to scroll fully as it should work.

Hi,

I am not able to replicate the issue. I've tried on: Windows 10 pro visiting https://slack.com/signin

On the following versions:
Release 73.0.1 (64-bit)
Beta 74.0b5 (64-bit)
Nightly 75.0a1 (2020-02-20) (64-bit)

Is the window fully maximized when following the STR mentioned above?

Please let me know what do you mean by the new slack login, would you mind attaching a picture of it?

Please try this on the latest version of nightly. You can download it from here: https://nightly.mozilla.org/

I will move this over to a component so developers can take a look over it. If is not the correct component please feel free to change it to an appropriate one.

Thanks for the report.

Best regards, Clara.

Component: Untriaged → Layout: Scrolling and Overflow
Flags: needinfo?(ca.steve.foobar)
Product: Firefox → Core

Hi Clara,

When it happened I did have the Firefox browser in full screen mode and as you can see in the screen shots I attached, it happened when I was in a container but did not happen when I wasn't in a container. Unfortunately, at this time I can't seem to reproduce it either. It may be an intermittent problem or it may be something I did then that I'm not doing now. I'm not sure but I'll just have to keep trying to reproduce it.

Thanks.

Flags: needinfo?(ca.steve.foobar)

I saw this happen again just now. Even though I had Slack launched in a "Default" container I saw the scrolling problem again (see new screen shots attached). I then removed the new Containers add-on from Firefox and refreshed the page and the problem went away. I have not gone back and forth with install/uninstall of the Container add-on to fully confirm all of this. I'm too busy right now but this may be a clue as to what's going on.

Thanks.

I was able to reproduce a similar problem. I do have Slack running in a container, but I don't know if that's related. My STR:

  1. Have Slack open in a non-fullscreen window.
  2. Open a long thread.
  3. Resize the window to be shorter, say half the original height of the window.
  4. Scroll to the bottom of the thread panel, and notice that you can't scroll to the very end.

This works as expected in Chrome.

One other difference I noticed with Chrome is that if the thread panel is scrolled to the very bottom when resizing the window, you can see that the thread panel is kept scrolled at the very bottom. (Visually, the "Reply..." box stays at the bottom of the window.) If you are scrolled to any other point in the thread panel before resizing the window, then the current scroll position stays where it is. In Firefox, the "keep the scroll position at the end if that's where you are" behavior doesn't happen.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3

I tried back to Firefox 61 and still got the same behavior. I couldn't go much further than that since Slack version blocks old Firefox. So if it's a regression, it's not a recent one.

Karl, is this something you would want to look into?

Flags: needinfo?(kdubost)

fwiw, this modifications fixes the issue.


/* client-boot-styles.e846326.css | https://a.slack-edge.com/bv1-8-8cacda2/client-boot-styles.e846326.css?cacheKey=gantry-1582936549 */

.p-threads_flexpane_container {
		overflow: scroll;
}

with a bit of jankiness at the start, they seem to want to control their own scrollbar on

<div data-qa="slack_kit_list" class="c-virtual_list__scroll_container" role="presentation" style="position: relative; height: 1610.9px;">
…
</div>

This contains all the individual messages of the thread.
In the ~8 millions characters js (~400,000 lines once prettified…, 7.62MB…), something is setting the class name

getContentsClassName() {
  return c() ('c-virtual_list__scroll_container', this.props.containerClassName, {
    'c-virtual_list__scroll_container--scrolling': this.isScrolling() && !this.isSelecting
  })
}

and removes it right away.

they keep the scrolling state and action into the object: this. React world.

Probably not a regression, but either a race issue, or a different way to handle the computations of everything.

The scrolling is working on first load, but definitely fails on resizing the window to be with a smaller height. Like if something was lost/not adjusted when doing that.

I would have published a profile, but that would include data which are private.
And not sure it helps more than just showing what is happening.

At this point maybe we could contact slack about it… because going through 400,000 lines of code…

or maybe someone has a clear idea of why this is happening.

Flags: needinfo?(kdubost)

Wonderful guys. I'm glad you were able to dig into this and it wasn't just me or my config! Slack is a heavily used app so I would think this would have some level of priority. We don't want people moving to Chrome (which is what I did) for specific issues like this. They may start to rethink coming back.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: