Closed Bug 379610 Opened 13 years ago Closed 10 years ago

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

Categories

(Core :: SVG, defect)

x86
macOS
defect
Not set

Tracking

()

RESOLVED WONTFIX

People

(Reporter: jwatt, Unassigned)

References

()

Details

Attachments

(2 files)

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.
The failing image shows the 'opacity' property working, but the 'fill-opacity' and 'stroke-opacity' properties failing.
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.
(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
Is this okay on Mac trunk?
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.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Blocks: 432298
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).
Assignee: general → nobody
QA Contact: ian → general
Summary: Reftest opacity-and-gradient-01.svg fails on OS X → Reftest opacity-and-gradient-01.svg fails on OS X 10.4
Looks like we're not going to support 10.4 on trunk any more.
Status: REOPENED → RESOLVED
Closed: 12 years ago10 years ago
Resolution: --- → WONTFIX
(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
Indeed. Feel free to do that :-)
You need to log in before you can comment on or make changes to this bug.