364732 - SVG in XUL is broken (not displayed)

Status: RESOLVED WORKSFORME

(Core :: SVG, defect, P2)

Description

[Arpad Borsos [:Swatinem]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20061219 Minefield/3.0a2pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20061219 Minefield/3.0a2pre

Embedding SVG in XUL and using <canvas> in XUL does not work correctly.
Just open the testcase i will attach.

Other examples of SVG not displaying in XUL:
http://starkravingfinkle.org/blog/wp-content/uploads/2006/12/svg-in-xul-lion.xul
http://starkravingfinkle.org/blog/wp-content/uploads/2006/12/svg-in-xul-parrot.xul

All of these examples work correctly in Gecko 1.8.
I hope the Component is the right one. I didn't know if i should file this against XUL, SVG or <canvas>...

Reproducible: Always

Steps to Reproduce:
Open the testcase.
Actual Results:  
Nothing is drawn. After removing the borders from the xul:box the svg is drawn but not the canvas.

Expected Results:  
Both should be drawn with and without borders on the xul:box.

Comment 1

[Arpad Borsos [:Swatinem]]

Attachment: testcase

Try to toggle borders on/off. The SVG displays without the borders.

Comment 2

[Neil Deakin]

Recent regression, since Nov 22 or so, likely the reflow branch.

Comment 3

[Dave Townsend [:mossop]]

Confirming this, the canvas examples at http://starkravingfinkle.org/blog/2007/01/xul-clippings-canvas/ all do not display.

Comment 5

[:Gavin Sharp [email: [e-mail]]]

Works in a build from before the reflow branch landing, doesn't work in a build from right after.

Comment 6

[jonathan chetwynd]

oops,

forgot to search first, thanks and apologies for dupe.

Comment 7

[Jonathan Watt [:jwatt]]

The testcase linked in the URL field has been fixed by the checkin for bug 367031. The testcases linked to in comment 0 have been worked around by Mark by adding flex="1" to the root <svg> tags in his examples, but the regression is still there. According to Neil the flex attribute should not be necessary (see bug 367031 comment 2). The problem with the canvas examples cannot be worked around by adding flex="1" unfortunately.

Comment 8

[Boris Zbarsky [:bzbarsky]]

This worksforme, both on the testcase and on the links from comment 0 (with the flex="1" removed from them).  Anyone else still seeing this on current trunk?

Comment 9

[Martijn Wargers (dead)]

The testcases here are worksforme.
However, I can still see the issue with: https://bugzilla.mozilla.org/attachment.cgi?id=234801

Comment 10

[jonathan chetwynd]

from dupe bug: https://bugzilla.mozilla.org/show_bug.cgi?id=275254
which has more detail...
fill at least may be broken 

https://bugzilla.mozilla.org/attachment.cgi?id=169094
the button is the wrong height
the fill is only present on event

https://bugzilla.mozilla.org/attachment.cgi?id=169109
the fill box is different to the button
incidentally mozilla crashed when I clicked this button.

Comment 11

[Boris Zbarsky [:bzbarsky]]

> However, I can still see the issue with:
> https://bugzilla.mozilla.org/attachment.cgi?id=234801

There's no size set on that <svg> element.  So we size it to be 0x0.  I think that's correct per the spec, but worth checking.

Comment 12

[Jonathan Watt [:jwatt]]

(In reply to comment #11)
> There's no size set on that <svg> element.  So we size it to be 0x0.  I think
> that's correct per the spec, but worth checking.

No, it should default to a width and height of 100%, meaning "100% of the available space". Anyway, it (attachment 234801 [details]) does seem to work now so I guess this is worksforme.

I've checked in a reftest for this at mozilla/layout/reftests/svg/inline-in-xul-basic-01.xul

Comment 13

[Martijn Wargers (dead)]

(In reply to comment #12)
> No, it should default to a width and height of 100%, meaning "100% of the
> available space". Anyway, it (attachment 234801 [details]) does seem to work now so I
> guess this is worksforme.

It doesn't seem to work for me, using:
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a8pre) Gecko/2007082019 Minefield/3.0a8pre
What are you seeing with that testcase? I'm just getting a blank page, which is incorrect, according to you.

Comment 14

[Jonathan Watt [:jwatt]]

Ignore me, I'm an idiot. I was testing with the wrong tree.

Comment 15

[Bill Gianopoulos [:WG9s]]

(In reply to comment #14)
> Ignore me, I'm an idiot. I was testing with the wrong tree.
> 

Strange.  It works for me with:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007082105 Minefield/3.0a8pre

Comment 16

[Bill Gianopoulos [:WG9s]]

Oh i see.  nevermind.  All the testcases on this bug work but an attachment on a different bug still fails.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Sounds like an SVG bug, then, not core layout.

Comment 18

[Boris Zbarsky [:bzbarsky]]

Er... so why is the test that was checked in failing on mac?  And passing on other platforms?

Comment 19

[Jonathan Watt [:jwatt]]

It's not, it's failing on all platforms. I was confused. And yes, this is an SVG issue which is fixed by the code I'm working on for bug 294086.

Comment 20

[Jonathan Watt [:jwatt]]

So the fix for bug 294086 didn't help fix the remaining issues here. According to Neil (in bug 373960 comment 3) XUL box frames ignore percentages on their children. This seems to be the source of all the remaining problems with the examples mentioned on this bug. Note that HTML <div> with percentage width/height has the same problems in XUL as SVG.

Since we don't know what fixed the issues that disappeared months ago, I'll close this bug as WORKSFORME. Anyone interested in any remaining problems with SVG in XUL, please CC yourself on bug 373960. (This current bug is now too fragmented to work with, so if you think that bug 373960 doesn't cover an issue that you're seeing, please open another bug and CC me.)