A HTML table is rotated through 'transform: rotate(22deg)'. A script then applies the inline style 'transform: none', flushes the layout changes and removes the inline style. See attached test case. Steps to reproduce 1. load attached test case 2. click on first link, inline 'transform: none' is applied 3. click on second link, the above is removed Expected result: table is rotated 22 degrees. Actual result : table is rotated 44 degrees... As far as I can tell, this happens only for tables.

My money is on us managing to apply the transform on both the inner and outer table somehow...

Either I don't get it or it works for me on 16.0.1 - after the second click the table is in the same position than the original (and reference) position.

(and it is the same WFM on 17.0 - I had a doubt and upgraded just now. I'm on Windows 7)

Yep. It works in 16 and 17, but not a nightly. (On another note, if you're really using 16.0.1 you need to update ASAP: you're two security updates behind.) I'll bet money this regressed with bug 691651.

Yeah, regression range on nightlies includes bug 691651.

The ::-moz-table-outer { -moz-transform: inherit } rule in ua.css is almost certainly related. I checked that nsChangeHint_AddOrRemoveTransform was added to nsChangeHint_Hints_NotHandledForDescendants and NS_HintsNotHandledForDescendantsIn correctly; it looks to me like it was. So I don't see anything immediately.

I do wonder what makes us not apply the transform to the inner table. (Or perhaps what used to but doesn't anymore.)

(In reply to David Baron [:dbaron] from comment #7) > I do wonder what makes us not apply the transform to the inner table. (Or > perhaps what used to but doesn't anymore.) This, in nsTableFrame.cpp: // Transforms need to affect the outer frame, not the inner frame (bug 722777) mState &= ~NS_FRAME_MAY_BE_TRANSFORMED;

Instead of removing the MAY_BE_TRANSFORMED bit in certain frame classes, add an nsIFrame::SupportsCSSTransforms method and call it when necessary.

Comment on attachment 687622 [details] [diff] [review] fix Since we have IsFrameOfType for this sort of thing - why not IsFrameOfType(eSupportsCSSTransforms) instead of SupportsCSSTransforms() ? This comment needs updating? http://mxr.mozilla.org/mozilla-central/source/layout/base/nsCSSFrameConstructor.cpp#7791

Comment on attachment 688097 [details] [diff] [review] fix v2 [Approval Request Comment] Bug caused by (feature/regressing bug #): 691651 User impact if declined: Possibly broken rendering on a small number of pages Testing completed (on m-c, etc.): just landed on m-c Risk to taking this patch (and alternatives if risky): Seems relatively low-risk for Aurora String or UUID changes made by this patch: None

Comment on attachment 688097 [details] [diff] [review] fix v2 agree that this is low-risk enough for aurora, approving.

Verified fixed on Firefox 19 beta 6 User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20100101 Firefox/19.0 Build ID: 20130212082553