mozilla :: #layout

17 Mar 2017
02:29heycamxidorn: looks like we use -moz-border-colors for at least some form control stuff, so needed in non-chrome documents too: http://searchfox.org/mozilla-central/source/layout/reftests/forms/progress/style.css#10
02:30xidornok...
22:55dholberttnikkel: question for you... so I'm working on a patch to let us process "overflow: hidden/scroll/auto" changes without doing frame reconstruction
22:56tnikkel*nod*
22:57dholberttnikkel: the thing I'm wondering right now is: for a scrollframe that *has already created scrollbars* (via CreateAnonymousContent), is it safe to just leave those scrollbars around if we e.g. change to "overflow:hidden" and just prevent them from being painted?
22:58dholberttnikkel: i.e. I'm wondering if I can treat scrollbars as lazily-constructed extra pieces of a nsHTMLScrollFrame (which stick around, once constructed, though they may or may not be painted if we change to "overflow-{x|y}: hidden")
22:58dholberttnikkel: does that sound sane/possible, and are there any obvious pitfalls you're aware of?
22:59dholbertbotond: (this ^^ might be a question for you, too)
23:00dholbertThis largely seems to Just Work right now, except I'm having trouble getting scrollbars to reliably stop painting on the root node when I change it from "overflow:auto" to "overflow:hidden". (It seems to work for an arbitrary div, though)
23:00tnikkeldholbert: it looks like thats how it currently works for the root scroll frame, according to CreateAnonymousContent
23:01dholberttnikkel: hmm. The root scroll frame is the only one that's giving me trouble right now. :D
23:01tnikkelhttps://dxr.mozilla.org/mozilla-central/source/layout/generic/nsGfxScrollFrame.cpp#4394
23:02dholbertheh, that comment is optimistic but incorrect :D
23:02dholbertdynamic changes to overflow styles do trigger frame reconstruction right now
23:03dholbert(though I suppose only to the frame that experiences the style change -- so potentially a [large] subtree of the root will get reconstructed, but not the root itself)
23:03dholbert(if e.g. "body.style.overflow" changes)
23:03tnikkeldholbert: yeah, my only point was that we construct the scrollbars for overflow hidden on the root
23:03dholberttnikkel: yup, gotcha
23:04tnikkeldholbert: are you testing with floating scrollbars or classic scrolblars?
23:04dholberttnikkel: classic I believe (not overlay)
23:05tnikkeldholbert: can i see your wip?
23:05* dholbert has "now watch me wip, wip, now watch me ne-ne" playing in his head now
23:05dholberttnikkel: one sec
23:07dholberttnikkel: https://pastebin.mozilla.org/8982384
23:07tnikkelhaha
23:08dholberttnikkel: the changes are: (1) refactor out a piece of nsCSSFrameConstructor::BeginBuildingScrollFrame() into a helper function called CreateScrollFrameNAC
23:08dholbert(2) Create a new change hint nsChangeHint_UpdateScrollFrame (and another one that I'm not using right now
23:08dholbert(3) send that change hint when "overflow-x|y" change, in nsStyleDisplay::CalcDifference
23:09dholbert(4) handle that change hint by calling this CreateScrollFrameNAC function for the corresponding scrollframe (which calls CreateAnonymousContent on the scrollframe)
23:09dholbert(5) Adjust the scrollframe CreateAnonymousContent function to gracefully avoid re-creating the same content if it already exists
23:12dholberttnikkel: and this successfully makes scrollbars appear/disappear on a div when I change it from "overflow:hidden" to "overflow:auto"
23:13dholbertbut does not work on <html> or <body> (and I&#39;ve already got a hack to target the correct scrollframe [I think] for those elements/frames)
23:14dholberttnikkel: anyway I probably just need to debug a bit more, and perhaps see if I can figure out how we avoid painting scrollbars on the root scrollframe when <body> is overflow:hidden -- assuming that actually works like the code-comment suggests that it does, that&#39;ll probably help me figure out how to co-opt the same codepath for my purposes
23:14dholberttnikkel: but any insights you have are appreciated :D
23:16tnikkeldholbert: it works for going to auto from hidden? but not the other way around? is that correct?
23:16dholberttnikkel: double checking (waiting for rebuild to complete)
23:17dholberttnikkel: &quot;auto to hidden&quot; does not work right now (the scrollbars stick around)
23:19dholberttnikkel: neither direction works (on html/body)
23:20tnikkeldholbert: ScrollFrameHelper::LayoutScrollbars is probably where the magic happens
23:20dholberttnikkel: thanks! I&#39;ll take a look at that
23:20tnikkeldholbert: the difference between aContentArea and mScrollPort is used to size the scrollbars
23:20tnikkelso if they are the same the scrollbars will be invisible
23:21dholberttnikkel: I&#39;m trying this with hidden<-->scroll too btw
23:21dholbertif that matters
23:21tnikkeloverlay scrollbars have a negative margin that gives them a non-zero size even when the content and scrollport are the same
23:21dholbert(similarly broken)
23:21dholbert(in case your suspicions are based on the idea that we might care about whether &quot;auto&quot; scrollbars should be hidden vs. shown)
23:22dholberttnikkel: I am a bad help-requester and I have to run in a couple of minutes
23:22dholberttnikkel: I will be looking more at this on Monday though
23:22tnikkeldholbert: okay. if the content area is correctly sized my guess is you need to update mHasVerticalScrollbar
23:22dholberttnikkel: ok
23:23dholberttnikkel: thanks for your help!
23:30tnikkelnp
23:33tnikkeldholbert: are you making sure a reflow happens?
23:33tnikkela reconstruction would cause one
23:33tnikkelbut i don&#39;t see anything that forces one in your new code
23:35tnikkeland if the root already has the scrollbar frames it wouldn&#39;t generate a reflow, creating the scrollbars on a non-root scrollframe could cause a reflow to happen
23:38dholberttnikkel: yeah, I&#39;m sending AllReflowHints in nsStyleDisplay::CalcDifference
23:39dholbertwhich should force one I think, tho... Maybe not for the root frame
23:40dholbert(Maybe I&#39;m just marking the body blockframe as needs-reflow and we don&#39;t sufficiently reflow the root frame)
23:40tnikkeldholbert: yeah, perhaps we need to mark the scrollframe itself as dirty and we aren&#39;t
23:41dholberttnikkel: good point. I&#39;ll look into that possibility
23:41dholberttnikkel: on a train now - will poke more at this on Mon
18 Mar 2017
No messages
   
Last message: 157 days and 17 hours ago