Note: There are a few cases of duplicates in user autocompletion which are being worked on.

getComputedStyle().MozTransformOrigin and MozPerspectiveOrigin sometime return percentages

RESOLVED FIXED in mozilla13

Status

()

Core
DOM: CSS Object Model
--
minor
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: ayg, Assigned: ayg)

Tracking

Trunk
mozilla13
x86
Linux
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Test case:

data:text/html,<!doctype html>
<body>
<script>
alert(getComputedStyle(document.body).MozTransformOrigin)
</script>

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)>
<script>
alert(getComputedStyle(document.body).MozTransformOrigin)
</script>

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:

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

I suggest Gecko change to do this too, to match other browsers.

Comment 1

6 years ago
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?
The current spec actually doesn't define a .transformOrigin property at all, in <http://dev.w3.org/csswg/css3-transforms/#dom-interfaces>, so the format isn't defined AFAICT.  That's <https://www.w3.org/Bugs/Public/show_bug.cgi?id=15433>.  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

6 years ago
> The current spec actually doesn't define a .transformOrigin property at all

The relevant spec is http://dev.w3.org/csswg/cssom/#dom-window-getcomputedstyle which claims that the resolved value is the computed value for all but a small list of properties; see http://dev.w3.org/csswg/cssom/#resolved-value

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....  :(
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

6 years ago
We should probably just match the other UAs and "fix" the spec...
(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
> http://dev.w3.org/csswg/cssom/#dom-window-getcomputedstyle which claims that
> the resolved value is the computed value for all but a small list of
> properties; see http://dev.w3.org/csswg/cssom/#resolved-value

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.)
The same issue exists for perspective-origin.
Summary: getComputedStyle().MozTransformOrigin sometimes returns percentages → getComputedStyle().MozTransformOrigin and MozPerspectiveOrigin sometime return percentages
Created attachment 595137 [details] [diff] [review]
Patch

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?
Assignee: nobody → ayg

Comment 9

6 years ago
I think you should probably request review.
Attachment #595137 - Flags: review?(roc)
Attachment #595137 - Flags: review?(roc) → review?(bzbarsky)

Comment 10

6 years ago
Comment on attachment 595137 [details] [diff] [review]
Patch

r=me
Attachment #595137 - Flags: review?(bzbarsky) → review+
Whiteboard: [autoland]

Updated

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

Comment 11

6 years ago
Autoland Patchset:
	Patches: 595137
	Branch: mozilla-central => try
	Destination: http://hg.mozilla.org/try/rev/592efbbd58f2
Try run started, revision 592efbbd58f2. To cancel or monitor the job, see: https://tbpl.mozilla.org/?tree=Try&rev=592efbbd58f2

Comment 12

6 years ago
Try run for 592efbbd58f2 is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=592efbbd58f2
Results (out of 212 total builds):
    success: 192
    warnings: 20
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/autolanduser@mozilla.com-592efbbd58f2
 Timed out after 06 hours without completing.

Updated

6 years ago
Whiteboard: [autoland-in-queue]
None of the test failures seem related.
Keywords: checkin-needed
http://hg.mozilla.org/integration/mozilla-inbound/rev/fd7620f86092
Keywords: checkin-needed
Target Milestone: --- → mozilla13

Updated

6 years ago
Flags: in-testsuite+
https://hg.mozilla.org/mozilla-central/rev/fd7620f86092
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.