User-Agent: Mozilla/5.0 (Windows; Windows NT 5.1; en-US; rv:2.0b2pre) Gecko/20100707 Minefield/4.0b2pre Build Identifier: Mozilla/5.0 (Windows; Windows NT 5.1; en-US; rv:2.0b2pre) Gecko/20100707 Minefield/4.0b2pre Here is a tricking regression. The link I provide is a work in progress (I freezed it at that URL for the purpose of this bug) where I try to show the interests of inline SVG inside an HTML document. For a few days now (at least 2 or 3), I experience some random flickering on the objects which use a clipPath. The flickering disappear if I applies some filters to those objects. I say it's a regression (therefor I thing it's a major bug) because if I try to use FF 3.6 with the HTML5 Parser enable, it work fine without any flickering. Reproducible: Always Steps to Reproduce: 1. open the provide URL 2. set a Puzzle (let the default options) 3. try to move some pieces over other pieces Actual Results: Some pieces are rectangular where they have to be clipped and when you move the piece they sometime do not render properly. Expected Results: The pieces should be cleanly clipped and should not flicker while moving whatever you applies filters or not.

Can you produce a minimised testcase and attach it to the bug please. The example given is too large to figure out what's going on.

Alternately, can you narrow down when the problem appeared using nightlies? For what it's worth, I see no flickering on Mac...

Ok, here is a shorten test case. Move your mouse over, in and out the red SVG elements. They flick but they should not. This is a real subtle problem because if you change something in the HTML or in the CSS, the problem vanished. the combination of the CSS properties font-family, position and vertical align is require (remove one of them and there is no problem any more). The use of canvas is require has well (if you use an img tag instead of the canvas tag, no problem).

I'm not seeing any red elements in that testcase...

(In reply to comment #2) > Alternately, can you narrow down when the problem appeared using nightlies? I'm working on it > For what it's worth, I see no flickering on Mac... I don't have a Mac so I can't test with it. I continue to dig on it but at that time this bug occur on Windows and on Linux as well. (In reply to comment #4) Ah... I see, this is due to the lack of load event on the Image. The canvas is painted before the Image is rendered if the image is not in your browser cache. I'll fix the test case ASAP.

FWIW, no flicker for me on a Linux trunk build. (had to save the file locally to get the red puzzle-pieces to show up, too.) Mozilla/5.0 (X11; Linux i686; en-US; rv:2.0b2pre) Gecko/20100708 Minefield/4.0b2pre

Here is an update version of the testcase. This update fix the load img issue in the previous test case. I've change the font-size property of the body element. The consequence is that now, this test case allow me to show the bug on my linux laptop with Mozilla/5.0 (X11; Linux x86_64; en-US; rv:2.0b2pre) Gecko/20100708 Minefield/4.0b2pre But with this change, this new testcase do not show the bug on my WinXP machine (but it still occur with the old test case).

Du to the feed back, I've dig into my test case to make it simpler and try to figure out why it behave differently between OS. First of all, I have reduced the number of SVG elements and the complexity of the clip path. By doing that, the flickering effect is gone but, now, it's easier to see that sometimes, the clipPath is not visually rendered. If the clip path is applied, you can see a red square clipped by a half circle. If it is not, you'll see a simple red square. It seems that the problem is depending on the typographic size. So with this new test case, you can easily change the font size to check at which point the clipping rendering is messing up. This could explain why different OS behave differently: the typo are not the same and their own default size could be different. For example, with my WINXP machine, the clip path is well rendered with the font size values : 24, 22, 19, 18, 16, 15, 8, 7, 5, 3 and 0 pixels. At other sizes, it is not rendered.

Here's some additional questions then if you're game... Does it require canvas or can you simplify things such that it just uses an SVG image element? Does it really require text with a font-size at the top or does anything that moves the svg down the page cause things to screw up? If you convert this to xhtml so that it works on Firefox 3.6 does that still show a problem? Does that xhtml version show a problem on trunk?

(In reply to comment #9) > Does it require canvas or can you simplify things such that it just uses an SVG > image element? No, canvas is require, if I use an SVG image or an HTML img element inside a foreignObject I can not reproduce the problem > Does it really require text with a font-size at the top or does anything that > moves the svg down the page cause things to screw up? Yes it's require and a text before the element with the property position:relative is require as well. It's also require to have this text inside an inline element with the CSS property vertical-align:middle. > If you convert this to xhtml so that it works on Firefox 3.6 does that still > show a problem? Does that xhtml version show a problem on trunk? I've run the following test with the last test case : HTML version with FF 3.6.6 and the HTML5 parser enable : no problem HTML version with FF 3.7a5pre : the clipPath is never apply HTML version with the trunk : The problem as describe above XHTML version with FF 3.6.6 and the HTML5 parser enable : no problem XHTML version with FF 3.7a5pre : no problem XHTML version with the trunk : The problem as describe above the FF 3.7a5pre, it's the build : Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a5pre) Gecko/20100424 Minefield/3.7a5pre I'm sorry but I don't know where to find other trunk build to investigate when things change between this old build and the current trunk build.

You can find old trunk builds here: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ trunk is in the directories that end mozilla-central If you can get down to the day a fix is massively more likely given that the testcase is still relatively complex. Please type about:buildconfig into the location bar and tell us the built from data for the last working build and the first broken one so we can get an accurate range.

Ok, I've found that the build that break the XHTML test case is between 2010/04/26 built from http://hg.mozilla.org/mozilla-central/rev/2968d19b0165 and 2010/04/27 built from http://hg.mozilla.org/mozilla-central/rev/29a6a85fab8e There is also a change on the way the HTML testcase react between 2010 05 03 built from http://hg.mozilla.org/mozilla-central/rev/83c887dff0da and 2010 05 04 built from http://hg.mozilla.org/mozilla-central/rev/d6bb0f9e9519 Hope this will help.

The log for the first is http://hg.mozilla.org/mozilla-central/shortlog/41393 my guess would be bug 542605 or possibly bug 561827 The second is http://hg.mozilla.org/mozilla-central/shortlog/41756 which includes bug 373864 which enables the html5 parser. Before that, inline svg only works in xhtml so that's expected.

bug 561827 must have been a commit typo. I don't know what the real bug number would be.

Since this requires canvas to show the bug and seems to be as a result of the bug 542605 cairo checkin I think core->graphics is a better home.

This bug looks ok now. I do not have the time to check each version of Gecko to see when this happen but it works now :D

We use fixed if we know why and WFM if not.