Message: "Failed to process setattr zkoss - ZK."

answered 2019-10-15 17:52:01 +0800

MDuchemin
2570 ● 1 ● 6

Hi RicardoRivas, welcome to the forum.

This message indicates that a JavaScript function went wrong and tried to access an undefined value, or a value on an undefined attribute.

When this happen, there should be a trace in your JS console (in browser's developer tools) which should give more info on what went wrong. Please paste it here with the whole stack trace below it so that we can have a more in-depth look :)

if you can also give a short description of what kind of action trigger the issue, would also be helpful.

answered 2019-11-12 17:35:27 +0800

MDuchemin
2570 ● 1 ● 6

Hi Ricardo, From your description, it looks like the column is no longer attached to the page, but is still trying to resize itself. Stacktrace is somewhat difficult to parse, since it's using minified code.

I'd recommend activating debug-js mode (display non-minified JS in browser) with : <client-config> <debug-js>true</debug-js> </client-config> in zk.xml

Also, could you give me a small overwiew of where this column is located? If you can make a fiddle to reproduce, that'be helpful :) (bumped your karma to enable links in your posts)

answered 2019-11-14 11:33:35 +0800

MDuchemin
2570 ● 1 ● 6

Hi Ricardo,

Thanks for updating the debug stacktrace. Unless it's triggered manually, docResize should be caused by the browser window resizing, or by the device changing orientation (portrait <> landscape) if it's a mobile or tablet.

docResize might also happen if the ZK app is running inside of an IFrame which is resized.

If you put a breakpoint inside of either zFlex.fixFlex or _docResize, you can check from where this was called. If you find it's called by _sizeHandler (above in the async stack), then it's likely triggered by the actual browser window. If that's the case, it would be interesting to check if the issue is browser-related (only on Chrome, IE, Firefox, etc)

If the resize event comes from another source, then it's a good lead.

In any case, from the stacktrace, it looks like a speed condition between a resize event and a component being removed from the page. You can prevent the issue altogether by checking if the component is attached before firing fixFlex.

    <script><![CDATA[
    zk.afterLoad("zk", function () {
        var _xzFlex = {};
        zk.override(zFlex, _xzFlex, {
            fixFlex: function(wgt) {
                if(wgt == null || wgt.$n() == null || wgt.$n().parentNode == null){
                    console.warn("skipped resize for widget: " + wgt);
                    return; //prevent default action
                }
                var result = _xzFlex.fixFlex.apply(this, arguments);
                return result;
            }
         });
    });
]]></script>

This should prevent the symptoms, since it will skip fixFlex for widgets that aren't attached to the page. Would still like to know the cause :)

regarding this script: you can deploy it in a single page with <script> tag, but it's be more efficient to deploy in lang-addon.xml if you need to have it active in every page of your application.

answered 2019-11-20 16:09:28 +0800

MDuchemin
2570 ● 1 ● 6

Good news: not the same error, not the same stack. That suggest the first error is prevented by the snippet posted last time.

Bad new: new error. It is triggered by setVisible (most likely on grid.setVisible, or column.setVisible), and it fails to find the DOM node associated with one of the widgets or its parent. Since we saw in your last stacktrace that the column's parent either is null or not attached, it's likely that this error is caused by the same condition.

I still can't tell if the widget is detached but not cleaned-up, or if it's in an unexpected state (attached, but with a DOM node removed or something like that).

Is it possible to make a zkfiddle sample of the issue? I'd be helpful to run the page locally to have a look at the exact sequence of events causing the issue.