1279447 - moz-transform: translate y value sign differs from other browsers

Status: RESOLVED INVALID

(Core :: Layout, defect)

Description

[Attila Soki]

Attachment: webkit-transform.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160606200529

Steps to reproduce:

when using css transform: translate(x,y) the behavior of Firefox differs that from Safari and Chrome.

1. load the testcase in firefox and in safari and/or chrome.
2. the text will be displayed approximately in the middle of the window in all browsers
3. remove the -moz-transform: translate(-50%, -50%); line (line 27) and reload in all browsers
4. no change in safari and no change in chrome, but in firefox the text is shifted downwards



Actual results:

to achieve the same results in Firefox as in Safari and Chrome, the sign of the Y value must be flipped.
for example:

transform: translate(-50%, 50%); //Y is positive
-webkit-transform: translate(-50%, 50%); //Y is positive
-moz-transform: translate(-50%, -50%); //Y is NEGATIVE

when you remove the moz-transform line or changing Y to be positive and loading the page in firefox the text will be shifted downwards.



Expected results:

transform:translate() on firefox should behave like transform:translate() does it in other major browsers

Comment 1

[Gérard Talbot]

Attila,

1-
Can you reduce furthermore your test?

Eg
opacity: 0.9;
text-align: center;
border-radius: 2vw;
white-space: pre-wrap;
are not needed at all for your test.

2-
By definition, 'vertical-align' is a property that only applies to inline elements and table-cell elements.
https://www.w3.org/TR/CSS21/visudet.html#propdef-vertical-align

3-
If you are trying to demonstrate a bug, then do not use vendor-prefix if and when stable releases of browsers already support unprefixed version of property: this is the case with Chrome (latest stable is version 51) and Firefox (latest stable is version 47) here.

So,
line 26: -webkit-transform: translate(-50%, 50%);
line 27: -moz-transform: translate(-50%, -50%);
should not be in there. Furthermore, vendor-prefixed declarations should always be last for various known reasons (browser-prefixed version of a property does not always and necessarly do the same as the standard property; therefore order is important.).
https://css-tricks.com/ordering-css3-properties/

4-
line 22: position: relative;
line 23: top: 50%;

If the containing block's computed height is not known at parse time, then 'top: 50%' is resolved as 'auto'. Here, this could be the issue to investigate...

There could be a bug here... I really do not know at this point.

5-
Have you checked how Firefox succeeds in tests with negative percentage of translate? 
http://test.csswg.org/suites/css-transforms-1_dev/nightly-unstable/html/toc.htm
I have not found any transform tests like that so far...
Your test suggest other questions too...

6-
What does
<div id="page_motd_modal_cover">
do? Can you reproduce the problem without <div id="page_motd_modal_cover"> ?
Overall, you should try to reduce, minimize, simplify your test as much as possible.
How to Really, Really Help Developers on Bugs -- Minimal Testcases:
https://wiki.mozilla.org/MozillaQualityAssurance:Triage#How_to_Really.2C_Really_Help_Developers_on_Bugs_--_Minimal_Testcases
Reducing testcases:
https://developer.mozilla.org/en-US/docs/Mozilla/QA/Reducing_testcases

7-
Your test should also use doctype declaration. Right now, your test triggers backward-compatible (quirks) rendering mode and not standards rendering mode.

Regards, Gérard

Comment 2

[Gérard Talbot]

> 4-
> line 22: position: relative;
> line 23: top: 50%;
> 
> If the containing block's computed height is not known at parse time, then
> 'top: 50%' is resolved as 'auto'. Here, this could be the issue to
> investigate...

If you toggle On/Off the 'top: 50%' declaration in Chrome and in Firefox, you will notice a difference in rendering. This could be a bug in other browsers and not in Firefox.

- - - - - - 

Percentages for transform function is a percentage of the size of bounding box, which is, for non-SVG elements, the border-box of such element. So, how does the <div id="page_motd_modal_cover_content"> figure out its own border-box height at parse time... when such height depends on its content? This is probably why Firefox does not seem to apply the translate Y value of 50%.

Comment 3

[Attila Soki]

Attachment: mostly without the unneded properties

Comment 4

[Attila Soki]

Attachment: this one working without vendor prefixed properties, and does not triggers the problem

1. i created two new files:
	transform-y.html: mostly without the unneded properties

	i understand that the same visual effect what i wanted can be achieved simpler and without triggering this problem
	transform-ok.html: this one working without vendor prefixed properties (i tested it with nightly, FF47 and safari)

