373960 - Percentage width/height on <svg> in XUL doesn't work

Status: RESOLVED WONTFIX

(Core :: SVG, defect)

Description

[Jonathan Watt [:jwatt]]

Attachment: testcase

Percentage width/height on <svg> in XUL stopped working after the reflow branch landing. I guess we probably need to fix bug 280923 to get this working.

Comment 1

[Jonathan Watt [:jwatt]]

Or maybe it was a bug that it worked in the first place? I'm not exactly sure how the XUL box model/CSS layout model is supposed to interact when one touches the other.

Comment 2

[Jonathan Watt [:jwatt]]

Attachment: testcase - div in XUL

I can't seem to get things working as I'd expect them to for a <div> in XUL, either before or after the reflow branch landing.

Comment 3

[Neil Deakin]

XUL box frames ignore percentages on their children, so the behaviour before may have been due to svg frame code using the width/height in some way to affect the preferred size which it isn't doing now.

The svg testcase gives a number of assertions in svg code, related to bug 367031.

Comment 4

[Jonathan Watt [:jwatt]]

Thanks Neil. So what's the correct way(s) to get a non-XUL element to fill its parent XUL element's area?

BTW, the SVG assertion:

###!!! ASSERTION: XXX. We shouldn't get here. Viewbox width/height is set to 0.
lay of element as per specs.: 'Error', file c:/mozilla/trees/trunk/mozilla/conte
sSVGSVGElement.cpp, line 1248

is just a side affect of the 100% values computing to zero.

Comment 5

[Jonathan Watt [:jwatt]]

Note that -moz-available and the other new values for the width property don't work either.

Comment 8

[jonathan chetwynd]

#7 Robert, is Core/SVG the right place to get this resolved?

might toolkit/xulrunner (Bug 484947) connect with non-svg folk?

seems to me this is unlikely to be an SVG issue...

Comment 9

[Robert Longson [:longsonr]]

I've don't know what the right place is. toolkit/xulrunner is definitely wrong though, it's either core/SVG or core/XUL.

Comment 10

[jonathan chetwynd]

moving to XUL as it's clearly not plain SVG, and it's been here two years...

Comment 11

[Robert Longson [:longsonr]]

Moving back to SVG since it already has a XUL bug as a dependency.

Comment 12

[galmok]

Would this bug be the same that prevents the route from showing on Garmin Connect with Firefox 9.0a1? Example path is here:

http://connect.garmin.com/activity/108993784

The SVG code seems to be inserted dynamically depending on map zoom/pan but the svg is created with width and height set to 100% which produces a too small area for the path to be shown in. Using the builtin Webdeveloper/Inspect tool, the SVG tag and its parent tags are easily found. Changing "100%" to the size of the parent makes the whole route visible. Needless to say, this works fine in Firefox 3.6, Opera and Chrome.

Comment 13

[Martijn Wargers (dead)]

galmok, that sounds like a completely different bug to me. File a new bug?

Comment 14

[Daniel Holbert [:dholbert]]

Galmok, I suspect that what you're describing might be an intended result of Bug 611099's patch.  (Let's not discuss it any more here, though -- better to discuss it on a new bug, on Bug 611099, or on a newsgroup.)

Comment 15

[Robert Longson [:longsonr]]

XUL is obsolete now.