Closed Bug 953334 Opened 6 years ago Closed 6 years ago

text-shadow issue with hardware acceleration enabled

Categories

(Core :: Graphics, defect)

26 Branch
x86
Windows 7
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla29
Tracking Status
firefox26 --- wontfix
firefox27 + verified
firefox28 + verified
firefox29 + verified
firefox-esr17 --- unaffected
firefox-esr24 --- unaffected

People

(Reporter: heaven_ro, Assigned: jrmuizel)

References

Details

(Keywords: platform-parity, testcase)

Attachments

(5 files, 1 obsolete file)

Attached file bug.rar
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release)
Build ID: 20131216183647

Steps to reproduce:

jquery.bxSlider.js is a little harder to debug, but i dont thing the problem is there couse it works fine in all the other browsers that i tested.. it worked just fine in firefox up to 25 i guess.. firefox 26 and 27 dont hide part of that <p> 


Actual results:

firefox 26 and 27 dont hide part of that <p> .. it has something to do with that text-shadow .. if values are changed.. script works ->
 text-shadow: #999 2px 2px 1px;
works fine


Expected results:

well.. should be hidden ..
Component: General → CSS Parsing and Computation
Attached file bug.html
With the online libraries, I get this rendering: http://i.imgur.com/yB9RoKd.png

Clicking on the numbers makes the text change.

Is it normal?
Flags: needinfo?(heaven_ro)
NB/ you need to allow mixed content (location bar).
Attached image win7_sp1.jpg
I can not reproduce it in something other than windows7, win7_sp1..
it works fine in ubuntu firefox 26 and android firefox..

with online libraries, you get another version of bx slider but the bug is still there(for win7 -> firefox 26 [and 27beta])
Flags: needinfo?(heaven_ro)
WFM
http://hg.mozilla.org/mozilla-central/rev/fe7f7ead589c
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 ID:20131228030204
http://hg.mozilla.org/releases/mozilla-aurora/rev/af28fe58e263
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20131228004002
http://hg.mozilla.org/releases/mozilla-beta/rev/5a11c57ceaa7
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 ID:20131216183647
Flags: needinfo?
Attached file bug.html
here is a copy with no javascript.
Works for me, Nightly 29.0a1 (2013-12-29) on Windows 7, with and without h/w acceleration enabled.
Component: CSS Parsing and Computation → Graphics
Flags: needinfo?
Keywords: pp, testcase
Can you reproduce the bug also in a clean profile?
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

How about with hardware acceleration turned off (in Options -> Advanced)?
Flags: needinfo?(heaven_ro)
it works fine with hardware acceleration turned off..

still buggy in a clean profile.. tested on 2 different windows7 computers..
Flags: needinfo?(heaven_ro)
Please load about:support and post the Graphics section from that page
(with hardware acceleration enabled).
Flags: needinfo?(heaven_ro)
Summary: text-shadow issue → text-shadow issue with hardware acceleration enabled
both of them are older intel 965 -- this is one of the 2:

Adapter Description	Mobile Intel(R) 965 Express Chipset Family
Adapter Drivers	igdumdx32 igd10umd32
Adapter RAM	Unknown
Device ID	0x2a12
Direct2D Enabled	Blocked for your graphics driver version.
DirectWrite Enabled	false (6.2.9200.16492)
Driver Date	9-23-2009
Driver Version	8.15.10.1930
GPU #2 Active	false
GPU Accelerated Windows	1/1 Direct3D 9
Vendor ID	0x8086
WebGL Renderer	Google Inc. -- ANGLE (Mobile Intel(R) 965 Express Chipset Family Direct3D9Ex vs_3_0 ps_3_0)
windowLayerManagerRemote	false
AzureCanvasBackend	skia
AzureContentBackend	none
AzureFallbackCanvasBackend	cairo
AzureSkiaAccelerated	0
Flags: needinfo?(heaven_ro)
And it looks like you have the latest drivers (8.15.10.1930) for this Intel chipset.
Blocks: 904266
I can repro.
user_pref("gfx.content.azure.backends", "");
user_pref("layers.prefer-d3d9", true);

