Re: [qooxdoo-devel] Crash in _applyCursor in widget

[Marc P. <mar...@re...>]

The first thing I notice is that you're destroying the window by calling 
dispose(), where calling destroy() would be better. The difference is 
that destroy() does not only dispose the object, but also removes it 
from the layout system. I think that not using destroy() is what might 
be causing your error.

General rule of thumb: call destroy() on widgets, call dispose() on 
non-widgets.

Regards,
Marc




On 11/30/2012 12:02 PM, Tim van Oijen wrote:
>
> Hi,
>
> We have noticed a strange (asynchronous?) issue in qx.ui.core.widget, 
> while setting the mouse-cursor style and “simultaneously” (slightly 
> before probably) destroying a pop-up window. The situation is as follows:
>
> From our server, we receive on the client two commands “simultaneously”:
>
> 1.Set the mouse cursor style. We do this in our client code as follows:
>
> var root = qx.core.Init.getApplication().getRoot();
>
> if(isWait) {
>
>                 root.setCursor("wait");
>
> 2.Close a window (self is the window here).
>
> varself = this._controls[tag.getAttribute("id")];
>
> ……………….
>
> var parent = self.getLayoutParent();
>
> if (parent) {
>
>             parent.remove(self);
>
>       }
>
>      self.dispose();
>
> The crash that sometimes occurs at a customer is an operation on a 
> null-reference (in red):
>
> // property apply
>
> _applyCursor : function(value, old)
>
>     {
>
> if (value == null && !this.isSelectable()) {
>
>         value = "default";
>
>       }
>
> // In Opera the cursor must be set directly.
>
> // http://bugzilla.qooxdoo.org/show_bug.cgi?id=1729
>
> *this.getContainerElement()*.setStyle(
>
> "cursor", value, qx.core.Environment.get("engine.name") == "opera"
>
>       );
>
>     },
>
> Do you see whether something is wrong in the way how we use the 
> Qooxdoo code? Are there any asynchronous issues going on here in the 
> qx-code (at least in our code it is not), which might cause the 
> problem, or are we using it in an incorrect way? Unfortunately we 
> cannot tell with 100% certainty which of the two commands is executed 
> first when the crash occurs (we think the first one), because the 
> problem only occurred at one of our customers and we haven’t been able 
> to reproduce it ourselves yet.
>
> I hope you can help me.
>
> Kind regards,
>
> Tim
>