User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 (Beta/Release) Build ID: 20140614030205 Steps to reproduce: Navigate to http://football.secunit.org/ in Firefox nightly/trunk. Actual results: Should have country icon images inside the circles. Does so on IE11/Chrome 37. Also, Dragging the circles around behaves oddly and leaves broken rendering of lines. This also happens in IE11 to some degree, works as should in Chrome 37. Expected results: Country images should have loaded inside the circles. Dragging the circles should have kept their connecting lines rendering properly with the dragging movement/new placement.

(In reply to Ran Sagy from comment #0) >Should have country icon images inside the circles. Does so on IE11/Chrome 37. I can reproduce the problem in Aurora32.0a2 and Nightly33.0a1. > Also, Dragging the circles around behaves oddly and leaves broken rendering > of lines. I cannot reproduce this. Regression Window(m-i) Good: https://hg.mozilla.org/integration/mozilla-inbound/rev/4511d9ac1000 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0 ID:20140606104153 Bad: https://hg.mozilla.org/integration/mozilla-inbound/rev/79624417d247 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0 ID:20140606104333 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=4511d9ac1000&tochange=79624417d247 Regressed by: Bug 994081

Can reproduce on OSX. Checking.

To be specific, I can reproduce the issue with the missing image in the circle. I don't see broken rendering.

Update: Sorry, My bad there about rendering/script issue - It's actually IE that fails at this, FF Nightly and Chrome do just fine.

We really want to avoid doing this. This is going to be really slow on any backend that has the pixels in VRAM (like Direct2D), and jwatt has been working hard to get rid of the callers of GetThebesSurfaceForDrawTarget. What creates the cairo gfxContext that is used in this case? We should try just convert that location to Moz2D instead.

Had a look because I was bored, this fixes the issue for me.

(In reply to Matt Woodrow (:mattwoodrow) from comment #9) > Had a look because I was bored, this fixes the issue for me. :( Unfortunately we already have a patch that does this in bug 932198. I've been holding off on landing it because doing this conversion breaks some reftests. Or at least it used to, but may not now after more Moz2D conversion. I'll push to Try and see if that's still the case.

I landed the patch over in bug 932198 since it passed Try (with a bit of fuzzing of a couple of font tests) and goes a little further than the patch here in its conversion to Moz2D.

Is bug 932198 going to be enough to fix all cases where a cairo gfxContext gets passed to imgFrame::Draw?

Bug 932198 fixes this specific case. Hopefully there are no other cases where imgFrame::Draw attempts to draw to a thebes gfxContext.