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

NEW
Unassigned

Status

()

Core
Layout
3 years ago
3 months ago

People

(Reporter: rik, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(5 attachments)

(Reporter)

Description

3 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

3 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.
Posted to www-style: http://lists.w3.org/Archives/Public/www-style/2014Jul/0380.html

Comment 6

3 years ago
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

2 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

2 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

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

Updated

2 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

2 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

a year ago
position: absolute; bottom: 0; has the same bug.
Duplicate of this bug: 1331754
Duplicate of this bug: 1402184
You need to log in before you can comment on or make changes to this bug.