379610 - Reftest opacity-and-gradient-01.svg fails on OS X 10.4

Status: RESOLVED WONTFIX

(Core :: SVG, defect)

Description

[Jonathan Watt [:jwatt]]

Attachment: Copy of the 'data:' base64 encoded image of the test failing

The reftest opacity-and-gradient-01.svg fails on the tinderbox "MacOSX Darwin
8.8.4 qm-xserve01 dep unit test". For the build/reftest log see:

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1178197680.24651.gz&fulltext=1

It's interesting that the opacity-and-pattern-01.svg test (identical except using patterns instead of gradients) passes just fine.

Comment 1

[Jonathan Watt [:jwatt]]

The failing image shows the 'opacity' property working, but the 'fill-opacity' and 'stroke-opacity' properties failing.

Comment 2

[Jonathan Watt [:jwatt]]

Attachment: opacity-and-gradient-01.svg

Comment 3

[Jonathan Watt [:jwatt]]

So doing some debugging with jmt we _seem_ to be observing the fill-opacity attribute having the value "1" instead of the value "0" as specified in the source. To see this you can put a breakpoint at:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/style/nsCSSParser.cpp&rev=3.353&mark=4573#4572

Which will give you the stack:

CSSParserImpl::ParseSingleValueProperty
CSSParserImpl::ParseProperty
CSSParserImpl::ParseProperty
nsSVGElement::UpdateContentStyleRule

Maybe we were doing something wrong, but if you look up in UpdateContentStyleRule you'll see the variable 'value' (i.e. the attribute value) has the value "1". :-/ Indeed, the failure behavior is as if "1" was specified.

Comment 4

[tor]

(In reply to comment #3)
> So doing some debugging with jmt we _seem_ to be observing the fill-opacity
> attribute having the value "1" instead of the value "0" as specified in the
> source.

I'm not see this - the right fill opacity is set, and SetupPaintServer gets the correct value.  Looking further down, ComputeGradientValue in cairo-quartz-surface.c is computing the right values.

Doing some investigating, other people have encountered similar odd behavior with Quartz:

  http://lists.apple.com/archives/quartz-dev/2006/Mar/msg00006.html

Comment 5

[Jonathan Watt [:jwatt]]

Is this okay on Mac trunk?

Comment 6

[Brian Ewins]

WFM branch and trunk.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-GB; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b2pre) Gecko/2007113023 Minefield/3.0b2pre

Closing as WFM as this wasn't fixed by the last cairo update (bug 383960) maybe the previous update? Tested branch on 10.5 and 10.4, so doesn't appear to be a Leopard fix either.

Comment 7

[Jonathan Watt [:jwatt]]

In http://lxr.mozilla.org/seamonkey/source/layout/reftests/svg/reftest.list we have this test prefixed with:

  fails-if(MOZ_WIDGET_TOOLKIT=="cocoa")

If it was actually passing on the Mac tinderboxes then we'd have been notified (the boxes would have turned orange with the message UNEXPECTED PASS). For some reason this is still broken for them.

Comment 8

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

The test machines are running 10.4.8, and I presume Brian is running something more recent/up-to-date -- it's entirely possible that this was fixed in CG after 10.4.8 (which was released Sept '06).

Comment 9

[Robert Longson [:longsonr]]

Looks like we're not going to support 10.4 on trunk any more.

Comment 10

[Daniel Holbert [:dholbert]]

(In reply to comment #9)
> Looks like we're not going to support 10.4 on trunk any more.

Perhaps we should remove the "fails on 10.4" annotation in reftest.list, then?  (and just state that the test should always pass)

Annotation was added here:
http://hg.mozilla.org/mozilla-central/rev/e3119a5865c5

Comment 11

[Robert Longson [:longsonr]]

Indeed. Feel free to do that :-)

Comment 12

[Daniel Holbert [:dholbert]]

removed annotation: http://hg.mozilla.org/mozilla-central/rev/b4ad886d0baf