DO NOT REPLY New: - baseVal cannot be initialized via DOM

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=42
014>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=42014

           Summary: baseVal cannot be initialized via DOM
           Product: Batik
           Version: 1.7
          Platform: Other
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P2
         Component: SVG DOM
        AssignedTo: batik-devxmlgraphics.apache.org
        ReportedBy: x00000000freenet.de


Setting baseVal.value of an element that has been created
with DOM methods
gives SVG Error "null":

org.apache.batik.dom.svg.LiveAttributeException
	at
org.apache.batik.dom.svg.AbstractSVGAnimatedLength$BaseSVGLe
ngth.revalidate(Unknown
Source)
	at
org.apache.batik.dom.svg.AbstractSVGLength.setValue(Unknown
Source)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
	at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
ssorImpl.java:39)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
thodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.mozilla.javascript.MemberBox.invoke(Unknown Source)
	at org.mozilla.javascript.JavaMembers.put(Unknown Source)
	at org.mozilla.javascript.NativeJavaObject.put(Unknown
Source)
	at
org.mozilla.javascript.ScriptableObject.putProperty(Unknown
Source)
	at
org.mozilla.javascript.ScriptRuntime.setObjectProp(Unknown
Source)
	at
org.mozilla.javascript.ScriptRuntime.setObjectProp(Unknown
Source)
	at org.mozilla.javascript.gen.c2782._c0(Event attribute
file:/home/batik/tests/baseval.svg:8 onload:1)
	at org.mozilla.javascript.gen.c2782.call(Event attribute
file:/home/batik/tests/baseval.svg:8 onload)
	at org.mozilla.javascript.ContextFactory.doTopCall(Unknown
Source)
	at org.mozilla.javascript.ScriptRuntime.doTopCall(Unknown
Source)
	at org.mozilla.javascript.gen.c2782.call(Event attribute
file:/home/batik/tests/baseval.svg:8 onload)
	at org.mozilla.javascript.gen.c2782.exec(Event attribute
file:/home/batik/tests/baseval.svg:8 onload)
	at org.mozilla.javascript.Context.evaluateReader(Unknown
Source)
	at
org.apache.batik.script.rhino.RhinoInterpreter$2.run(Unknown
Source)
	at org.mozilla.javascript.Context.call(Unknown Source)
	at org.mozilla.javascript.ContextFactory.call(Unknown
Source)
	at
org.apache.batik.script.rhino.RhinoInterpreter.evaluate(Unkn
own Source)
	at
org.apache.batik.bridge.BaseScriptingEnvironment$1.handleEve
nt(Unknown Source)
	at
org.apache.batik.dom.events.EventSupport.fireEventListeners(
Unknown Source)
	at
org.apache.batik.dom.events.EventSupport.fireEventListeners(
Unknown Source)
	at
org.apache.batik.dom.events.EventSupport.dispatchEvent(Unkno
wn Source)
	at org.apache.batik.dom.AbstractNode.dispatchEvent(Unknown
Source)
	at
org.apache.batik.bridge.BaseScriptingEnvironment.dispatchSVG
Load(Unknown Source)
	at
org.apache.batik.bridge.BaseScriptingEnvironment.dispatchSVG
LoadEvent(Unknown
Source)
	at
org.apache.batik.bridge.UpdateManager.dispatchSVGLoadEvent(U
nknown Source)
	at
org.apache.batik.bridge.UpdateManager.dispatchSVGLoadEvent(U
nknown Source)
	at
org.apache.batik.swing.svg.SVGLoadEventDispatcher.run(Unknow
n Source)

for this document:

<?xml version="1.0"
encoding="iso-8859-1"?>
<svg xmlns="http://www.w3.org/20
00/svg" viewBox="-1 -1 3 3"
 onload='
  var root= document.rootElement;
  var elt= document.createElementNS( root.namespaceURI,
"rect" );
  elt.width.baseVal.value= 1;
  elt.height.baseVal.value= 1;
  root.appendChild( elt );
 '/>

