mozilla :: #layout

21 Apr 2017
14:02emiliobirtles: are you around?
14:04emiliobirtles: is my understanding right that pseudo-elements shouldn't arrive at http://searchfox.org/mozilla-central/source/layout/style/AnimationCollection.cpp#63?
14:05emiliobirtles: because I was debugging some stylo pseudo-element animation issues uncovered by my patch at bug 1355351, and they definitely arrive there :-(
14:05firebothttps://bugzil.la/1355351 NEW, nobody@mozilla.org pseudo-elements don't return the correct style via getComputedStyle.
14:06* emilio thinks that function should assert
18:22emiliobirtles: bug 1358570 was the most problematic there, but there's also the call when chrome code calls getComputedStyle directly on the pseudo-element, which ends up in UpdateAnimations.
18:22firebothttps://bugzil.la/1358570 NEW, emilio+bugs@crisal.io The PruneCompletedTransitions call in the frame constructor isn't looking at the right EffectSet.
18:48noxdholbert: Hello, you around? Do you remember why you added the comma-less webkit linear gradient there? http://searchfox.org/mozilla-central/source/layout/style/test/property_database.js#715
18:48dholbertnox: hi!
18:48dholbertlooking
18:49noxThis does not seem to be legal, according to the spec that should be used for https://compat.spec.whatwg.org/#css-gradients-webkit-linear-gradient
18:49dholbertnox: does it work in other browsers? that was my main source for what was legal & not
18:50noxOk.
18:50dholbertnox: hm, seems that it does not work!
18:50dholbertnox: comparing with-comma: data:text/html,<div style=&quot;background:-webkit-linear-gradient(0, red, blue)&quot;>Hi
18:50dholbertvs no-comma: data:text/html,<div style=&quot;background:-webkit-linear-gradient(0 red, blue)&quot;>Hi
18:50noxSo I don&#39;t need to support in Stylo, right?
18:50dholbertnox: so that&#39;s a bug I guess
18:50dholbertnox: correct
18:51noxThings I don&#39;t need to support are things I like, thank you for the quick answer.
18:51dholbertnox: sure! Thanks for the heads-up about that weirdness. /me filing a bug right now for gecko
18:52noxThanks for filing it.
19:20noxdholbert: Was a decision taken for the -moz gradients yet?
20:04dholbertnox: sorry, was at lunch
20:05dholbertnox: we want to unsupport them if we can
20:05dholbertnox: that is uncontroversial
20:05noxCool.
20:05dholbertnox: though we can&#39;t do that until my patches on those -webkit-linear-gradient / -webkit-gradient bugs land, to stop relying on -moz-linear-gradient for serialization
20:06dholbertnox: once those have landed, it should be as simple as a pref flip
20:06dholbertnox: (xidorn posted an intent to un-ship on dev-platform, too)
20:07dholbertnox: there&#39;s a small but nonzero chance that unshipping will break some sites, but we can be optimistic
21:37noxdholbert: In a color stop, does mLocation matter if mIsInterpolationHint is true?
21:38dholbertnox: I don&#39;t recall
21:39noxdholbert: Also, do you have any clue about https://github.com/nox/servo/blob/transition/components/style/gecko/conversions.rs#L291-L297?
21:41dholbertnox: currentColor does seem to work: data:text/html,<div style=&quot;color: lime; background: linear-gradient(currentColor, purple)&quot;>Hi
21:42dholbertnox: we presumably convert from the keyword to the nscolor in nsRuleNode
21:42dholbert(where we go from the specified-gradient representation to the computed-style gradient representation -- two different structs)
21:43dholbertnox: that currentColor handling happens via our call to &quot;SetColor&quot; here in nsRuleNode (for each color stop): https://dxr.mozilla.org/mozilla-central/source/layout/style/nsRuleNode.cpp#1313
21:43noxdholbert: Seems like the comment is wrong,
21:44noxIn our bindings at least now the mColor field is of type nsCSSValue.
21:44dholbertnox: nsRuleNode&#39;s SetColor function handles a bunch of special cases including currentColor, and produces a nscolor
21:44dholbertnox: that&#39;s what the field is in our specified-style gradients, too
21:44dholbertbut not in our computed-style gradients (in nsStyleStruct.*
21:44dholbert)
21:45noxOh I see.
21:45dholbertnox: the comment is indeed probably wrong. e_milio was probably looking at the computed-style gradient struct and noticed that it couldn&#39;t possibly store a special currentColor token
21:45dholbert(but that&#39;s because we convert it away when we produce that struct)
21:46noxI wonder if we handle currentColor correctly in other places or not.
21:46noxLooking at the bindings I don&#39;t see how to fix that right now.
21:46dholbertI think servo has code to populate nsStyleStruct.h&#39;s structs from specified style, right?
21:46dholbert*stylo
21:46dholbertI would expect it&#39;s in that conversion code
21:47dholbert(if it&#39;s there at all)
21:49dholbertnox: RE your original question about mInterpolationHint -- yes, it looks like its location still matters
21:50dholbertnox: I don&#39;t really know how that code works but it looks like stops with mInterpolationHint = true are really &quot;dummy&quot; color stops, which specify how far along the color-interpolation midpoint should be, between the two adjacent color stops
21:50dholbertsee https://drafts.csswg.org/css-images-4/#color-interpolation-hint
21:50dholbertand it looks like this was added in https://bugzilla.mozilla.org/show_bug.cgi?id=1074056
21:50firebotBug 1074056 FIXED, cabanier@adobe.com Add support for interpolation hints to CSS gradients
21:51noxdholbert: That&#39;s what I was thinking too, thanks for confirming.
21:51dholbert(And I don&#39;t really know more than that ^^ so your research is as good as mine if you have further questions on how they work. :))
21:51dholbertnox: sure
21:54dholbertnox: I just posted a patch on that -webkit-linear-gradient bug -- feel free to build on top of that if it&#39;s helpful
21:54dholbert(added a few more testcases, too)
21:54* dholbert brb
22:00noxdholbert: https://bugzilla.mozilla.org/show_bug.cgi?id=1358642 has been filed, so I don&#39;t understand anymore.
22:00firebotBug 1358642 NEW, nox@mozilla.com stylo: support -moz-linear-gradient
22:02dholbertnox: I&#39;ll add a comment
22:09noxdholbert: Cool.
23:00botondtnikkel: ping?
23:00tnikkelbotond: hi
23:00botondtnikkel: hey! do you know about XUL <listbox>?
23:05tnikkelmore than i want to admit
23:05botondtnikkel: excellent :)
23:05botondtnikkel: so, you know how it only scrolls by whole-line increments?
23:06botondtnikkel: i understand how that works for mouse-wheel events: it prevent-defaults the mouse-wheel event and scrolls itself
23:06botondtnikkel: i&#39;m wondering, how does it work during scrollbar dragging?
23:07tnikkelbotond: i actually dont know about that part of listbox. i fixed a bunch of sec bugs in the frame construction aspect of listbox back in the day
23:08botondtnikkel: i see
23:08botondtnikkel: do you know who would know about this?
23:08tnikkelbotond: i&#39;m guessing the blame for that code is very old, so the answer may be no one
23:10botondtnikkel: oh wonderful :p
23:11tnikkelbotond: that means you about to become the expert on this
23:12botondtnikkel: i think i actually discovered the answer
23:13botondtnikkel: <listbox> has its own nsIScrollbarMediator
23:13botondtnikkel: which overrides ThumbMoved() to scroll by whole-line increments
23:13botondtnikkel: nsSliderFrame calls that to perform the actual scrolling in response to dragging
23:19botondi guess a nice and simple way of dealing with this is that scroll frames with custom scrollbar mediator don&#39;t get async scrollbar dragging
23:24tnikkelseems reasonable
22 Apr 2017
No messages
   
Last message: 4 days and 53 minutes ago