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

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?

NB/ you need to allow mixed content (location bar).

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])

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

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.

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)?

it works fine with hardware acceleration turned off.. still buggy in a clean profile.. tested on 2 different windows7 computers..

Please load about:support and post the Graphics section from that page (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

And it looks like you have the latest drivers (8.15.10.1930) for this Intel chipset.

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

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 ?

I don't know much about graphics code so I'll defer that to Jeff.

I expect this is a dup of bug 953253

Duping for now and not tracking as the DUP is already tracked.

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.

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?

We also need to land a patch file for this, right?

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

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.

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.

https://hg.mozilla.org/releases/mozilla-aurora/rev/7fbaade45173 https://hg.mozilla.org/releases/mozilla-beta/rev/c53d7e5c6e0c

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

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).