Incorrect rendering when MozTransform set to scale and png images

RESOLVED WORKSFORME

Status

()

Core
Layout
RESOLVED WORKSFORME
6 years ago
4 years ago

People

(Reporter: lviggiani, Unassigned)

Tracking

13 Branch
All
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
Created attachment 635651 [details]
test.html

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:13.0) Gecko/20100101 Firefox/13.0.1
Build ID: 20120615112143

Steps to reproduce:

Consider the attached example.



Actual results:

When run in FF 13 (both OSX and Linux) or in FF14 Beta (mobile/android) the images are rendered only partially and misplaced.

Interesting thing to notice are:

1) The problem does not occur if main div transform is not applied ( //main.style.MozTransform =  "scale(.5,.5)";) OR
2) The two images (image1 and image2) have a background color (image1.style.backgroundColor = "red"; image2.style.backgroundColor = "red";)

In addition, please notice that there are two moments when everything is rendered correctly: when opacity in the arrow blinking animation is set either to 0 or 1 (you see better if you increase the setInterval time)


Expected results:

The arrow should blink over the red cup
(Reporter)

Comment 1

6 years ago
here is the javascript from my attached example:

function test(){
	var main = document.body.appendChild(document.createElement("div"));
	main.style.position = "absolute";
	main.style.width = "600px";
	main.style.height = "600px";
	main.style.MozTransform = main.style.WebkitTransform = "scale(.5,.5)";
	
	var image1 = main.appendChild(document.createElement("img"));
	image1.style.position = "absolute";
	image1.src = "http://images2.wikia.nocookie.net/__cb20070425035052/house/images/9/92/House_Red_Mug_Trans.png";

	var image2 = main.appendChild(document.createElement("img"));
	image2.style.position = "absolute";
	image2.style.left = "200px";
	image2.style.top = "400px";
	image2.src = "http://a.dryicons.com/images/icon_sets/coquette_part_5_icons_set/png/128x128/blue_arrow_up.png";

	var a = 1;
	setInterval(function(){
		a+=.1;
		if (a>1) a = 0;
		image2.style.opacity = a;
	}, 100);
}
(Reporter)

Updated

6 years ago
Component: Untriaged → Webapp Runtime

Updated

6 years ago
Attachment #635651 - Attachment mime type: text/plain → text/html

Comment 2

6 years ago
I think This was fixed by Bug 750334 in Firefox14beta and later.

Comment 3

6 years ago
Created attachment 635665 [details]
CSS only testcase

On windows I see both images fully, though whenever opacity isn't 0 or 1 they move a pixel to the right.
This is the testcase without javascript for people on linux to see if the problem still happens.
The movement in the first testcase doesn't happen in this one on windows, though I'm not sure that means the fault is with how the javascript engine works on style.

Comment 4

6 years ago
(In reply to Mardeg from comment #3)
> Created attachment 635665 [details]
> CSS only testcase
> 
> On windows I see both images fully, though whenever opacity isn't 0 or 1
> they move a pixel to the right.
> This is the testcase without javascript for people on linux to see if the
> problem still happens.
> The movement in the first testcase doesn't happen in this one on windows,
> though I'm not sure that means the fault is with how the javascript engine
> works on style.

This is Bug 767292

Comment 5

6 years ago
Sorry
Please ignore comment #4.

Comment 6

6 years ago
Testing on Fennec nightly trunk, Galaxy Nexus ICS.
First testcase with js, about the bottom quarter of the arrow disappears only when opacity is 0 or 1, the rest of the time it's all visible (the opposite of the bug description?). The mug is always fully visible.
Second testcase without js works without any problem.

Updated

6 years ago
Component: Webapp Runtime → Layout
Product: Firefox → Core
QA Contact: untriaged → layout
Hardware: x86_64 → All
(Reporter)

Comment 7

6 years ago
Just tested my test case (test.html) on nightly build just downloaded on Mac and it works fine.
Looks fine to me now (with attached test cases)
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.