Fedora

SVG rotation renderization broken

Reported by Jaime Soriano on 2007-03-31
8
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Fix Released
Medium
firefox (Fedora)
Fix Released
Unknown
firefox (Ubuntu)
Medium
Mozilla Bugs
Declined for Feisty by Alexander Sack

Bug Description

Binary package hint: firefox

Firefox 2.0.0.3 in Ubuntu Feisty doesn't render properly the SVG rotations, some parts of the image disappear or are corrupted.

It can be tested with http://croczilla.com/svg/samples/opacity1/opacity1.xml or with any other SVG with rotations.

It works correctly with the same version of Firefox in Ubuntu Edgy.

Changed in firefox:
assignee: nobody → mozilla-bugs
status: Unconfirmed → Needs Info
Jaime Soriano (kronoss) wrote :

I can make screenshots of the corrupted views. It happens in any SVG with rotations.

I have tried it in three different computers with Firefox 2.0.0.3 and Ubuntu Feisty and always can be reproduced. I haven't seen this problem in other distributions or other versions of Firefox.

Chris Nokleberg (chris-sixlegs) wrote :

I can confirm this on Feisty. The linux 2.0.0.3 binary downloaded from mozilla.org works fine, so it seems to be a Ubuntu-specific issue (non-standard build flags?). This will be a show-stopper for many SVG-based applications.

Alexander Sack (asac) wrote :

Thanks, this appears to be a bug in thebes implementation depending on some cairo (non-)feature which changed in latest libcairo updates.

Changed in firefox:
importance: Undecided → Medium
status: Needs Info → Confirmed
Alexander Sack (asac) wrote :

Chris, thanks for helping to triaging firefox bugs. In future, please don't nominate.

Frédéric Junod (fredj) wrote :

Hi,

I have the same problem using this site: http://www.openlayers.org/dev/examples/draw-feature.html

Sylvain Pasche (sylvain-pasche) wrote :

So not using --enable-system-cairo should fix this?

On Thu, May 24, 2007 at 10:16:12AM -0000, Sylvain Pasche wrote:
> So not using --enable-system-cairo should fix this?
>

It might fix this particular problem ... but we cannot ship with cairo
that is embedded.

 - Alexander

Sylvain Pasche (sylvain-pasche) wrote :

I can confirm that rebuilding the package with the embedded cairo fixes this. The embedded cairo version is cairo 1.0.2, while the current version on feisty is 1.4.2. That's a rather big difference for tracking the potential issues which happened between these versions. I'm wondering if the same issues is also affecting Fedora, it would be interesting to test this on core 7 (they are also using --enable-system-cairo).

What are the arguments against using the embedded cairo version?

Alexander Sack (asac) wrote :

On Thu, May 24, 2007 at 01:29:38PM -0000, Sylvain Pasche wrote:
> I can confirm that rebuilding the package with the embedded cairo fixes
> this. The embedded cairo version is cairo 1.0.2, while the current
> version on feisty is 1.4.2. That's a rather big difference for tracking
> the potential issues which happened between these versions. I'm
> wondering if the same issues is also affecting Fedora, it would be
> interesting to test this on core 7 (they are also using --enable-system-
> cairo).
>
> What are the arguments against using the embedded cairo version?
>

If you want to track this down, ask thebes devs on #cairo (or however
the freenode channel is called). They may have an idea as they
probably fixed it for ffox trunk already.

 - Alexander

Notes from the cairo devs for tracking this:

< cworth> If you can verify that a system-cairo of 1.0.2 works and a system-cairo of 1.4.2 doesn't, then it should be an easy process to use
                git-bisect to find the problem.
< tor_> offhand that looks possibly to be the change when cairo fixed an extents bug the 1.8-branch svg depended on
< tor_> a8ca155f83098c02fb8d3acc57b0492d5b753d54 is the likely suspect, if you're set up to experiment that way
< tor_> if that is the problem, changing moz to work with the current fixed behavior is relatively simple

Shouldn't the upstream tracker be mozilla?

Changed in firefox:
status: Unknown → In Progress

Created attachment 266077
don't depend on API bug

Since linux distributors can't seem to understand "--enable-system-cairo is unsupported", we need to change the branch SVG code to handle both the old and new API behavior of cairo_{fill,stroke}_extent.

Changed in firefox:
status: Unknown → Confirmed

What is the API bug that we don't want to depend on?

Here's the commit Tim found that fixes the API bug in question: http://gitweb.freedesktop.org/?p=cairo.git;a=commitdiff;h=a8ca155f83098c02fb8d3acc57b0492d5b753d54

"Correctly return the transformed bounding box for stroke/fill extents,
instead of just transforming the two corners separately."

Thanks Sylvain.

Comment on attachment 266077
don't depend on API bug

Linux distributors have been ignoring our advice that --enable-system-cairo is unsupported and are running Firefox against newer versions of cairo than what's in the tree. The branch svg code relied on a bug in one of the cairo APIs that has since been fixed. This patch moves similar fixes that were made to the trunk about half a year ago, and makes the code work with both old and new behavior.

Comment on attachment 266077
don't depend on API bug

approved for 1.8.1.5, a=dveditz for release-drivers

Checked in on MOZILLA_1_8_BRANCH.

Changed in firefox:
status: Confirmed → Fix Released

This is now fixed in 2.0.0.5.

Per user comments, marking Fix Released.

Changed in firefox:
status: Confirmed → Fix Released
Changed in firefox:
status: In Progress → Fix Released
Changed in firefox:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.