http://www.afr.com/ displays differently in nightly based on stylo being toggled on or off. When toggled on the main.main element is styled with NaN dimensions. In a debug build this results in hitting an assert (see attached stack trace).

Rank #243 in Australia.

Thanks for pinpointing the issue, Bryce. The specified value of main.main's transform is rotate3d(0, 0, 0, 0), and the conversion to a computed value here: http://searchfox.org/mozilla-central/rev/bd39b6170f04afeefc751a23bb04e18bbd10352b/servo/components/style/properties/longhand/box.mako.rs#1414-1421 is dividing by zero. Boris I think you were looking at 3D transforms at one point, do you want to look at fixing this?

(In reply to Cameron McCormack (:heycam) from comment #2) > Thanks for pinpointing the issue, Bryce. > > The specified value of main.main's transform is rotate3d(0, 0, 0, 0), and > the conversion to a computed value here: > > > http://searchfox.org/mozilla-central/rev/ > bd39b6170f04afeefc751a23bb04e18bbd10352b/servo/components/style/properties/ > longhand/box.mako.rs#1414-1421 > > is dividing by zero. Boris I think you were looking at 3D transforms at one > point, do you want to look at fixing this? OK. Interesting, it uses (0,0,0) as the direction vector.

(In reply to Boris Chiou [:boris] from comment #3) > OK. Interesting, it uses (0,0,0) as the direction vector. s/direction/rotate axis/

Comment on attachment 8894823 [details] Bug 1388216 - Don't apply the rotation if it cannot be normalized. https://reviewboard.mozilla.org/r/165950/#review171106 ::: servo/components/style/properties/longhand/box.mako.rs:1420 (Diff revision 1) > - result.push(computed_value::ComputedOperation::Rotate(ax / len, ay / len, az / len, theta)); > + // https://www.w3.org/TR/css-transforms-1/#funcdef-rotate3d > + // Spec: A direction vector that cannot be normalized, such as [0,0,0], > + // will cause the rotation to not be applied. Therefore, we don't push this > + // transform operation into the result. > + if len > 0. { Yeah, I think it's wrong that Servo is doing the normalization here, since the spec says that the computed value of transform should just be the specified value with units made absolute. (Although Gecko and other browsers just return a matrix() or matrix3d() from getComputedStyle, so I'm not sure how accurate the spec is.) So do you think it could make sense to just append the value without normalizing here? Then Gecko should still skip this item in ProcessRotate3D.

Comment on attachment 8894824 [details] Bug 1388216 - Add a rotate3d whose direction vector cannot be normalized into property_database.js. https://reviewboard.mozilla.org/r/165980/#review171108

Comment on attachment 8894823 [details] Bug 1388216 - Don't apply the rotation if it cannot be normalized. https://reviewboard.mozilla.org/r/165950/#review171106 > Yeah, I think it's wrong that Servo is doing the normalization here, since the spec says that the computed value of transform should just be the specified value with units made absolute. > > (Although Gecko and other browsers just return a matrix() or matrix3d() from getComputedStyle, so I'm not sure how accurate the spec is.) > > So do you think it could make sense to just append the value without normalizing here? Then Gecko should still skip this item in ProcessRotate3D. Yes. It makes sense and the behavior would be much closer to that in Gecko. I will update this. Thanks.

Comment on attachment 8894823 [details] Bug 1388216 - Don't apply the rotation if it cannot be normalized. https://reviewboard.mozilla.org/r/165950/#review171512 Looks good, thanks.

Pushed by bchiou@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/8b04b798e6b2 Add a rotate3d whose direction vector cannot be normalized into property_database.js. r=heycam

(In reply to Boris Chiou [:boris] from comment #14) > Created attachment 8895200 [details] > Servo PR, #18016 Seen fixed in Nightly 57 x64 20170810100255 @ Debian Testing. It's no longer white where you would expect the site's main content (a list of articles). Broken in Nightly 57 x64 20170808114032 @ Windows 7, but fixed in Nightly 57 x64 20170809100326 @ Windows 7.

Too late for 56. Mass won't fix for 56.