You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by bu...@apache.org on 2010/01/17 21:51:47 UTC
DO NOT REPLY [Bug 48561] New: clicking links in applet crashes
browser
https://issues.apache.org/bugzilla/show_bug.cgi?id=48561
Summary: clicking links in applet crashes browser
Product: Batik
Version: 1.8
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: SVG DOM
AssignedTo: batik-dev@xmlgraphics.apache.org
ReportedBy: chris@bodar.com
Will post an example tomorrow but I haev been playing offline with you applet
example and if you click on any element with xlink:href="{url}" it crashes the
browser rather than navigates to the url.
This may be 'expected' behavior as clearly the applet demo is of the simplest
form - if this is the case a couple of pointers as to the 'correct' way of
correcting it would be really helpful (I'm a relative newcomer to Java from an
XML/XSLT/XHTML/Javascript background so aplogies)
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
DO NOT REPLY [Bug 48561] clicking links in applet crashes browser
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48561
Helder Magalhães <he...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--- Comment #2 from Helder Magalhães <he...@gmail.com> 2010-01-19 15:40:00 UTC ---
(In reply to comment #1)
> This does not occur on every machine I've tested with but quite a few (firefox
> and IW when it occurs) . However importing the batik-gui-util.jar seem to
> prevent the crash so presumably it's that error that causes the problem rather
> than the security problem.
I'm not sure how it was assumed that the jar could be left out. It's even used
in the demo [1]... ;-)
> Not ideal to have the error popup is it possible to
> handle the error console exception by checking for the classes presence?
I guess not that way, but you probably can reimplement code so that the error
pop-up is displayed differently. Note that the error pop-up is used for
displaying... Errors! :-) So you probably don't want (in most cases, that is)
simply discard them. You (and/or your users) will want to be informed so the
erroneous content can be fixed.
Note that I'm having extreme difficulty in trying to imagine a bug from this
report. I'm much more inclined to marking it "invalid", but I'm marking it as
"need info" so that more information is added which can then turn this into a
bug report [2]. Please update with more info or close the issue accordingly!
:-)
Finally, the most updated sources [3] contains a fix which solved a security
problem which forced applets to be signed. In the mean time, my current guess
goes to security policy issues, not related to Batik...
[1] http://xmlgraphics.apache.org/batik/demo.html
[2] http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
[3] http://xmlgraphics.apache.org/batik/download.cgi#Subversion+repository
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
DO NOT REPLY [Bug 48561] clicking links in applet crashes browser
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48561
Christian Bodart <ch...@bodar.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
--- Comment #3 from Christian Bodart <ch...@bodar.com> 2010-01-25 08:24:55 UTC ---
Not sure what you mean by the demo containing the batik-gui-util - certainly
not the one in my cache!!! 8-)
<applet archive="batik-awt-util.jar,
batik-bridge.jar, batik-css.jar,
batik-dom.jar, batik-ext.jar,
batik-gvt.jar, batik-parser.jar,
batik-svg-dom.jar,
batik-script.jar, batik-swing.jar,
batik-util.jar, batik-xml.jar,
xml-apis-dom3.jar" code="AppletDemo.class" codebase="demo/"
height="300" mayscript="mayscript" width="400" id="chart">
But I take your point.
I'm capturing the event, changing the host page's location and stopping the
applet to prevent the error wherever possible (it still seems to cause the odd
exception on disposal but hey) So I guess it should be ruled out as a bug -
surely though there should be a silent/console only error reporting flag or
similar - my users would think they had a virus if they saw exceptions like
that.
So I guess the bug is simply the absence of the jar in the demo page!
Thanks for your time
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
DO NOT REPLY [Bug 48561] clicking links in applet crashes browser
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48561
--- Comment #4 from Helder Magalhães <he...@gmail.com> 2010-01-25 16:15:13 UTC ---
(In reply to comment #3)
> Not sure what you mean by the demo containing the batik-gui-util - certainly
> not the one in my cache!!! 8-)
Yup, you are right. My bad. I guess the demo wasn't made to handle errors but
more towards being simple and download friendly. ;-)
> But I take your point.
>
> I'm capturing the event, changing the host page's location and stopping the
> applet to prevent the error wherever possible (it still seems to cause the odd
> exception on disposal but hey) So I guess it should be ruled out as a bug -
> surely though there should be a silent/console only error reporting flag or
> similar - my users would think they had a virus if they saw exceptions like
> that.
Thing is, SVG's error processing [1] states that the object should stop
rendering whenever an error occurs and stuff like that, which makes it
necessary to warn the author/user whenever bad content is detected; else the
user might be tricked into a situation where he feels that everything is as
expected when it may not even have completely loaded! (Imagine a broken script,
for example).
So the errors in your case are probably just content errors. I'd ask (again)
that you'd confirm that and, if the errors are unexpected, to attach test cases
to this bug.
> So I guess the bug is simply the absence of the jar in the demo page!
I'm not sure, given that it's a demo (i.e., "batik-gui-util.jar" is not even
there). I'm considering building a wiki page with more information on how to
assemble a standard Batik-based applet, though... ;-)
Does keeping this issue open still makes sense?
[1] http://www.w3.org/TR/SVG/implnote.html#ErrorProcessing
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
DO NOT REPLY [Bug 48561] clicking links in applet crashes browser
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48561
--- Comment #1 from Christian Bodart <ch...@bodar.com> 2010-01-18 04:21:15 UTC ---
This does not occur on every machine I've tested with but quite a few (firefox
and IW when it occurs) . However importing the batik-gui-util.jar seem to
prevent the crash so presumably it's that error that causes the problem rather
than the security problem. Not ideal to have the error popup is it possible to
handle the error console exception by checking for the classes presence?
Java Plug-in 1.6.0_18
Using JRE version 1.6.0_18-b07 Java HotSpot(TM) Client VM
User home directory = C:\Documents and Settings\chrisbod
----------------------------------------------------
c: clear console window
f: finalize objects on finalization queue
g: garbage collect
h: display this help message
l: dump classloader list
m: print memory usage
o: trigger logging
q: hide console
r: reload policy configuration
s: dump system and deployment properties
t: dump thread list
v: dump thread stack
x: clear classloader cache
0-5: set trace level to <n>
----------------------------------------------------
java.lang.NoClassDefFoundError: org/apache/batik/util/gui/JErrorPane
at
org.apache.batik.swing.JSVGCanvas$CanvasUserAgent.displayError(JSVGCanvas.java:1124)
at
org.apache.batik.swing.svg.AbstractJSVGComponent$BridgeUserAgentWrapper.displayError(AbstractJSVGComponent.java:2347)
at
org.apache.batik.swing.svg.AbstractJSVGComponent$SVGListener.documentLoadingFailed(AbstractJSVGComponent.java:1486)
at
org.apache.batik.swing.svg.SVGDocumentLoader$4.dispatch(SVGDocumentLoader.java:161)
at
org.apache.batik.util.EventDispatcher.dispatchEvent(EventDispatcher.java:103)
at org.apache.batik.util.EventDispatcher.fireEvent(EventDispatcher.java:87)
at org.apache.batik.util.EventDispatcher$1.run(EventDispatcher.java:46)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Caused by: java.lang.ClassNotFoundException:
org.apache.batik.util.gui.JErrorPane
at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
... 15 more
Caused by: java.io.FileNotFoundException:
E:\AndAgain\batik\org\apache\batik\util\gui\JErrorPane.class (The system cannot
find the path specified)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(Unknown Source)
at java.io.FileInputStream.<init>(Unknown Source)
at sun.net.www.protocol.file.FileURLConnection.connect(Unknown Source)
at sun.net.www.protocol.file.FileURLConnection.getInputStream(Unknown
Source)
at sun.plugin2.applet.Applet2ClassLoader.getBytes(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader.access$000(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
... 18 more
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
DO NOT REPLY [Bug 48561] clicking links in applet crashes browser
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48561
Christian Bodart <ch...@bodar.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #5 from Christian Bodart <ch...@bodar.com> 2010-01-26 03:37:45 UTC ---
No, I guess not the behaviour is correct.
PS
If you are thinking of creating an applet wiki page - ive been playing with
making an applet duplicate Mozilla's implementation and ASV.
I've come across the following problems so far:
Right-clicking (popuptriggering) a link fires a link activation event and loads
the link into the applet (if it's from the right domain ) - I can't seem to
overrride this behaviour pleasantly (and find it an odd behaviour TBH) .
Hooking into the actual document Events is no good as there are too many edge
cases with scripting to guarantee correct behaviour (although maybe right click
detection might be safe)
Since I can't detect popupTrigger in the linkactivation event I guess I'll have
to look elsewhere to intercept the event (i'm currently trying to glasspane the
applet to introduce a context menu but this seesm to be failing for me -
despite not routing the event beyond the glasspane the SVGCanvas seems to be
picking up the right click - I guess the layering is more interesting than I
bargained or I'm just stupid)
Finally there's no meaningful way of implementing getSVGDocument/providing
Mozilla/ASV style DOM scripting from the host page as it looks like scripting
Rhino wrapped objects in applets from a browser won't work and obviously
returning the Java SVOGDocument provides a different interface to the document
anyway
PS I am a stupid noob to Java so I often speak nonsense
Christian
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org