http://hg.mozilla.org/releases/mozilla-beta/rev/5a11c57ceaa7
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 ID:20131216183647
Status: UNCONFIRMED → NEW
Ever confirmed: true
jeff/:mats, can you please help with next steps here ? Do you think this testcase would be a common scenario to be hit by real world websites or what are your thought's on user impact to track for release ?
Flags: needinfo?(matspal)
Flags: needinfo?(jmuizelaar)
I don't know much about graphics code so I'll defer that to Jeff.
Flags: needinfo?(matspal)
I expect this is a dup of bug 953253
Status: NEW → UNCONFIRMED
Ever confirmed: false
Flags: needinfo?(jmuizelaar)
Duping for now and not tracking as the DUP is already tracked.
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 953253
I have a patch that fixes this.
Currently we can think that we have a clip set on the DC when we actually don't. Calling _cairo_win32_surface_set_clip_region(NULL) clears this so that when we call it with the a region we will set it properly on the new DC that doesn't have the clip set on it.
Attachment #8356427 - Flags: review?(bgirard)
Comment on attachment 8356427 [details] [diff] [review]
Clear the clip on the surface when we get a new DC

Review of attachment 8356427 [details] [diff] [review]:
-----------------------------------------------------------------

Probably could use better comments. Don't you want to write a cairo patch for this?
Attachment #8356427 - Flags: review?(bgirard) → review+
We also need to land a patch file for this, right?
Flags: needinfo?(jmuizelaar)
(In reply to Mats Palmgren (:mats) from comment #21)
> We also need to land a patch file for this, right?

I decided to stop doing that. I've always just used the mercurial history when syncing the cairo stuff with upstream and I'm not sure that the current patches are really of any use.
Flags: needinfo?(jmuizelaar)
OK, good to know.  The old scheme with patch files did make it easy to see
the current set of local changes though.  I'm slightly worried that our
bug fixes will get buried and never upstreamed.
(In reply to Mats Palmgren (:mats) from comment #23)
> OK, good to know.  The old scheme with patch files did make it easy to see
> the current set of local changes though.  I'm slightly worried that our
> bug fixes will get buried and never upstreamed.

Upstream is far enough away (1.12 vs 1.10) right now that most fixes aren't relevant anymore. I hope to fix this, but it's never been a high priority.
Resolution: DUPLICATE → FIXED
Duplicate of this bug: 953253
The patch as it actually landed.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 907544
User impact if declined: Incorrect rendering on some pages.
Testing completed (on m-c, etc.): on m-c for one day, there's a test cse included and it passes all of the tests in tree.
Risk to taking this patch (and alternatives if risky): Relatively low, easy to backout.
Attachment #8356427 - Attachment is obsolete: true
Attachment #8358573 - Flags: approval-mozilla-beta?
Attachment #8358573 - Flags: approval-mozilla-aurora?
Blocks: 907544
No longer blocks: 904266
Blocks: 958500
Duplicate of this bug: 956209
Attachment #8358573 - Flags: approval-mozilla-beta?
Attachment #8358573 - Flags: approval-mozilla-beta+
Attachment #8358573 - Flags: approval-mozilla-aurora?
Attachment #8358573 - Flags: approval-mozilla-aurora+
Keywords: verifyme
Reproduced with 27 beta 2 (Build ID: 20131216183647) with STR from comment 12 and the attached testcase.

Verified as fixed with Firefox 27 beta 6 (Build ID: 20140113161826):
Mozilla/5.0 (Windows NT 6.1; rv:27.0) Gecko/20100101 Firefox/27.0
Duplicate of this bug: 958500
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0
Verified as fixed on latest Aurora 28.0a2 (20140120004001) and latest Nightly 29.0a1 (20140120030202).
Status: RESOLVED → VERIFIED
Keywords: verifyme
QA Contact: petruta.rasa
Duplicate of this bug: 951102
You need to log in before you can comment on or make changes to this bug.