407104 - Crash when trying to paint gradient with no stops

Status: RESOLVED FIXED

(Core :: Graphics, defect, P2)

Description

[Boris Zbarsky [:bzbarsky]]

See the mail in the URL field.  I've disabled the test_2d.gradient.empty.html canvas test on Mac for now; we should reenable it once we fix this.

Comment 1

[Robert Longson [:longsonr]]

In SVG world you have these rules...

It is necessary that at least two stops defined to have a gradient effect. If no stops are defined, then painting shall occur as if 'none' were specified as the paint style. If one stop is defined, then paint with the solid color fill using the color defined for that gradient stop.

Perhaps canvas should do the same thing.

Comment 2

[Philip Taylor]

The canvas spec says "When there are no stops, the gradient is transparent black", and the implementations I've tested all agree with that (at least on Linux and Windows), so that does look like the sensible thing to do. (See e.g. <http://philip.html5.org/tests/canvas/suite/tests/2d.gradient.empty.html>)

Comment 3

[Brian Ewins]

That's what the patch I've got does (as I mentioned in my reply on the list). It is the behaviour of cairo's image backend,  so the quartz backend behaving differently was a bug.

Really the patch here should be as simple as:
(at http://lxr.mozilla.org/seamonkey/source/gfx/cairo/cairo/src/cairo-quartz-surface.c#722
)
cairo_gradient_pattern_t gpat = (cairo_gradient_pattern_t *)source;
if (!gpat->n_stops) {
CGContextSetRGBStrokeColor (surface->cgContext, 0., 0., 0., 0.);
CGContextSetRGBFillColor (surface->cgContext, 0., 0., 0., 0.);
return DO_SOLID;
}

... but something equivalent to this caused an unrelated failure in cairo's tests (placing this after the checks for unsupported gradient types works, but needs the bigger change I mentioned in my mail). I need to add a unit test for this to cairo anyway. I'll post a patch later tonight.

Comment 4

[William Jenkins]

(In reply to comment #2)

> (See e.g.
> <http://philip.html5.org/tests/canvas/suite/tests/2d.gradient.empty.html>)

I tried this out in Camino Version 2007102517 (1.5.3) by visiting the website Philip Taylor referred to and it appeared to work; that is the website claimed that the browser passed the test.  Then I tried the same thing in Firefox 3.0 Beta 1, and the browser crashed and TalkBack came up and submitted the results. So it seems that the problem has been fixed in Camino and maybe someone could copy the code from there.  I don't know much about the relationship between Firefox and Camino, though, so maybe it's more complicated than that. I'm going to try installing a nightly build of Firefox and see what happens with that. By the way, I'm using a PowerPC iBookG4 with Mac OS X 10.4.11 (Tiger).

Comment 5

[William Jenkins]

Update: I downloaded the latest nightly build of Firefox and tried visiting the test website again.  The first time, the browser just hung and the Spinning-Pinwheel-of-Death appeared, so I "Force Quit" the application.  I tried it again just to be sure and this time the browser actually crashed and the Crash Reporter application appeared, as it did with Beta 1.

Here's the browser version:

Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9b2pre) Gecko/2007120604 Minefield/3.0b2pre

Comment 6

[Brian Ewins]

I'm not sure Camino is relevant, their cairo may predate the nquartz surface (which hit trunk in June IIRC, and isn't used on branch). In any case, I've pushed a test and quartz fix now to cairo master, turns out this is a crasher for us on the pdf surface too and possibly ps, svg as well. 
http://gitweb.freedesktop.org/?p=cairo;a=commit;h=19680f545a1620d944322775c1b85b0e5f93fa0f

(you'll need the preceding commit as well if you cherry pick this for yourself)

Both patches should apply to trunk I think, but I'll try this myself shortly.

Comment 7

[Boris Zbarsky [:bzbarsky]]

William, Camino 1.5.3 uses Gecko 1.8.1.9.  So it's not even using cairo for rendering.  You'd need to try a development version of Camino based on a trunk Gecko to see this bug in Camino.

Comment 8

[William Jenkins]

(In reply to comment #6 and comment #7)
Thanks for the clarification. I really don't know anything about the actual development of the Gecko rendering engine and its incorporation into the different web browsers that Mozilla produces, e.g Firefox, Camino, Seamonkey. I just thought it might be helpful to try to reproduce the bug.  Sorry for the confusion.

Comment 9

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Fixed by bug 411224.