Last Comment Bug 342513 - [SVGSVGElement].width.baseVal.value returns 1 for 100% wide SVG
: [SVGSVGElement].width.baseVal.value returns 1 for 100% wide SVG
Status: RESOLVED DUPLICATE of bug 1283539
: regression, testcase
Product: Core
Classification: Components
Component: SVG (show other bugs)
: Trunk
: All All
: -- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
Depends on: 530985
Blocks: 1283539
  Show dependency treegraph
 
Reported: 2006-06-23 03:23 PDT by Arpad Borsos [:Swatinem]
Modified: 2016-07-25 07:49 PDT (History)
7 users (show)
longsonr: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase that prints the width of a 100% wide svg (991 bytes, application/xhtml+xml)
2006-06-23 07:14 PDT, Arpad Borsos [:Swatinem]
no flags Details
pure svg testcase - click on red (403 bytes, image/svg+xml)
2006-06-23 09:06 PDT, tor
no flags Details
make nsSVGLength2 handle a outersvg context (2.16 KB, patch)
2007-03-13 09:50 PDT, tor
no flags Details | Diff | Splinter Review
missed header file (3.50 KB, patch)
2007-03-16 09:12 PDT, tor
no flags Details | Diff | Splinter Review
mochitest for embedded testcase (1.83 KB, patch)
2008-07-14 07:12 PDT, Arpad Borsos [:Swatinem]
jwatt: review+
Details | Diff | Splinter Review
reftest for convertToSpecifiedUnits (2.00 KB, patch)
2008-07-14 07:48 PDT, Arpad Borsos [:Swatinem]
no flags Details | Diff | Splinter Review
updated mochitest (2.30 KB, patch)
2008-07-14 13:58 PDT, Arpad Borsos [:Swatinem]
no flags Details | Diff | Splinter Review
mochitest updated to tip with invalid test removed (2.45 KB, patch)
2009-02-23 08:33 PST, Robert Longson
no flags Details | Diff | Splinter Review

Description Arpad Borsos [:Swatinem] 2006-06-23 03:23:32 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a3) Gecko/20060622 BonEcho/2.0a3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a3) Gecko/20060622 BonEcho/2.0a3

[SVGSVGElement].width.baseVal.value returns 1 for a 100% wide SVG.
This bug only occurs in a recent trunk build width gecko 1.9. It works flawlessly width a 1.8 branch build.
[SVGSVGElement].viewBox.baseVal.width returns the correct width however.

Reproducible: Always

Steps to Reproduce:
retrieve the value of [SVGSVGElement].width.baseVal.value
Actual Results:  
1

Expected Results:  
the correct width in pixels, e.g. 1158
Comment 1 tor 2006-06-23 05:54:30 PDT
Do you have a testcase you can attach?
Comment 2 Arpad Borsos [:Swatinem] 2006-06-23 07:14:19 PDT
Created attachment 226785 [details]
testcase that prints the width of a 100% wide svg

I've just created a simple testcase. This prints out the svgDoc.width.baseVal.value and svgDoc.viewBox.baseVal.width values of a svg with width="100%".
The two values match on a branch build. A trunk build outputs 1 for svgDoc.width.baseVal.value.
Opera does not support the viewBox method at all.
This bug breaks my SVGraph examples at http://swatinemz.sourceforge.net/svgraph.xhtml
Comment 3 tor 2006-06-23 09:06:18 PDT
Created attachment 226795 [details]
pure svg testcase - click on red
Comment 4 tor 2006-06-23 09:18:05 PDT
Some results of testing - seems like little agreement:

FF 1.5:

        width.baseVal.value   = pixel width of area
        viewBox.baseVal.width = pixel width of area

FF trunk:

        width.baseVal.value   = 1
        viewBox.baseVal.width = pixel width of area

Opera 9:

        width.baseVal.value   = pixel width of area
        viewBox.baseVal.width = 0

Batik 1.6:

        width.baseVal.value   =  pixel width of area
        viewBox.baseVal.width =  <"getViewBox not implemented">

Adobe SVG Viewer 3.0:

        width.baseVal.value   = <"null or not an object">
        viewBox.baseVal.width = <"null or not an object">