Note that it isn't possible to use createSVGLength() first
because baseVal
is readonly (however, the actual error in Batik is
'Java class
"org.apache.batik.dom.svg.SVGOMAnimatedLength" has
no public
instance field or method named "baseVal"'), nor is
it possible to attach
the element to the document first (gives an exception on
missing required
width/height for a <rect/>).

Setting the value with setAttribute() works as expected.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=ema
il
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the
assignee.

------------------------------------------------------------
---------
To unsubscribe, e-mail: batik-dev-unsubscribexmlgraphics.apache.org
For additional commands, e-mail: batik-dev-helpxmlgraphics.apache.org

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=42
014>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=42014





------- Additional Comments From x00000000freenet.de  2007-04-01 11:13 -------
Created an attachment (id=19862)
 --> (http://issues.apache.org/bugzilla/attac
hment.cgi?id=19862&action=view)
testcase


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=ema
il
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the
assignee.

------------------------------------------------------------
---------
To unsubscribe, e-mail: batik-dev-unsubscribexmlgraphics.apache.org
For additional commands, e-mail: batik-dev-helpxmlgraphics.apache.org

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=42
014>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=42014


camapache.org changed:

           What    |Removed                     |Added
------------------------------------------------------------
----------------
             Status|NEW                         |ASSIGNED




------- Additional Comments From camapache.org  2007-04-02
17:23 -------
Yes, perhaps the checking for required attributes should be
done only when the
element is about to be actually used, so that if the element
is not in the
document the exception isn't thrown.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=ema
il
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the
assignee.

------------------------------------------------------------
---------
To unsubscribe, e-mail: batik-dev-unsubscribexmlgraphics.apache.org
For additional commands, e-mail: batik-dev-helpxmlgraphics.apache.org

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=42
014>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=42014





------- Additional Comments From x00000000freenet.de  2007-04-03 13:20 -------
Looked at the source. The whole process of setting a value
doesn't make
sense to me. It is as follows:

- AbstractSVGLength.setValue() calls
  AbstractSVGAnimatedLength$BaseSVGLength.revalidate() to
validate the *old*
  value of the corresponding attribute

- If I remove the revalidate(), AbstractSVGLength.setValue()
sets the value

- Then it calls
AbstractSVGAnimatedLength$BaseSVGLength.reset(), which
calls
  AbstractSVGLength.getValueAsString()

- AbstractSVGLength.getValueAsString() calls
  AbstractSVGAnimatedLength$BaseSVGLength.revalidate() to
validate the *old*
  value of the corresponding attribute

- If I remove the revalidate(),
  AbstractSVGAnimatedLength$BaseSVGLength.reset() finally
sets the
  corresponding attribute to the new value (without
validation)

- The bridge is notified about the new element when it is
put into the
  document

- SVGRectElementBridge.buildShape() calls
AbstractSVGLength.getValue()

- AbstractSVGLength.getValue() calls
  AbstractSVGAnimatedLength$BaseSVGLength.revalidate() to
validate the value
  of the corresponding attribute (i.e. parses it and
calculates the value)

Note that the final validation will be bypassed if the *old*
value was valid
(reset() inhibits the call of invalidate() in
attrChanged()), i.e. this does
not throw an exception:

  var root= document.rootElement;
  var elt= document.createElementNS( root.namespaceURI,
"rect" );
  elt.setAttribute( "width", 1 );
  elt.setAttribute( "height", 1 );
  elt.width.baseVal.value= -1;
  root.appendChild( elt );

IMHO, validation should happen explicitly in
SVG*ElementBridge.buildShape()
and nowhere else. Synching of XML attribute and SVG DOM
values should be
separate from this. Also consider code like this, which
should work if the
element isn't attached to the document yet:

  myWidth.value= someFunctionThatMayReturnNegativeValues();
  if ( myWidth.value < minimumWidth ) myWidth.value=
minimumWidth;

The SVG 1.1 spec says in B.7:

  If a script sets a DOM attribute to an invalid value
(e.g., a negative
  number for an attribute that requires a non-negative
number or an
  out-of-range value for an enumeration), unless this
specification
  indicates otherwise, no exception shall be raised on
setting, but the
  given document fragment shall become technically in error
as described in
  Error processing.

And in F.2:

  Because of situations where a block of scripting changes
might cause a
  given SVG document fragment to go into and out of error,
error processing
  shall occur only at times when document presentation
(e.g., rendering to
  the display device) is updated. In particular, error
processing shall be
  disabled whenever redraw has been suspended via DOM calls
to
  suspendRedraw().

BTW, AbstractSVGLength.parse() catches ParseException and
sets the length to
0 unknown units. AbstractSVGLength.getValue() then returns 0
with this
comment:

            // XXX Should we throw an exception here when
the length
            //     type is unknown?

The answer is "no", but validation at rendering
time should check for
invalid units.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=ema
il
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the
assignee.

------------------------------------------------------------
---------
To unsubscribe, e-mail: batik-dev-unsubscribexmlgraphics.apache.org
For additional commands, e-mail: batik-dev-helpxmlgraphics.apache.org

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=42
014>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=42014





------- Additional Comments From x00000000freenet.de  2007-04-03 13:55 -------
The behavior of newValueSpecifiedUnits() is even worse:

  elt.setAttribute( "width", 1 );
  elt.width.baseVal.newValueSpecifiedUnits(
    elt.width.baseVal.SVG_LENGTHTYPE_NUMBER, 2 );

This results in width still being 1 because
newValueSpecifiedUnits() does
not call revalidate(), so the other call to revalidate() in
reset() resp.
getValueAsString() actually validates the value that has
been set before
in setAttribute() and replaces the new value with the old
value.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=ema
il
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the
assignee.

------------------------------------------------------------
---------
To unsubscribe, e-mail: batik-dev-unsubscribexmlgraphics.apache.org
For additional commands, e-mail: batik-dev-helpxmlgraphics.apache.org

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=42
014>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=42014





------- Additional Comments From camapache.org  2007-04-03
17:26 -------
Thanks for the detailed analysis.

> - AbstractSVGLength.setValue() calls
>   AbstractSVGAnimatedLength$BaseSVGLength.revalidate()
to validate the *old*
>   value of the corresponding attribute

Hmm, yes it seems that calling revalidate() before any set
method serves no
useful purpose.

> Note that the final validation will be bypassed if the
*old* value was valid
> (reset() inhibits the call of invalidate() in
attrChanged()), i.e. this does
> not throw an exception:

You're right.  I wonder why.

> IMHO, validation should happen explicitly in
SVG*ElementBridge.buildShape()
> and nowhere else. Synching of XML attribute and SVG DOM
values should be
> separate from this.

Agreed.  I'll probably put an explicit, public validate
method on the value
objects that the bridge calls just before it uses those
values to build the
graphics objects.  This will allow different error-handling
behaviour for the
bridge and script.

> Also consider code like this, which should work if the
> element isn't attached to the document yet:
> 
>   myWidth.value=
someFunctionThatMayReturnNegativeValues();
>   if ( myWidth.value < minimumWidth ) myWidth.value=
minimumWidth;

Yes, according to the bits of the spec you quoted this
should be allowed.

> BTW, AbstractSVGLength.parse() catches ParseException
and sets the length to
> 0 unknown units. AbstractSVGLength.getValue() then
returns 0 with this
> comment:
> 
>             // XXX Should we throw an exception here
when the length
>             //     type is unknown?
> 
> The answer is "no", but validation at
rendering time should check for
> invalid units.

I think there is a case for throwing an exception here. 
getValue() is meant to
return the length value in user units.  If the unit type is
invalid, because of
a weird DOM attribute value (or doing a
.newValueSpecifiedUnits() with an
invalid unit type), there's no way to convert it to user
units.  It's not clear
whether some value should be returned or an exception should
be thrown. 
(Actually, the spec is clear that getValue() doesn't throw
an exception, but I
think it should either be changed to throw or clarified to
say what value is
returned.)

> The behavior of newValueSpecifiedUnits() is even
worse:
> 
>   elt.setAttribute( "width", 1 );
>   elt.width.baseVal.newValueSpecifiedUnits(
>     elt.width.baseVal.SVG_LENGTHTYPE_NUMBER, 2 );
> 
> This results in width still being 1 because
newValueSpecifiedUnits() does
> not call revalidate(), so the other call to
revalidate() in reset() resp.
> getValueAsString() actually validates the value that
has been set before
> in setAttribute() and replaces the new value with the
old value.

Yes, that seems to be broken, too, but only for elements not
in the document.

I'll take a look at all of this over the easter break.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=ema
il
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the
assignee.

------------------------------------------------------------
---------
To unsubscribe, e-mail: batik-dev-unsubscribexmlgraphics.apache.org
For additional commands, e-mail: batik-dev-helpxmlgraphics.apache.org

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=42
014>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=42014





------- Additional Comments From x00000000freenet.de  2007-04-05 17:58 -------
(In reply to comment #5)
> > Note that the final validation will be bypassed if
the *old* value was valid
> > (reset() inhibits the call of invalidate() in
attrChanged()), i.e. this does
> > not throw an exception:
> 
> You're right.  I wonder why.

Probably this has been copied from simpler cases like
SVGOMAnimatedNumber.setBaseVal() without enough thinking. It
assumes that
the value has just been validated resp. synced with the
attribute, but that
isn't true here because revalidate() validates the *old*
value.

> I think there is a case for throwing an exception here.
 getValue() is meant to
> return the length value in user units.  If the unit
type is invalid, because of
> a weird DOM attribute value (or doing a
.newValueSpecifiedUnits() with an
> invalid unit type), there's no way to convert it to
user units.  It's not clear
> whether some value should be returned or an exception
should be thrown. 
> (Actually, the spec is clear that getValue() doesn't
throw an exception, but I
> think it should either be changed to throw or clarified
to say what value is
> returned.)

Ok, the spec also says: "It is invalid to attempt to
define a new value of
this type". This might mean that anything could happen.
And "attempt" may
imply that it won't succeed.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=ema
il
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the
assignee.

------------------------------------------------------------
---------
To unsubscribe, e-mail: batik-dev-unsubscribexmlgraphics.apache.org
For additional commands, e-mail: batik-dev-helpxmlgraphics.apache.org

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=42
014>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=42014





------- Additional Comments From camapache.org  2007-04-10
21:33 -------
I've just committed some changes to the LiveAttributeValue
stuff.  Please try it
and let me know if it behaves as you expect it should.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=ema
il
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the
assignee.

------------------------------------------------------------
---------
To unsubscribe, e-mail: batik-dev-unsubscribexmlgraphics.apache.org
For additional commands, e-mail: batik-dev-helpxmlgraphics.apache.org

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=42
014>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=42014


camapache.org changed:

           What    |Removed                     |Added
------------------------------------------------------------
----------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=ema
il
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the
assignee.

------------------------------------------------------------
---------
To unsubscribe, e-mail: batik-dev-unsubscribexmlgraphics.apache.org
For additional commands, e-mail: batik-dev-helpxmlgraphics.apache.org