Closed Bug 962501 Opened 7 years ago Closed 7 years ago
when justify-content: flex-end, overflow auto
. when content overflows scrollbars dont show
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release) Build ID: 20131205075310 Steps to reproduce: when div is display flex, column direction, with justify-content: flex-end, overflow auto. then you insert sub divs with flex-shrink:0, insert until content taken up, scroll bars do not show please see test case Actual results: vertical scrollbar dont show Expected results: vertical scrollbar should show
oh the expected results should be: vertical scrollbar should show AND: scrollbar should be at bottom most. like when flex-start, or in normal cases, the scrollbar starts at top most, when flex-end it should be bottom most.
Component: Untriaged → Layout
OS: Windows XP → All
Product: Firefox → Core
Hardware: x86 → All
Version: 26 Branch → Trunk
It looks to me like this is just a special case of a more general problem: "Content that overflows off the *top* of a scrollable area isn't scrollable" which I think might be by-design.
For example: compare this data URL data:text/html,<div style="overflow: scroll; height: 100px; width: 400px"><div style="position: relative; top: 100px">Can you reach me? ...to this data URL: data:text/html,<div style="overflow: scroll; height: 100px; width: 400px"><div style="position: relative; top: -50px">Can you reach me? The latter one, the "Do you see me" text isn't scrollable, because it's pushed off the top of the scrollport, and the default scrollposition is 0, and we can't scroll below 0.
Both the original testcase and the data URLs from comment 3 (the latter one in particular, with the negative "top" making things unreachable) render the same in Firefox, Chrome, and Opera (Presto), so I think this behavior is interoperable. Also, it looks like the more general problem here is covered by bug 172955, which is a dupe of bug 6976. Marking this a duplicate as well. See in particular bug 6976 comment 117.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 6976
thanks daniel for the replies. when those dupe bugs get fixed would that fix this as well? im having a hard time working around it :( can you please help me: i posted the full details here: http://forums.mozillazine.org/viewtopic.php?p=13319765#p13319765 i noticed that if i add content (call this content "content a" and scroll the div way down, then reload the page, the scroll bar stays at the bottom as i add "content b" UNTIL "content b" exceeds the height of "content a". i think this is something to do with a property that is saved on the scroll bar to make the scroll bar appear in same position, do you know what this property is? so i can do the same thing except in run time, without need for reload, (im making an addon and this is an addon page so i can get into the xbl and stuff)
(In reply to noitidart from comment #5) > thanks daniel for the replies. when those dupe bugs get fixed would that fix > this as well? im having a hard time working around it :( Unfortunately, the dupe bug is "WONTFIX", which means it won't be fixed (in part because fixing it would break existing web content). As noted in comment 2, I think this is by design. > i noticed that if i add content (call this content "content a" and scroll > the div way down, then reload the page, the scroll bar stays at the bottom > as i add "content b" UNTIL "content b" exceeds the height of "content a". i > think this is something to do with a property that is saved on the scroll > bar to make the scroll bar appear in same position, do you know what this > property is? so i can do the same thing except in run time, without need for > reload, (im making an addon and this is an addon page so i can get into the > xbl and stuff) Is the "scrollTop" property what you're looking for? https://developer.mozilla.org/en-US/docs/Web/API/Element.scrollTop e.g. this data URL will scroll its scrollable div to position 500px when the document loads: data:text/html,<!DOCTYPE html><div id="scroll" style="height: 100px; overflow: scroll"><div style="height: 1000px"></div></div><script>document.getElementById("scroll").scrollTop = 500</script>
much thanks but scrollTop isn't it. if we see the scrollTop property before reload and after it is reset to 0. and we can't "over-set" scrollTop. even if scrollTop is set to some huge number like 5 million, as soon as content is added, new content is at bottom and scrollbar says there, so now there is a gap and we have to scroll down to see new content. theres some property i cant find, that we can "over-set" and whenever new content is inserted, the scroll bar tries to go for it, and sets itself to the max possible until the max possible equals that value. please help me find that value i scoured mxr but so many results i cant narrow it down :(
Sorry, I don't really work on the scrolling code, so I can't really help you. (a bug page also isn't really the right forum for this kind of discussion - you might try stackoverflow, or maybe someone on that mozillazine thread can help)
(The only thing I can think of would be re-setting scrollTop to 5 million or whatever, immediately *after each time* dynamic content is inserted. (so, forcibly snapping the scrollbar back to its most extreme lower position) You seem to be asking for a way to request that the scrollbar auto-scroll-down such that it will *stay* snapped to the bottom, even as new content is added to make the scrollable region taller. I don't know of a way to do that. Which isn't to say that it's impossible; I just don't know of a way.)
ah yeah thanks very much for help even though its bug topic. yep thats what im trying to do, keep it snapped. the problem with setting it to the bottom for me though is: my content that gets added is a css transition, the height goes from 0 to 100%, so i have to wait for after animation completes. and if i do that then user cant see cool animation haha. ill keep digging, its definitely some property, im thinking its in xbl though i looked deep. thanks again daniel!
or unless do you know of a css transition that scrolls the page? that would be perfect!
(In reply to noitidart from comment #11) > or unless do you know of a css transition that scrolls the page? that would > be perfect! (Not directly. CSS transitions only work on CSS properties, and there is no "page scroll position" CSS property. You can transition other things that indirectly affect the scroll position, like an element's "height" property, but I don't think that's what you're getting at.)
ah ok no problem. thanks again daniel! :)
Added a test case (one-line change from bug 1042151's test case) clearly showing the problem with and without `justify-content: flex-end`. Also, I'm not really sure how this is a duplicate of the generic scrollbar bug 6976 from 15 years ago.
(In reply to Jan Keromnes [:janx] from comment #14) > Also, I'm not really sure how this is a duplicate of the generic scrollbar > bug 6976 from 15 years ago. See comment 2 and comment 4 here. (Bug 1042151 is a bit different, since (depending on how the www-style discussion turns out) the main-end edge of the flex container (the top, in a "column-reverse" flex container) may end up being specced as "the overflow direction", in which case overflow on that side *should* trigger scrollbars [and we'll need some implementation work to support things triggering overflow on the top]. However, in this bug here (with "flex-direction:column;justify-content:flex-end"), we aren't flipping the axes, so it's less clear that the overflow edge should be the top. Maybe the www-style post will turn out that way, though; in that case, this should be reopened.)
This came up for me in a layout I was trying to do... http://codepen.io/chriscoyier/pen/obNNRa (Imagine a "chat" layout where you type in a bar along the bottom, new lines are added directly above it fixed to the bottom. It would be nice if it could scroll, but it can't.)
I'm duping forward to Bug 1042151, instead of the old bug 6976, since the spec situation (hinted at in comment 15) ended up being resolved such that this bug & bug 1042151 are basically the same issue. See https://lists.w3.org/Archives/Public/www-style/2014Sep/0187.html and the spec link there for more.
Duplicate of bug: 1042151
You need to log in before you can comment on or make changes to this bug.