Draggable method onMouseMove problem wrong detection SVG

Draggable method onMouseMove has comment

Code:

---

// elem.getClassName throwing GWT exception when dragged widget is over        // SVG / VML

---

I use third party JS library leaflet, drawing polyline with svg. Exception raised when over polyline.

GXT version 3.0.1

Workaround or fix
change in Draggable condition error and add try catch

Code:

---

    // elem.getClassName throwing GWT exception when dragged widget is over
    // SVG / VML
    if (hasAttribute(elem, "class")) {
      String cls = ((Element) event.getEventTarget().cast()).getClassName();
      if (cls != null && cls.contains("x-insert")) {
        return;
      }
    }

---

to

Code:

---

        // elem.getClassName throwing GWT exception when dragged widget is over
        // SVG / VML
        if (hasAttribute(elem, "class")) {
            try {
                final String cls = ((Element) event.getEventTarget().cast()).getClassName();
                if (cls != null && cls.contains("x-insert")) {
                    return;
                }
            } catch (final Exception e) {


            }
        }

---

I wonder if you can provide an example? That is a very odd situation where
a) the element has a class, but
b) if you ask for the class, you will get an exception.

This block of code seems consistent - can you share the stack trace, and a working test case of the bug?

Here is example maven project, printscreen and stackstrace.

Yikes! The SVG library you are using is modifying DOM elements (specifically SVG elements) and giving them a property called "class", which, instead of containing a String like every other DOM element, has an Object? Is every css class-matching library supposed to be riddled with slow try/catch blocks to protect against this?

I briefly wandered the source of leaflet-src.js, and within the SVG code found these - all of which appear to be setting strings, not objects:

in L.Path, line 3961:

Code:

---

                this._path.setAttribute('class', 'leaflet-clickable');

---

in L.Map, lines 4011 and 4018:

Code:

---

                this._pathRoot.setAttribute('class', ' leaflet-zoom-animated');

---

Code:

---

                this._pathRoot.setAttribute('class', ' leaflet-zoom-hide');

---

Later references appear to be in VML-specific blocks, replacing the L.Path impl, so don't apply (since you are getting this issue in Firefox). Why are you getting a JavaScriptObject then inside GWT's Element.getClassName (note: this 'bug' is happening inside GWT, not in GXT)?

Okay, so leaflet.js is apparently behaving - why are we seeing objects instead of strings?

Debugging the app, the error is apparently because the in line 4011 above, the class is set on the SVG element, but when the same value is read back out again, the value is now a SvgAnimatedString object - probably so the value can be animated, along with all other properties of the svg element. This seems to be the browser itself performing this transformation.

Nothing ever seems to read this value back out again though, so why is the class being set in the first place? The leaflet library might have some use for it - zooming, apparently - and indeed if the class is removed, the zooming css no longer functions correctly.

The method that is failing in GWT itself:

Code:

---

  /**
  * The class attribute of the element. This attribute has been renamed due to
  * conflicts with the "class" keyword exposed by many languages.
  *
  * @see <a
  *      href="http://www.w3.org/TR/1999/REC-html401-19991224/struct/global.html#adef-class">W3C
  *      HTML Specification</a>
  */
  public final native String getClassName() /*-{
    return this.className;
  }-*/;

---

Reading the associated link though, no reference is made to the attribute being renamed - and indeed, when testing within your app, I find that invoking element.getAttribute("class") instead of element.className seems to work in firefox. More testing will be required to ensure this works in all browsers.

At this point, I'm tentatively holding the opinion that GWT is in the wrong, not GXT, though we can workaround this issue by invoking getAttribute("class") instead of getClassName() as a more efficient solution than simply adding a try/catch block. Further testing in all supported browsers will be required to ensure that this deals completely with the issue.

Thanks for the more complete report/example and stack trace - one comment though. As written, a simple 'mvn install' doesn't work correctly - I had to remove the gwt:i18n goal:

Code:

---

[ERROR] Failed to execute goal org.codehaus.mojo:gwt-maven-plugin:2.5.0:i18n (default) on project bug: neither i18nConstantsBundles, i18nMessagesBundles nor i18nConstantsWithLookupBundles present.

---

I've filed this within our tracker to see about creating and validating a workaround, but would encourage you to do further research on a proper fix in GWT itself, as any 'fix' in GXT will only be a workaround for this case, and it could popup elsewhere in GXT or other GWT libraries.

Thanks I change call in onMouseMove().

Sorry for mvn install. I create project from archetype and remove all.