User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.57 Safari/537.17 Steps to reproduce: Hey guys, we recently discovered that the latest Firefox version (19) has a bug that is not painting images correctly when the content is created dynamically (in our case e.g., a JSON is retched by AJAX, which is then used in a underscore Javascript template). The templates contains a inline-style like: <td style="background-image: url(http://a.cdn.net/path/to/image.png)">...</td> Actual results: When I make a full refresh, everything is loaded instantly and looks fine. However, if the content area is cleared and new content is created (in exactly the same way as on a clean refresh, except that the page is not reloaded - so AJAX > JSON > _.underscore), then the pictures are not immediately visible. Sometimes it takes up to 10-12 seconds for them to display. This ONLY occurs in Firefox 19 and 20b1 Live Example: https://www.racebets.com/en/horse-betting-online/race/details/id/808582/ Clean refresh, all good. But change the races once loaded, and the silks are not painted. If you resize the window, change some CSS style or scroll up and down, the silks are painted immediately - so I suspect it is a draw/paint issue. Happens ONLY in Firefox 19 and 20b1 and was reproduced on 5 individual Windows 7 computers. Expected results: The images should be loaded immediately.

Could you attach a minimal testcase (HTML file e.g. or online testcase)? It would help to debug.

Hello Loic, I tried for several hours to reproduce the bug in jsfiddle and on a local test page, but I cannot get it to behave like on our website. I added a video to emphasise the problem. I tried to reproduce it on our site on more computers and it definitely happens in every FF19+ version. Link to a 30 second screencast: http://screencast.com/t/rvewzv0w It is definitely not (only?) a problem with rendering dynamic elements with a background-image in it because this generally works, but must rather be a side effect or some more things.

I just isolated the bug and it is actually only happening when the parent table is the CSS attribute "border-collapse: collapse;". See the attached file for a simple test case.

Simple test case. As soon as you remove "border-collapse: collapse;" from the table style, the images load as expected.

Confirmed (with the testcase and link in comment #0). The images are not loaded immediately, scrolling or switching to another tab then going back fixes the issue. Regression range: m-c good=2012-11-06 bad=2012-11-07 http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f9c2c266e7aa&tochange=e587aa26326e

Regression window Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/3523098f7911 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121106135430 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/8d793eb6a281 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121106140530 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=3523098f7911&tochange=8d793eb6a281 Regressed by: Bug 798964

A temporary workaround is to use cellspacing="0" on the table element instead of using the border-collapse CSS property.

(In reply to Spellcoder from comment #9) > A temporary workaround is to use cellspacing="0" on the table element > instead of using the border-collapse CSS property. Negative, cellspacing="0" does not result into the same behaviour as "border-collapse: collapse;" - and it shouldn't if I think about it. Any other working workaround?

the places where this bug bites us, we were using "border-collapse: collapse;" (and td { padding: 0; })" only as a css replacement for cellspacing=0, cellpadding=0, and we weren't actually using borders. In that case, using old-fashioned cellspacing=0 cellpadding=0 instead of border-collapse:collapse, is a workaround for us.

(In reply to Loic from comment #5) > Confirmed (with the testcase and link in comment #0). > The images are not loaded immediately, scrolling or switching to another tab > then going back fixes the issue. Given your description of the problem/workaround, we'd take a low risk uplift but would not track for upcoming releases.

This is the same as bug 844750.