Content that overflows off the "start" side of a "flex-direction: *-reverse" flex container is not scrollable (but should be)

NEW
Unassigned

Status

()

5 years ago
25 days ago

People

(Reporter: rik, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(5 attachments)

(Reporter)

Description

5 years ago
Created attachment 8460329 [details]
flex-reverse-overflow-testcase.html

See attached testcase.

The two boxes are identical except the first one has a flex-direction: column, the second one column-reverse.
Version: unspecified → Trunk
Created attachment 8460341 [details]
comparison, demonstrating same issue w/ relative positioning

Hmm.

I think we have this behavior in general, where content that runs off the top of a "overflow:[non-visible]" element isn't reachable via scrolling.  Here's a testcase that demonstrates this with relative positioning.
Chrome reacts to Anthony's initial testcase here by putting the scrollbar all the way at the bottom, in the "column-reverse" example.  (So, scrollTop starts out at something nonzero.)

That seems like a reasonable behavior.

I'm looking for spec text on how this is supposed to work... It looks like the closest thing is this, which defines the scrollable area: 
 http://www.w3.org/TR/cssom-view/#scrolling-area

That definition relies on the "overflow directions", which are defined here: 
 http://www.w3.org/TR/cssom-view/#overflow-directions
...and which seem to be based on block flow direction & inline flow direction. (which aren't influenced by "flex-direction").

So per the letter of the spec,
 - the inline-flow & block-flow directions are still left to right, top to bottom
 - which means the "overflow directions" are rightward & downward
 - which means the top edge of the scrollable area is "The element's top padding edge." (that is -- the flex container's own top padding edge -- *not* anything dependent on its children)
 - which means we're correct in not allowing these children to be reachable via scrolling.

I think Chrome's behavior seems more useful, though... I'll bet flex containers *want* to establish their overflow directions as being the main-end & cross-end edges of the flex container. (instead of being dependent on block / inline direction)

I'll send a www-style post to ask about this later today.
(Also: FWIW, IE11 renders the initial testcase here the same way that we do.)
(Reporter)

Comment 4

5 years ago
If that can help with www-style discussions, we saw this bug with Jan when prototyping an IRC client. New messages would be inserted as the first children of #container.
FWIW, bug 962501 has a similar issue where adding `justify-content: flex-end` prevents any scrolling (in Chrome as well as in Firefox).

For context, Anthony suggested using `justify-content: flex-end` (and reversing the order of the elements in javascript) as a workaround for the present `flex-direction: column-reverse` scroll problem. It turns out we still can't scroll.
I was worried that might be the case, but then I tested locally and came up with something that worked (I thought).  I'll see if I can recreate that.
Created attachment 8461267 [details]
(mock-up IRC client that uses "flex-end" & doesn't need browser-support for overflow off the top of an element)

Yeah, you're right - justify-content:flex-end + overflow:auto don't quite work, on the same element.  But, we can make it work if we put "flex-end" on a flex-container that is the *parent* of the scrollable one. (so that the scrollable one still overflows off of its bottom & creates a scrollbar, and when it's too short to have any overflow, its parent snaps it to the bottom)  This demo has code to keep the scrollbar snapped to the bottom, too, taken from https://developer.mozilla.org/en-US/docs/Web/API/Element.scrollHeight. This makes it behave like my terminal & my IRC client on my desktop machine. 

Anyway, sorry for misleading you & Anthony (slightly) about "flex-end" & overflow yesterday, but hopefully with the wrapper, it does what we need.

Let's take any further IRC-client-discussion somewhere else (maybe the dev.tech.layout newsgroup), and keep this bug focused on the overflow behavior of flex-direction:column-reverse. (particularly after we hear back on www-style)
Attachment #8461267 - Attachment description: (demo IRC client that uses "flex-end" & doesn't rely on this) → (mock-up IRC client that uses "flex-end" & doesn't need browser-support for overflow off the top of an element)
dbaron suggests the might behavior might fall out naturally from nsLayoutUtils::GetScrolledRect, if we tweak that function to be aware of flexbox main/cross axes.
http://mxr.mozilla.org/mozilla-central/source/layout/base/nsLayoutUtils.h?rev=3a5cfc71b3d3#549
http://mxr.mozilla.org/mozilla-central/source/layout/base/nsLayoutUtils.cpp?rev=50623b494578#1805
*the right behavior
Comment on attachment 8461267 [details]
(mock-up IRC client that uses "flex-end" & doesn't need browser-support for overflow off the top of an element)

The attachment does seem to work around the issue, thanks!

>    .message {
>      border: 1px dotted purple;
>    }

This class probably needs `flex-shrink: 0` so that messages don't get squashed.
(In reply to Jan Keromnes [:janx] from comment #11)
> The attachment does seem to work around the issue, thanks!

hooray!

> This class probably needs `flex-shrink: 0` so that messages don't get
> squashed.

(I don't see any squashing here, but that may be font-size-dependent. Anyway, I agree that change would make sense in a real-world testcase. (or better: use "flex:none", which is functionally equivalent to flex-shrink:0; flex-basis: [unset]; flex-grow: [unset]; and is more human-readable.)
As noted in the "Overflow Issue" section of [1], there's a proposal to address this in the CSS-align spec[2].

[1] http://lists.w3.org/Archives/Public/www-style/2014Aug/0321.html
[2] http://dev.w3.org/csswg/css-align/#overflow-scroll-position
Duplicate of this bug: 1063967
(...and per http://lists.w3.org/Archives/Public/www-style/2014Sep/0187.html , the WG has now accepted the proposal.)

Comment 16

4 years ago
Is there any progress regarding this? The `justify-content` solution won't work if you resize the browser vertically; the messages don't stick to the bottom.
Not currently.

Comment 18

3 years ago
Created attachment 8680682 [details]
Another test case. Scroll position should not be changed here without user control.
Attachment #8680682 - Attachment filename: file_1042151.txt → file_1042151.html
Attachment #8680682 - Attachment mime type: text/plain → text/html

Updated

3 years ago
Attachment #8680682 - Attachment filename: file_1042151.html → file_1042151.txt

Updated

3 years ago
Attachment #8680682 - Attachment filename: file_1042151.txt → file_1042151.html
Duplicate of this bug: 962501
Broadening this bug's summary slightly, to include the scenario from bug 962501, since it's all basically the same issue, given the way this ended up being specced (per www-style post in comment 15).
Summary: flex-direction: column-reverse with overflow-y: auto is not scrollable → flex-direction: column-reverse (or "flex-direction:column; justify-content:flex-end") with overflow-y: auto is not scrollable

Comment 21

3 years ago
Created attachment 8700740 [details]
less-js test case

I think I've just run into this myself - if it helps, I've attached my repo case too; I was trying to use as little JS as possible, just detecting when you're at the bottom or not.

In particular, note that (column-reverse, flex-start) on the viewport does work in chrome, but not (column, flex-end). Neither work in FF unfortunately, the former seems to be due to this bug.
Duplicate of this bug: 1322236
Summary: flex-direction: column-reverse (or "flex-direction:column; justify-content:flex-end") with overflow-y: auto is not scrollable → Content that overflows off the "start" side of a "flex-direction: *-reverse" flex container is not scrollable (but should be)

Comment 23

2 years ago
position: absolute; bottom: 0; has the same bug.
Duplicate of this bug: 1331754
Duplicate of this bug: 1402184

Comment 26

4 months ago
Same problem here :
colum, row and row-reverse work correctly but not column-reverse
http://jsfiddle.net/qfe7ur1o/13/
Duplicate of this bug: 1495157

Comment 28

3 months ago
Hello,

Considering this bug-report has been sitting idle for a year and the general consensus is that the scrolling behavior of Chrome is the expected result, I was wondering if

Comment 29

3 months ago
there is any indication on whether this issue will be resolved in the near future.


(Apologies for the break between messages)
Component: Layout → Layout: Flexbox
It's not a top priority at the moment -- probably not destined to be resolved in the immediate future.
[tagging as a spec change around flexbox, though, per comment 15/comment 16, to be sure it's tracked alongside other such bugs]
Blocks: 1055888

Comment 32

3 months ago
Hi, I just wanted to add my +1 to this bug report. Here is an example of the chat window I am trying to build, which ideally should show the bottom messages by default, but allow the user to scroll to the top of the conversation. I am having difficulty finding non-javascript workarounds, and would appreciate any updates. https://codepen.io/beccanelson/pen/jeBwgW

Comment 33

3 months ago
Another +1 to this bug report. The entire use-case of `overflow-y: scroll` and `flex: column-reverse` seems to be to enable chat windows, and firefox's implementation doesn't allow that to happen.
Ran into this on nytimes.com today, at the "Live Updates from our Reporters" section on this page:
 https://www.nytimes.com/interactive/2018/11/06/us/elections/results-house-forecast.html

The .eln-cards element there has
  display: flex;
  overflow-x: scroll;
  flex-direction: row-reverse;
...with the ~tweet-sized "cards" overflowing off the left side of the container and being unscrollable (in Firefox) due to this bug.

Comment 35

2 months ago
Well, it seems like there are years now since this bug has been around, not sure whether this will ever be solved ... I am having the same issue I had 2 years ago, thought I'd just drop it.

Again, this behaviour seems to be the go-to for chat-like applications, where you don't have to programatically scroll the user's window downwards, all the time new content is added, or a simple image loads and extends it's own height.

Everytime content's height changes, it get's broken, and we need to somehow fix that from JS. Having this in place, does it automatically, and gets us rid of that issue.

Seems like Chrome is the only browser so far implementing this correctly, guess I'll just have to limit our users to using that instead.

Comment 36

25 days ago
@edi
you are right, Chrome is the only one who does it well.
It also works on Safari, but with a small issue with negative scroll offset value, but we can live with it.
That is a strange thing with FF, 5 years left and still not resolved..
You need to log in before you can comment on or make changes to this bug.