Last Comment Bug 715946 - getComputedStyle().MozTransformOrigin and MozPerspectiveOrigin sometime return percentages
: getComputedStyle().MozTransformOrigin and MozPerspectiveOrigin sometime retur...
Product: Core
Classification: Components
Component: DOM: CSS Object Model (show other bugs)
: Trunk
: x86 Linux
: -- minor (vote)
: mozilla13
Assigned To: :Aryeh Gregor (away until August 15)
Depends on:
  Show dependency treegraph
Reported: 2012-01-06 10:15 PST by :Aryeh Gregor (away until August 15)
Modified: 2012-02-09 10:15 PST (History)
3 users (show)
dao+bmo: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Patch (6.22 KB, patch)
2012-02-07 12:57 PST, :Aryeh Gregor (away until August 15)
bzbarsky: review+
Details | Diff | Review

Description :Aryeh Gregor (away until August 15) 2012-01-06 10:15:37 PST
Test case:

data:text/html,<!doctype html>

alerts "50% 50%" in 12.0a1 (2012-01-06) on Ubuntu 11.10 32-bit.  In IE9, Chrome 17 dev, and Opera Next 12.00 alpha it's in pixels, like "468px 0px".  (Obviously, I'm changing MozTransformOrigin to the appropriate prefixed variant.)  Also, in Gecko,

data:text/html,<!doctype html>
<body style=-moz-transform:translate(1px)>

alerts in pixels, like "472px 0px".

The CSS 2D Transforms spec doesn't technically say what to do here.  But all non-Gecko UAs seem to interoperably return pixel values, and so does Gecko in the interesting case (i.e., when there's a transform other than "none").  I filed a spec bug suggesting the spec say to always return pixels:

I suggest Gecko change to do this too, to match other browsers.
Comment 1 Boris Zbarsky [:bz] 2012-01-06 10:54:19 PST
This seems to be quite purposeful: nsComputedDOMStyle::GetFrameBoundsWidthForTransform returns false if not transformed.  David, do you happen to know why?  That check was in the original landing of all this code in bug 435293 and I see nothing about it in the bug.

That said, per current spec we should be alerting "50% 50%" in both cases here.  Are there pending spec changes or something?
Comment 2 :Aryeh Gregor (away until August 15) 2012-01-06 11:06:30 PST
The current spec actually doesn't define a .transformOrigin property at all, in <>, so the format isn't defined AFAICT.  That's <>.  Are you looking at a different spec?  Or are you figuring the format of .transformOrigin should follow the "Computed value" entry in the transform-origin definition?  Either way, always returning pixel values seems like the right thing to spec based on current browsers' behavior.  It's simpler for authors, too.
Comment 3 Boris Zbarsky [:bz] 2012-01-06 11:18:32 PST
> The current spec actually doesn't define a .transformOrigin property at all

The relevant spec is which claims that the resolved value is the computed value for all but a small list of properties; see

And the computed value is defined in the transforms spec, in the "Computed value" entry as you note.

It's too bad UAs are already ignoring the CSSOM spec drafts....  :(
Comment 4 :Aryeh Gregor (away until August 15) 2012-01-06 13:09:51 PST
Aha, I see.  Thanks -- I've mostly been working with DOM so far, so my CSS isn't always so great.  Personally, I'm fine with sticking with the current spec, if implementations are willing to change to match.  Gecko needs to change anyway -- which way does it want to go?
Comment 5 Boris Zbarsky [:bz] 2012-01-06 13:12:40 PST
We should probably just match the other UAs and "fix" the spec...
Comment 6 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2012-01-07 07:36:16 PST
(In reply to Boris Zbarsky (:bz) from comment #3)
> > The current spec actually doesn't define a .transformOrigin property at all
> The relevant spec is
> which claims that
> the resolved value is the computed value for all but a small list of
> properties; see

I'm not at all confident that spec is stable enough to change UA behavior based on.  (I think it may still be in the stage where we're more likely to change the spec based on UAs.)
Comment 7 :Aryeh Gregor (away until August 15) 2012-02-07 12:53:18 PST
The same issue exists for perspective-origin.
Comment 8 :Aryeh Gregor (away until August 15) 2012-02-07 12:57:14 PST
Created attachment 595137 [details] [diff] [review]

Patch attached, some tests run but not all so there might be new failures I don't know about.  Comment #1 suggests it's not clear yet whether we want this, so should I request review or not?
Comment 9 Boris Zbarsky [:bz] 2012-02-07 12:58:50 PST
I think you should probably request review.
Comment 10 Boris Zbarsky [:bz] 2012-02-07 13:17:03 PST
Comment on attachment 595137 [details] [diff] [review]

Comment 11 Mozilla RelEng Bot 2012-02-07 13:22:35 PST
Autoland Patchset:
	Patches: 595137
	Branch: mozilla-central => try
Try run started, revision 592efbbd58f2. To cancel or monitor the job, see:
Comment 12 Mozilla RelEng Bot 2012-02-08 00:30:23 PST
Try run for 592efbbd58f2 is complete.
Detailed breakdown of the results available here:
Results (out of 212 total builds):
    success: 192
    warnings: 20
Builds (or logs if builds failed) available at:
 Timed out after 06 hours without completing.
Comment 13 :Aryeh Gregor (away until August 15) 2012-02-08 08:13:51 PST
None of the test failures seem related.
Comment 15 Ed Morley [:emorley] 2012-02-09 10:15:33 PST

Note You need to log in before you can comment on or make changes to this bug.