Tables with 'transform' property set don't act as abs-pos/fixed-pos containers

RESOLVED FIXED in mozilla13

Status

()

Core
Layout: Tables
--
minor
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: ayg, Assigned: ayg)

Tracking

Trunk
mozilla13
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Simple test-case:

data:text/html,<!doctype html>
<div style="display:table;-moz-transform:scale(1);
width:100px;height:100px">
<div style="position:absolute;right:0">Hello
</div></div>

In Firefox 12.0a1 (2012-1-24), "Hello" is all the way at the right of the viewport.  In IE9, Chrome 17 dev, and Opera Next 12.00 alpha, it's at the right of the 100px-table.  The spec says anything with a transform other than 'none' has to be a container for absolute and fixed positioning.  This is mentioned in bug 435293 comment 34 but apparently was never fully fixed.

Bug 320865 and bug 391153 seem related.
Hmm.  Is the transform on the inner table or something?

If you add a caption in there, does it get transformed in various UAs?
data:text/html,<!doctype html>
<table style=-moz-transform:rotate(180deg)>
<caption>Hello</caption>
<tr><td>there
</table>

In Gecko, "there" is rotated but "Hello" is not.  In IE/Chrome/Opera, the whole table is rotated.  Likewise, percentages are relative to the height of the whole thing including caption.  It looks like the transforms spec doesn't say whether the transform is supposed to apply to the table wrapper box, or the table box.  Implementations make it the table wrapper box.  Should I file another bug?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15815
In our case it's basically the same bug.  The table wrapper box is what's used as a containing block for positioned stuff if the table is used at all, but since that's not transformed it's not actually a positioned containing block.

If we fix the transform to apply to the table wrapper box, the abs/fixed thing will automagically work, I suspect...
Yes. This is probably just a matter of adding to the :-moz-table-outer rule in ua.css and making nsTableFrame ignore its transform.
Assignee: nobody → matt.woodrow
So :-moz-table-outer should inherit -moz-transform/-moz-transform-origin/etc.?  How should we make nsTableFrame ignore its transform, return false from IsTransformable or something?
(In reply to Aryeh Gregor from comment #6)
> So :-moz-table-outer should inherit
> -moz-transform/-moz-transform-origin/etc.?

Yes.

> How should we make nsTableFrame
> ignore its transform, return false from IsTransformable or something?

Clearing NS_FRAME_MAY_BE_TRANSFORMED from mState in nsTableFrame::Init should do it. Then IsTransformed will return false for those frames.
I bet there are all sorts of interesting interactions with preserve-3d and anonymous frames here. E.g. does <div class="preserve-3d"><table class="preserve-3d"><td class="preserve-3d"> actually preserve-3d all the way down? I guess it shouldn't because the HTML parser inserts fake <tbody> and <tr> nodes into the DOM. But what if you do the same thing with CSS tables? Then preserve-3d should probably work all the way down. I wonder if any browser does that...
I do know that this doesn't work:

  <div style="-moz-transform:perspective(200px);
  -moz-transform-style:preserve-3d">
  <div style="height:100px;width:100px;background:lime;
  -moz-transform:rotatey(45deg);display:table">

doesn't work in Gecko but does in WebKit.  I'll definitely test anonymous table frames some more; in my brief testing they seemed to work as I'd expect, i.e., not per spec.  :)  Perhaps the spec should say that UAs have to have "tbody, thead, tfoot { transform-style: inherit }" to make it more intuitive.  (Or maybe the property should have been inherited to start with, but I guess it's too late for that.)
Created attachment 595770 [details] [diff] [review]
Patch v1

I don't know if this makes tables behave completely correctly, but it's an improvement.
Assignee: matt.woodrow → ayg
Attachment #595770 - Flags: review?(roc)
Whiteboard: [autoland]

Updated

6 years ago
Whiteboard: [autoland] → [autoland-in-queue]

Comment 11

6 years ago
Autoland Patchset:
	Patches: 595770
	Branch: mozilla-central => try
	Destination: http://hg.mozilla.org/try/rev/880a068be984
Try run started, revision 880a068be984. To cancel or monitor the job, see: https://tbpl.mozilla.org/?tree=Try&rev=880a068be984
I filed a spec bug on transform-style:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15943

WebKit treats it magically for tables, but the spec doesn't say this.
Attachment #595770 - Flags: review?(roc) → review+

Comment 13

6 years ago
Try run for 880a068be984 is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=880a068be984
Results (out of 210 total builds):
    success: 179
    warnings: 17
    failure: 14
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/autolanduser@mozilla.com-880a068be984

Updated

6 years ago
Whiteboard: [autoland-in-queue]
Keywords: checkin-needed
https://hg.mozilla.org/integration/mozilla-inbound/rev/d6c2ee4091e4
Status: NEW → ASSIGNED
Keywords: checkin-needed
Target Milestone: --- → mozilla13
https://hg.mozilla.org/mozilla-central/rev/d6c2ee4091e4
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.