Comment 5 Arpad Borsos [:Swatinem] 2007-03-13 00:24:59 PDT
Todays build regressed some more. I don't know which checkin caused it but it now outputs the following:
svgDoc.width.baseVal.value = 1
svgDoc.viewBox.baseVal.width = 0
That means there is currently no way to get the actual width of a 100% wide SVG with scripting :(
Comment 6 tor 2007-03-13 09:50:43 PDT
Created attachment 258429 [details] [diff] [review]
make nsSVGLength2 handle a outersvg context

This doesn't reliably fix the HTML testcase attached to this bug, as the load event appears to fire before the first reflow, which sets up the outer svg dimensions.  Not sure if that is per spec or not (the random values due to an uninitialized variable before the first reflow definitely aren't, but that's trivial to fix once we decide what the appropriate behavior should be).
Comment 7 tor 2007-03-16 09:12:52 PDT
Created attachment 258792 [details] [diff] [review]
missed header file
Comment 8 Arpad Borsos [:Swatinem] 2008-07-14 07:12:28 PDT
Created attachment 329442 [details] [diff] [review]
mochitest for embedded testcase

I wrote a mochitest for the embedded testcase to practice writing mochitests.
Something else I noticed while playing with firebug:
>>> document.getElementById('svg').width.baseVal.newValueSpecifiedUnits(5,100) // set value to 100px
>>> document.getElementById('svg').width.baseVal.convertToSpecifiedUnits(2) // convert to percentage
>>> document.getElementById('svg').width.baseVal.value
100 // value is always in "user units" according to spec. "user units" is always equal to pixels?
>>> document.getElementById('svg').width.baseVal.valueAsString
"10000%" // this is wrong

The SVGLength implementation somehow uses a fixed conversion ratio of 100 from "user units" (pixels) to percentage. The embedded SVG actually grows when I use the convertToSpecifiedUnits method.
Comment 9 Jonathan Watt [:jwatt] (back in October - email directly if necessary) 2008-07-14 07:35:05 PDT
Ah, crap. We shipped with this broken? :-(

Thanks a lot for the mochitest Arpad! It looks good to me.
Comment 10 Arpad Borsos [:Swatinem] 2008-07-14 07:48:37 PDT
Created attachment 329453 [details] [diff] [review]
reftest for convertToSpecifiedUnits

This is a reftest which tests the bug that the SVG is growing when using the convertToSpecifiedUnits method. I hope I've done that right, I didn't get the reftests to start :(
Comment 11 Jonathan Watt [:jwatt] (back in October - email directly if necessary) 2008-07-14 08:21:14 PDT
The basic problem here is our use of nsSVGElement::GetCtx which returns an nsSVGSVGElement* to the ancestor element that provides the coordinate context for the element on which it is called. Unfortunately there's no such ancestor for <svg> elements that are the root of an SVG document fragment, so GetCtx returns null. GetAxisLength then falls back to returning 1 when it doesn't get a context, so GetUnitScaleFactor returns 100 and we get 100/100 in nsSVGValue2::GetBaseValue.
Comment 12 Jonathan Watt [:jwatt] (back in October - email directly if necessary) 2008-07-14 08:25:36 PDT
Arpad: does that reftest actually fail currently? I thought this bug was only for percentage width/height on the rootmost <svg>. Besides that, it's preferable to get rid of the -ref file and just compare to pass.svg if possible. You can hopefully do that if you set the margin, border and padding on the html and body elements to none. Also, better to use convertToSpecifiedUnits(nsSVGLength.<ENUM_CONSTANT>) instead of convertToSpecifiedUnits(2). I've no idea offhand what 2 is. :-)
Comment 13 Arpad Borsos [:Swatinem] 2008-07-14 09:33:02 PDT
I will post an updated reftest if I can get this reftest infrastructure to run correctly.
Comment 14 Robert Longson 2008-07-14 12:14:59 PDT
I think this would be better as a mochitest. It's the output of convertToSpecifiedUnits that you are trying to test. What gets rendered is a side effect.
Comment 15 Arpad Borsos [:Swatinem] 2008-07-14 13:58:14 PDT
Created attachment 329540 [details] [diff] [review]
updated mochitest

This also tests the behavior of convertToSpecifiedUnits and friends.

Why does mozilla use SpecifiedUnits internaly and converts them to user units on every access to .value and not the other way around?

I also noticed that besides GetAxisLength also GetMMPerPixel always returns 1.
Comment 16 Robert Longson 2009-02-22 11:10:03 PST
Patch in bug 361920 fixes this so that we're compatible with Opera.
Comment 17 Robert Longson 2009-02-23 07:42:13 PST
Fixed by check in for bug 361920
Comment 18 Robert Longson 2009-02-23 08:33:32 PST
Created attachment 363687 [details] [diff] [review]
mochitest updated to tip with invalid test removed
Comment 19 Robert Longson 2009-02-23 12:58:33 PST
checked in http://hg.mozilla.org/mozilla-central/rev/bbbe69d822c0
Comment 20 Robert Longson 2014-07-09 00:54:20 PDT
Use getBoundingClientRect if you want to get the pixel width of an <svg> element.
Comment 21 Erik Haukjær Andersen 2016-07-04 01:57:45 PDT Comment hidden (off-topic)
Comment 22 Robert Longson 2016-07-25 07:49:02 PDT

*** This bug has been marked as a duplicate of bug 1283539 ***

Note You need to log in before you can comment on or make changes to this bug.