I found a regression bug on transitions.

AR: transition of background-color is broken on fixed elements

ER: it "fades" properly

Testcase:
https://jsfiddle.net/abqjf5vg/1/

note: outside the fiddle it works properly, probably the iframe also affects this. needs more investigation.

Last good: 2018-01-04
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b602b19745e33f26c196dc6fadb01ce9fa2b66a4&tochange=739484451a6399c7f156a0d960335606aa6c1221

First bad: 2018-01-05
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b602b19745e33f26c196dc6fadb01ce9fa2b66a4&tochange=2a4362ce2d9fa82f62909532a1b534d214761341

preferred blocker: Bug 1421507 (or Bug 1420928 )

This is a regression of Bug 1421507. I cannot reproduce this after reverting Bug 1421507.

Move the CSS transition component.

No idea for now. Looks like if we retrieve the nearest frame by SCROLLABLE_FIXEDPOS_FINDS_ROOT, this scrollableFrame doesn't have intersection with transformedRect, so IsFrameScrolledOutOfView returns true [1], and then we throttle the animation.

[1] https://searchfox.org/mozilla-central/rev/c21d6620d384dfb13ede6054015da05a6353b899/layout/generic/nsFrame.cpp#10489

This bug happens if the iframe is positioned on the bottom-right of the screen.

For example (by putting iframe.html and fix_pos.html in the same directory), the rect of scrollable parent frame is (0, 0, 18000, 9000) [1], which is the coordinate inside the iframe. The transformed rect is (25140, 25200, 6060, 6000) [1], which is the coordinate of the entire page, so there is no intersection if we use iframe. Either the fixed position frame is incorrect, or we use the incorrect way to get the transformed rect. Not sure for now.

Hiro, do you have any idea to fix the rect we get from nsLayoutUtils::TransformFrameRectToAncestor? Or the scrollable parent frame is not correct in this case? May need your feedback.

[1] The format of the rect is (x, y, width, height)

(In reply to Boris Chiou [:boris] from comment #6)

Hiro, do you have any idea to fix the rect we get from nsLayoutUtils::TransformFrameRectToAncestor?

Just checked the frame tree, and the |aTarget| and |scrollableParent| are all in the iframe (in the same frame tree). That's expected. However, looks like nsLayoutUtils::TransformFrameRectToAncestor will get the rect of its crossdoc parent frame, so we finally use the different coordinate system. :(

Maybe we have to add a flag to TransformFrameRectToAncestor to let it return the transformed rect in the same doc, instead of the cross doc.

Set P2 because this case is important based on modal views fade effect.

I think what I did in bug 1421507 was wrong. I think we need different mechanism for position:fixed elements. Given that the |scrollableParent| for the element in question is no an ancestor of the element's frame. Anyway, is this really P2 for us? If so, I will figure out the way for position:fixed elements. Thanks!

(In reply to Hiroyuki Ikezoe (:hiro) from comment #10)

Anyway, is this really P2 for us? If so, I will figure out the way for position:fixed elements. Thanks!

I marked this P2 because Robert said:

transition is simply broken on fixed elements, this sample is important based on modal views fade effect.`

Please feel free to mark this as P3 if the use case is rare.

Sean, could you please find someone to look into this for our 67 soft freeze (Mar 11)?

@hiro: Are you able to revisit this? And do you still think it is P2?

I am afraid I am not able to work on this in the near future. Downgrading to P3 since it been broken for a year.