The default bug view has changed. See this FAQ.

Removing an inline css transform on a table applies twice the resulting computed transform

RESOLVED FIXED in Firefox 19

Status

()

Core
Layout: View Rendering
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: glazou, Assigned: roc)

Tracking

({regression})

Trunk
mozilla20
x86
Mac OS X
regression
Points:
---

Firefox Tracking Flags

(firefox17 unaffected, firefox18 unaffected, firefox19+ verified, firefox20+ fixed)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

4 years ago
Created attachment 686503 [details]
test case showing issue

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...
Component: Style System (CSS) → Layout: View Rendering

Comment 2

4 years ago
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.

Comment 3

4 years ago
(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.
Keywords: regression, regressionwindow-wanted
Yeah, regression range on nightlies includes bug 691651.
Blocks: 691651
status-firefox17: --- → unaffected
status-firefox18: --- → unaffected
tracking-firefox19: --- → ?
tracking-firefox20: --- → ?
Keywords: regressionwindow-wanted
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.)
status-firefox19: --- → affected
status-firefox20: --- → affected
tracking-firefox19: ? → +
tracking-firefox20: ? → +
(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;
Assignee: nobody → roc
Created attachment 687622 [details] [diff] [review]
fix

Instead of removing the MAY_BE_TRANSFORMED bit in certain frame classes, add an nsIFrame::SupportsCSSTransforms method and call it when necessary.
Attachment #687622 - Flags: review?(matspal)
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
Created attachment 688097 [details] [diff] [review]
fix v2
Attachment #687622 - Attachment is obsolete: true
Attachment #687622 - Flags: review?(matspal)
Attachment #688097 - Flags: review?(matspal)

Updated

4 years ago
Attachment #688097 - Attachment is patch: true

Updated

4 years ago
Attachment #688097 - Flags: review?(matspal) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/bd4859261347
https://hg.mozilla.org/mozilla-central/rev/bd4859261347
Status: NEW → RESOLVED
Last Resolved: 4 years ago
status-firefox20: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
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
Attachment #688097 - Flags: approval-mozilla-aurora?
Comment on attachment 688097 [details] [diff] [review]
fix v2

agree that this is low-risk enough for aurora, approving.
Attachment #688097 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
https://hg.mozilla.org/releases/mozilla-aurora/rev/2d1c8ffeeeaa
status-firefox19: affected → fixed
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
status-firefox19: fixed → verified
QA Contact: cornel.ionce
You need to log in before you can comment on or make changes to this bug.