2. vertical-align removed

3. i used -moz-transform because my first example was rendered different in firefox stable without it.
the suprise was that my first example was rendered suddenly different in firefox beta as in FF47 and in safari.
now, i think this because Firefox 48 interpreting webkit prefixed properties and the -moz-transform definition was after the standard "transfer" definition but before the -webkit-transform definition.
my original css property order was:
transform
-moz-transform
-webkit-transform

4. 

5. no, i didn't known that site before.

6. unneeded div removed

7. i tried with various doctypes, there was no difference, so i not added it

Comment 5

[Gérard Talbot]

Attila,

I was going to create 2 tests out of your initial test. I will do that anyway and hopefully this weekend.

- - - - - - 

> 5. no, i didn't known that site before.

Another place to check transform translate functions tests is:

http://lxr.mozilla.org/mozilla-central/source/layout/reftests/transform/

but I see no percentage tests and no negative percentage tests in there.

- - - - - -

When I load your attachment 8762322 [details] in Firefox 47.0 buildID=20160606114208, in Firefox 50.0a1 buildID=20160611041614 and in Chrome 51.0.2704.84 (stable release), I see no noticeable difference. I am now convinced that the cause of the difference is the relatively positioned layer (the <div id="page_motd_modal_cover_content">) with 'top: 50%'. If the height of containing block of such layer is computed at parse time by rendering engine, then it will be half of the viewport height and will not be resolved as 'auto'. Chrome resolves this as 'auto'; Firefox does not.

Try this: load attachment 8762321 [details] and then uncheck 'left: 50%' and all the transform declarations and the difference in the rendering is caused by the way browsers understand how to interpret 'top: 50%'. Again, if the height of the containing block of a relatively positioned layer is computed (does not depend on its content) at parse time by browsers, then it will not be resolved as 'auto'. 

In my opinion and in my experience, chances are very high that Firefox 47 and Firefox 50 are correct and Chrome 51 and Chrome 53 are incorrect.

regards, Gérard

Comment 6

[Gérard Talbot]

> Another place to check transform translate functions tests is:
> 
> http://lxr.mozilla.org/mozilla-central/source/layout/reftests/transform/
> 
> but I see no percentage tests 

There are 4 tests testing translate(25%, 50%) (among other transform functions):
percent-1c.html, percent-1e.html, percent-1f.html and percent-1g.html

> and no negative percentage tests in there.

Comment 7

[Gérard Talbot]

> vendor-prefixed declarations should always be last for various known reasons

Err... vendor-prefixed declarations should always be first and the unprefixed declaration should follow and be last declaration for various known reasons

- - - - - -

Test:

http://www.gtalbot.org/BugzillaSection/Bug1279447-1.html

Expected result: there should be a filled green rectangle in lower left quadrant of window viewport and there should be no red. This should remain true when/if resizing viewport to any size.

Chrome 51.0.2704.84 and Chrome 53.0.2763.0 fail this test.

Firefox 47 buildID=20160606114208, Firefox 50.0a1 buildID=20160611041614, Opera 12.16, IE11 and Edge pass this test.

Attila, I think the problem you originally saw had nothing to do with transform translate function with negative percentage. If you still believe that Firefox has a bug with transform translate with negative percentage, then you should create a reduced test without positioned layers demonstrating this.

Comment 8

[Gérard Talbot]

> transform:translate() on firefox should behave like transform:translate() does it in 
> other major browsers

All major browsers nowadays are trying to comply with W3C recommended specifications and not necessarly with how other browsers behave.

> i tried with various doctypes, there was no difference, so i not added it

In absence of a doctype declaration or with an old doctype declaration, you're asking the browser to render a webpage in the way old browsers and buggy browsers were rendering webpages 10-15 years ago. With a web-standards doctype declaration, you're asking the browser to render a webpage in the best web-standards-compliant and most web-standards way. There is nowadays no known benefit to creating a webpage without a doctype declaration or with an old doctype declaration.

https://developer.mozilla.org/en-US/docs/Mozilla/QA/Reducing_testcases#Standards_and_quirks_modes

https://developer.mozilla.org/en-US/docs/Mozilla/QA/Reducing_testcases#Increasing_testcase_clarity

- - - - - -

I am resolving this bug as INVALID. 

Attila, if you still believe that Firefox has a bug with transform translate with negative percentage, then create a reduced test (preferably without positioned layers) demonstrating this and reopen this bug.