IE RPC problems: TypeError: 'response.id'...

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

IE RPC problems: TypeError: 'response.id'...

Cajus Pollmeier
Hi all!

I trapped into a problem with IE/RPC and after some hours of debugging I think
it's time to ask the qooxdoo experts ;-)

Target: qooxdoo-1.3-sdk

The complete RPC stuff works inside Firefox, Chrome, Safari and Opera, but
fails for RPC calls in IE. It doesn't seem to matter which version I use. I
tried 6/7/8 on XP and Windows 7.

The qooxdoo console reports that:

8<---------------------
 034632 qx.core.Init: Load runtime: 34632ms
<snip>
 034757 qx.core.Object[200]: Async start: getLoggedInUser
 034757 qx.html.Blocker[201]: State: queued
 034757 qx.io.remote.RequestQueue[202]: Progress: 0/1
 034757 qx.io.remote.RequestQueue[202]: Progress: 1/1
 034757 Using implementation: qx.io.remote.transport.XmlHttp
 034757 State: configured
 034773 qx.core.Init: Main runtime: 141ms
 034835 qx.core.Init: Finalize runtime: 62ms
 034897 State: sending
 034897 State: configured => sending
 034897 qx.io.remote.RequestQueue[202]: ActiveCount: 1
 034897 qx.html.Blocker[201]: State: sending
 034897 State: receiving
 034897 State: sending => receiving
 034897 qx.html.Blocker[201]: State: receiving
 034897 State: completed
 034897 State: receiving => completed
 034897 Returning content for responseType: application/json
 034897 Altered State: completed => failed
 034897 qx.io.remote.RequestQueue[202]: ActiveCount: 0
 034897 qx.html.Blocker[201]: State: completed
 034913 qx.io.remote.RequestQueue[202]: Request
   qx.io.remote.Request[201] handler _oncompleted threw an error:
   TypeError: 'response.id' ist Null oder kein Objekt
 034913 qx.html.Blocker[201]: State: aborted
 034913 {code:2, message:Aborted getLoggedInUser, origin:4}
 034975 qx.core.Object[303]: stop - global requests pending: 0
 034975 qx.io.remote.RequestQueue[202]: Progress: 0/0
8<---------------------

So the RPC call gets aborted due to an invalid "response.id". The returned
message from the RPC service is captured by wireshark as:

{"error": null, "result": "admin", "id": 2}

Any ideas on how to track that down?

Thanks'n cheers,
Cajus

------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: IE RPC problems: TypeError: 'response.id'...

Stefan Volbers
Hi Cajus,

 >     TypeError: 'response.id' ist Null oder kein Objekt

seems like you want the result object to have an "id" property.
Which, according to wireshark,

 > {"error": null, "result": "admin", "id": 2}

is not there, as the result object is only an "admin" string.

BTW, I'd consider it a bit overkill to use wireshark for RPC debugging -
you use Firebug on Firefox at least? If so, does it show the same RPC
result? AND, is the RPC POST/GET query the same, no matter if you use IE
or another browser?
Speaking of which, which RPC backend do you use - does it need any
special treatment/configuration?
Is the RPC a crossDomain one, or using BasicHTTPAuth or such we should know?

If this isn't of any help, maybe you wanna post the RPC call and/or the
result handler, so we might have a look into that.

Greetings,
Stefan

On 27.01.2011 13:01, Cajus Pollmeier wrote:

> Hi all!
>
> I trapped into a problem with IE/RPC and after some hours of debugging I think
> it's time to ask the qooxdoo experts ;-)
>
> Target: qooxdoo-1.3-sdk
>
> The complete RPC stuff works inside Firefox, Chrome, Safari and Opera, but
> fails for RPC calls in IE. It doesn't seem to matter which version I use. I
> tried 6/7/8 on XP and Windows 7.
>
> The qooxdoo console reports that:
>
> 8<---------------------
>   034632 qx.core.Init: Load runtime: 34632ms
> <snip>
>   034757 qx.core.Object[200]: Async start: getLoggedInUser
>   034757 qx.html.Blocker[201]: State: queued
>   034757 qx.io.remote.RequestQueue[202]: Progress: 0/1
>   034757 qx.io.remote.RequestQueue[202]: Progress: 1/1
>   034757 Using implementation: qx.io.remote.transport.XmlHttp
>   034757 State: configured
>   034773 qx.core.Init: Main runtime: 141ms
>   034835 qx.core.Init: Finalize runtime: 62ms
>   034897 State: sending
>   034897 State: configured =>  sending
>   034897 qx.io.remote.RequestQueue[202]: ActiveCount: 1
>   034897 qx.html.Blocker[201]: State: sending
>   034897 State: receiving
>   034897 State: sending =>  receiving
>   034897 qx.html.Blocker[201]: State: receiving
>   034897 State: completed
>   034897 State: receiving =>  completed
>   034897 Returning content for responseType: application/json
>   034897 Altered State: completed =>  failed
>   034897 qx.io.remote.RequestQueue[202]: ActiveCount: 0
>   034897 qx.html.Blocker[201]: State: completed
>   034913 qx.io.remote.RequestQueue[202]: Request
>     qx.io.remote.Request[201] handler _oncompleted threw an error:
>     TypeError: 'response.id' ist Null oder kein Objekt
>   034913 qx.html.Blocker[201]: State: aborted
>   034913 {code:2, message:Aborted getLoggedInUser, origin:4}
>   034975 qx.core.Object[303]: stop - global requests pending: 0
>   034975 qx.io.remote.RequestQueue[202]: Progress: 0/0
> 8<---------------------
>
> So the RPC call gets aborted due to an invalid "response.id". The returned
> message from the RPC service is captured by wireshark as:
>
> {"error": null, "result": "admin", "id": 2}
>
> Any ideas on how to track that down?
>
> Thanks'n cheers,
> Cajus
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: IE RPC problems: TypeError: 'response.id'...

Derrell Lipman


On Thu, Jan 27, 2011 at 08:14, Stefan Volbers <[hidden email]> wrote:
Hi Cajus,

 >     TypeError: 'response.id' ist Null oder kein Objekt

seems like you want the result object to have an "id" property.
Which, according to wireshark,

 > {"error": null, "result": "admin", "id": 2}

is not there, as the result object is only an "admin" string.

No, response is the whole thing, result is one of the three fields in the response. There is an id field in response. 

Somehow, we're getting an "aborted" event, it seems.

  034913 qx.io.remote.RequestQueue[202]: Request
  qx.io.remote.Request[201] handler _oncompleted threw an error:
  TypeError: 'response.id' ist Null oder kein Objekt
  034913 qx.html.Blocker[201]: State: aborted

Why it thinks that response.id is invalid is the question I have. (I don't know German, but I'm inferring that "oder kein Objekt" means "or not an object".)

As to the difference in IE, I can only imagine that something in the XMLHttpRequest processing occurs in a different order, or something, than with other browsers. There have been plenty of qooxdoo applications using IE over the years, though, that I'd have thought we had all of those browser differences cleared up by now.

I think this is going to require some debugging with Firefox. You might start with a breakpoint around line 574 of qx/io/remote/Rpc.js, which is the "aborted" event listener. From there you may be able to see from the stack trace what's going on a bit better.

Derrell


------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: IE RPC problems: TypeError: 'response.id'...

Cajus Pollmeier
In reply to this post by Stefan Volbers
Hi Stefan,

thanks for your answer. Find my comments below:

Am Donnerstag 27 Januar 2011, 14:14:07 schrieb Stefan Volbers:

> Hi Cajus,
>
>  >     TypeError: 'response.id' ist Null oder kein Objekt
>
> seems like you want the result object to have an "id" property.
> Which, according to wireshark,
>
>  > {"error": null, "result": "admin", "id": 2}
>
> is not there, as the result object is only an "admin" string.

Who does request the .id property? My code does not. It is reproducible by
that simple application snippet on qx side:

8<-----------------
      // Create a button
      var button1 = new qx.ui.form.Button("First Button", "rpctest/test.png");

      // Document is the application root
      var doc = this.getRoot();

      // Add button to document at fixed coordinates
      doc.add(button1, {left: 100, top: 50});

      // Add an event listener
      var rpc = new qx.io.remote.Rpc('/rpc');
      button1.addListener("execute", function(e) {
            rpc.callAsync(function(result, exc){
                    if(exc){
                         new qx.core.Object().debug("Fehler!");
                         qx.dev.Debug.debugObject(exc);
                    }else{
                         new qx.core.Object().debug("Ok!");
                         qx.dev.Debug.debugObject(result);
                    }
                },'login','very','secret');
      });
8<-----------------

Please just ignore that it's another method like in the dump below. That
snippet works in FF, Chrome and Opera, but is talking about that response.id
thingie in IE. Same for sync calls.

> BTW, I'd consider it a bit overkill to use wireshark for RPC debugging -
> you use Firebug on Firefox at least? If so, does it show the same RPC
> result? AND, is the RPC POST/GET query the same, no matter if you use IE
> or another browser?

I use wireshark because I don't know any tools that show the relevant
information in IE. The build in stuff sucks. If I compare the communication
between Firefox and IE, they're the same. So: yes, the RPC results sets in IE
and Firefox get are identical.

> Speaking of which, which RPC backend do you use - does it need any
> special treatment/configuration?

It's a wsgi python backend with jsonrpc logic. But as it works with other
browsers, I don't think that this one has problems. I'm always seeing 200 OK
on the RPC side and the result codes sent are identically for IE and FF.

> Is the RPC a crossDomain one, or using BasicHTTPAuth or such we should
> know?

No cross domain communication: the application is in /, the backend in /rpc.
 
> If this isn't of any help, maybe you wanna post the RPC call and/or the
> result handler, so we might have a look into that.

-Cajus

------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: IE RPC problems: TypeError: 'response.id'...

Stefan Volbers
In reply to this post by Derrell Lipman
Hi Derrell,

On 27.01.2011 14:22, Derrell Lipman wrote:

>
>
> On Thu, Jan 27, 2011 at 08:14, Stefan Volbers <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi Cajus,
>
>      >     TypeError: 'response.id <http://response.id>' ist Null oder
>     kein Objekt
>
>     seems like you want the result object to have an "id" property.
>     Which, according to wireshark,
>
>      > {"error": null, "result": "admin", "id": 2}
>
>     is not there, as the result object is only an "admin" string.
>
>
> No, response is the whole thing, result is one of the three fields in
> the response. There is an id field in response.

Ouch.. you're absolutely right - I somehow read "result.id". Great you
had an eye on the topic.

THX

Greetings,
Stefan

> Somehow, we're getting an "aborted" event, it seems.
>
>    034913 qx.io.remote.RequestQueue[202]: Request
>    qx.io.remote.Request[201] handler _oncompleted threw an error:
>    TypeError: 'response.id <http://response.id/>' ist Null oder kein Objekt
>    034913 qx.html.Blocker[201]: State: aborted
>
> Why it thinks that response.id <http://response.id> is invalid is the
> question I have. (I don't know German, but I'm inferring that "oder kein
> Objekt" means "or not an object".)
>
> As to the difference in IE, I can only imagine that something in the
> XMLHttpRequest processing occurs in a different order, or something,
> than with other browsers. There have been plenty of qooxdoo applications
> using IE over the years, though, that I'd have thought we had all of
> those browser differences cleared up by now.
>
> I think this is going to require some debugging with Firefox. You might
> start with a breakpoint around line 574 of qx/io/remote/Rpc.js, which is
> the "aborted" event listener. From there you may be able to see from the
> stack trace what's going on a bit better.
>
> Derrell

------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: IE RPC problems: TypeError: 'response.id'...

Cajus Pollmeier
In reply to this post by Derrell Lipman
Am Donnerstag 27 Januar 2011, 14:22:49 schrieb Derrell Lipman:

> On Thu, Jan 27, 2011 at 08:14, Stefan Volbers <[hidden email]> wrote:
> > Hi Cajus,
> >
> >  >     TypeError: 'response.id' ist Null oder kein Objekt
> >
> > seems like you want the result object to have an "id" property.
> > Which, according to wireshark,
> >
> >  > {"error": null, "result": "admin", "id": 2}
> >
> > is not there, as the result object is only an "admin" string.
>
> No, response is the whole thing, result is one of the three fields in the
> response. There is an id field in response.
>
> Somehow, we're getting an "aborted" event, it seems.
>
>   034913 qx.io.remote.RequestQueue[202]: Request
>   qx.io.remote.Request[201] handler _oncompleted threw an error:
>   TypeError: 'response.id' ist Null oder kein Objekt
>   034913 qx.html.Blocker[201]: State: aborted
>
> Why it thinks that response.id is invalid is the question I have. (I don't
> know German, but I'm inferring that "oder kein Objekt" means "or not an
> object".)
>
> As to the difference in IE, I can only imagine that something in the
> XMLHttpRequest processing occurs in a different order, or something, than
> with other browsers. There have been plenty of qooxdoo applications using
> IE over the years, though, that I'd have thought we had all of those
> browser differences cleared up by now.
>
> I think this is going to require some debugging with Firefox. You might
> start with a breakpoint around line 574 of qx/io/remote/Rpc.js, which is
> the "aborted" event listener. From there you may be able to see from the
> stack trace what's going on a bit better.

Hi Derrell,

hmm. You mean debugging with IE? Firefox never gets at that place.

I've just added qx.dev.StackTrace.getStackTrace() output for the aborted event
listener:

[
    anonymous(),
    qx.event.dispatch.Direct.prototype.dispatchEvent(),
    wrappedFunction(),
    qx.event.Manager.prototype.dispatchEvent(),
    qx.event.Registration.dispatchEvent(),
    qx.core.Object.prototype.dispatchEvent(),
    anonymous(),
    qx.io.remote.Request.prototype.__forwardEvent(),
    qx.io.remote.Request.prototype._onaborted(),
    qx.io.remote.RequestQueue.prototype._oncompleted(),
    ...
]

For me the result is not very helpful ;-) It seems to be truncated by IE,
though. Do you have additional hints on how to make it more verbose?

Thanks,
Cajus

------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: IE RPC problems: TypeError: 'response.id'...

Stefan Volbers
In reply to this post by Cajus Pollmeier
Hi Cajus,

On 27.01.2011 14:33, Cajus Pollmeier wrote:
>> seems like you want the result object to have an "id" property.
>> Which, according to wireshark,
>>
>>   >  {"error": null, "result": "admin", "id": 2}
>>
>> is not there, as the result object is only an "admin" string.
>
> Who does request the .id property? My code does not. It is reproducible by
> that simple application snippet on qx side:

Derrell is right, and I was on the wrong track - see his answer; the id
property of the response JSON object is generated by the backend and is
to show the same ID as the requesting RPC delivered. It is a means built
into RPC to help fitting requests and responses, and debugging.
So RPC code itself requests the property, and having response.id==null
is a problem, as the RPC response clearly shows "id": 2.

Plain vanilla RPC is widely used with any browser, but I haven't
switched to qx1.3 yet, so I cannot confirm any IE problem there, yet.

If I find some time, I'll try to set up a qooxdoo 1.3 environment to
test your example.

Greetings,
Stefan


> 8<-----------------
>        // Create a button
>        var button1 = new qx.ui.form.Button("First Button", "rpctest/test.png");
>
>        // Document is the application root
>        var doc = this.getRoot();
>
>        // Add button to document at fixed coordinates
>        doc.add(button1, {left: 100, top: 50});
>
>        // Add an event listener
>        var rpc = new qx.io.remote.Rpc('/rpc');
>        button1.addListener("execute", function(e) {
>              rpc.callAsync(function(result, exc){
>                      if(exc){
>                           new qx.core.Object().debug("Fehler!");
>                           qx.dev.Debug.debugObject(exc);
>                      }else{
>                           new qx.core.Object().debug("Ok!");
>                           qx.dev.Debug.debugObject(result);
>                      }
>                  },'login','very','secret');
>        });
> 8<-----------------
>
> Please just ignore that it's another method like in the dump below. That
> snippet works in FF, Chrome and Opera, but is talking about that response.id
> thingie in IE. Same for sync calls.
>
>> BTW, I'd consider it a bit overkill to use wireshark for RPC debugging -
>> you use Firebug on Firefox at least? If so, does it show the same RPC
>> result? AND, is the RPC POST/GET query the same, no matter if you use IE
>> or another browser?
>
> I use wireshark because I don't know any tools that show the relevant
> information in IE. The build in stuff sucks. If I compare the communication
> between Firefox and IE, they're the same. So: yes, the RPC results sets in IE
> and Firefox get are identical.
>
>> Speaking of which, which RPC backend do you use - does it need any
>> special treatment/configuration?
>
> It's a wsgi python backend with jsonrpc logic. But as it works with other
> browsers, I don't think that this one has problems. I'm always seeing 200 OK
> on the RPC side and the result codes sent are identically for IE and FF.
>
>> Is the RPC a crossDomain one, or using BasicHTTPAuth or such we should
>> know?
>
> No cross domain communication: the application is in /, the backend in /rpc.
>
>> If this isn't of any help, maybe you wanna post the RPC call and/or the
>> result handler, so we might have a look into that.
>
> -Cajus

------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: IE RPC problems: TypeError: 'response.id'...

Derrell Lipman
In reply to this post by Cajus Pollmeier
On Thu, Jan 27, 2011 at 09:18, Cajus Pollmeier <[hidden email]> wrote:
hmm. You mean debugging with IE? Firefox never gets at that place.

Yeah, that sucks. Debugging in older versions of IE is pretty awful.

Ah! I think I just found your answer. Look at the comments in the _oncompleted method of RequestQueue:

    /**
     * Listens for the "completed" event of the transport object and decreases
     * the counter for active requests.
     *
     * @param e {qx.event.type.Event} event object
     * @return {void}
     */
    _oncompleted : function(e)
    {
      if (qx.core.Variant.isSet("qx.debug", "on"))
      {
        if (qx.core.Setting.get("qx.ioRemoteDebug"))
        {
          if (e.getTarget()._counted)
          {
            this.__activeCount--;
            this.debug("ActiveCount: " + this.__activeCount);
          }
        }
      }

      // delegate the event to the handler method of the request depending
      // on the current type of the event ( completed|aborted|timeout|failed )
      var request = e.getTarget().getRequest();
      var requestHandler = "_on" + e.getType();

      // It's possible that the request handler can fail, possibly due to
      // being sent garbage data. We want to prevent that from crashing
      // the program, but instead  display an error, and, importantly
      // (regardless of error) remove the request from the queue.
      try
      {
        if (request[requestHandler])
        {
          request[requestHandler](e);
        }
      }
      catch(ex)
      {
        this.error("Request " + request + " handler " + requestHandler +
          " threw an error: ", ex);

        // Issue an "aborted" event so the application gets notified.
        // If that too fails, or if there's no "aborted" handler, ignore it.
        try
        {
          if (request["_onaborted"])
          {
            var event = qx.event.Registration.createEvent("aborted",
                                                      qx.event.type.Event);
            request["_onaborted"](event);
          }
        }
        catch(ex)
        {
        }
      }
      finally
      {
        this._remove(e.getTarget());
      }
    },

Note that it's issuing the "aborted" event when the request handler throws an error. That's almost certainly what's happening. Try adding a try/catch block inside of your "completed" handler, and you'll likely find the problem.

Derrell


------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: IE RPC problems: TypeError: 'response.id'...

Derrell Lipman
In reply to this post by Cajus Pollmeier
On Thu, Jan 27, 2011 at 09:18, Cajus Pollmeier <[hidden email]> wrote:
[
   anonymous(),
   qx.event.dispatch.Direct.prototype.dispatchEvent(),
   wrappedFunction(),
   qx.event.Manager.prototype.dispatchEvent(),
   qx.event.Registration.dispatchEvent(),
   qx.core.Object.prototype.dispatchEvent(),
   anonymous(),
   qx.io.remote.Request.prototype.__forwardEvent(),
   qx.io.remote.Request.prototype._onaborted(),
   qx.io.remote.RequestQueue.prototype._oncompleted(),
   ...
]

For me the result is not very helpful ;-) It seems to be truncated by IE,

Actually, it's not truncated by IE, it's truncated by the method getStackTraceFromCaller when you request the stack trace. It's finding a function that it's already shown you, so thinking that it's likely recursive and prevents an infinite loop. (It might be better if it allowed some number of the same function to be displayed, since finding the same function on the stack isn't necessarily a recursion issue.)

Derrell


------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: IE RPC problems: TypeError: 'response.id'...

Cajus Pollmeier
In reply to this post by Derrell Lipman
LOL. Just got it. The real reason *somehow* gets swallowed by IE. Placing
several try/catch blocks deeper in the code tells me:

 "Encoding not supported"

That's because the server seems to use charset set to utf8. Removing the
charset on the server side makes it work. #@~!

Thanks for your help ;-)

Cheers,
Cajus

Am Donnerstag 27 Januar 2011, 15:47:40 schrieb Derrell Lipman:

> On Thu, Jan 27, 2011 at 09:18, Cajus Pollmeier <[hidden email]> wrote:
> > hmm. You mean debugging with IE? Firefox never gets at that place.
>
> Yeah, that sucks. Debugging in older versions of IE is pretty awful.
>
> Ah! I think I just found your answer. Look at the comments in the
> _oncompleted method of RequestQueue:
>
>     /**
>      * Listens for the "completed" event of the transport object and
> decreases
>      * the counter for active requests.
>      *
>      * @param e {qx.event.type.Event} event object
>      * @return {void}
>      */
>     _oncompleted : function(e)
>     {
>       if (qx.core.Variant.isSet("qx.debug", "on"))
>       {
>         if (qx.core.Setting.get("qx.ioRemoteDebug"))
>         {
>           if (e.getTarget()._counted)
>           {
>             this.__activeCount--;
>             this.debug("ActiveCount: " + this.__activeCount);
>           }
>         }
>       }
>
>       // delegate the event to the handler method of the request depending
>       // on the current type of the event (
> completed|aborted|timeout|failed )
>       var request = e.getTarget().getRequest();
>       var requestHandler = "_on" + e.getType();
>
>       // It's possible that the request handler can fail, possibly due to
>       // being sent garbage data. We want to prevent that from crashing
>       // the program, but instead  display an error, and, importantly
>       // (regardless of error) remove the request from the queue.
>       try
>       {
>         if (request[requestHandler])
>         {
>           request[requestHandler](e);
>         }
>       }
>       catch(ex)
>       {
>         this.error("Request " + request + " handler " + requestHandler +
>           " threw an error: ", ex);
>
>         // Issue an "aborted" event so the application gets notified.
>         // If that too fails, or if there's no "aborted" handler, ignore
> it. try
>         {
>           if (request["_onaborted"])
>           {
>             var event = qx.event.Registration.createEvent("aborted",
>                                                       qx.event.type.Event);
>             request["_onaborted"](event);
>           }
>         }
>         catch(ex)
>         {
>         }
>       }
>       finally
>       {
>         this._remove(e.getTarget());
>       }
>     },
>
> Note that it's issuing the "aborted" event when *the request handler*
> throws an error. That's almost certainly what's happening. Try adding a
> try/catch block inside of your "completed" handler, and you'll likely find
> the problem.
>
> Derrell


------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: IE RPC problems: TypeError: 'response.id'...

Cajus Pollmeier
To be even more correct: utf8 is wrong, utf-8 is correct. The other browsers
seem to ignore that fact.

Am Donnerstag 27 Januar 2011, 17:30:08 schrieb Cajus Pollmeier:

> LOL. Just got it. The real reason *somehow* gets swallowed by IE. Placing
> several try/catch blocks deeper in the code tells me:
>
>  "Encoding not supported"
>
> That's because the server seems to use charset set to utf8. Removing the
> charset on the server side makes it work. #@~!
>
> Thanks for your help ;-)
>
> Cheers,
> Cajus
>
> Am Donnerstag 27 Januar 2011, 15:47:40 schrieb Derrell Lipman:
> > On Thu, Jan 27, 2011 at 09:18, Cajus Pollmeier <[hidden email]>
wrote:

> > > hmm. You mean debugging with IE? Firefox never gets at that place.
> >
> > Yeah, that sucks. Debugging in older versions of IE is pretty awful.
> >
> > Ah! I think I just found your answer. Look at the comments in the
> >
> > _oncompleted method of RequestQueue:
> >     /**
> >    
> >      * Listens for the "completed" event of the transport object and
> >
> > decreases
> >
> >      * the counter for active requests.
> >      *
> >      * @param e {qx.event.type.Event} event object
> >      * @return {void}
> >      */
> >    
> >     _oncompleted : function(e)
> >     {
> >    
> >       if (qx.core.Variant.isSet("qx.debug", "on"))
> >       {
> >      
> >         if (qx.core.Setting.get("qx.ioRemoteDebug"))
> >         {
> >        
> >           if (e.getTarget()._counted)
> >           {
> >          
> >             this.__activeCount--;
> >             this.debug("ActiveCount: " + this.__activeCount);
> >          
> >           }
> >        
> >         }
> >      
> >       }
> >      
> >       // delegate the event to the handler method of the request
> >       depending // on the current type of the event (
> >
> > completed|aborted|timeout|failed )
> >
> >       var request = e.getTarget().getRequest();
> >       var requestHandler = "_on" + e.getType();
> >      
> >       // It's possible that the request handler can fail, possibly due to
> >       // being sent garbage data. We want to prevent that from crashing
> >       // the program, but instead  display an error, and, importantly
> >       // (regardless of error) remove the request from the queue.
> >       try
> >       {
> >      
> >         if (request[requestHandler])
> >         {
> >        
> >           request[requestHandler](e);
> >        
> >         }
> >      
> >       }
> >       catch(ex)
> >       {
> >      
> >         this.error("Request " + request + " handler " + requestHandler +
> >        
> >           " threw an error: ", ex);
> >        
> >         // Issue an "aborted" event so the application gets notified.
> >         // If that too fails, or if there's no "aborted" handler, ignore
> >
> > it. try
> >
> >         {
> >        
> >           if (request["_onaborted"])
> >           {
> >          
> >             var event = qx.event.Registration.createEvent("aborted",
> >            
> >                                                       qx.event.type.Event
> >                                                       );
> >            
> >             request["_onaborted"](event);
> >          
> >           }
> >        
> >         }
> >         catch(ex)
> >         {
> >         }
> >      
> >       }
> >       finally
> >       {
> >      
> >         this._remove(e.getTarget());
> >      
> >       }
> >    
> >     },
> >
> > Note that it's issuing the "aborted" event when *the request handler*
> > throws an error. That's almost certainly what's happening. Try adding a
> > try/catch block inside of your "completed" handler, and you'll likely
> > find the problem.
> >
> > Derrell
>
> ---------------------------------------------------------------------------
> --- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better
> price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: IE RPC problems: TypeError: 'response.id'...

Derrell Lipman
In reply to this post by Cajus Pollmeier
On Thu, Jan 27, 2011 at 11:30, Cajus Pollmeier <[hidden email]> wrote:
LOL. Just got it. The real reason *somehow* gets swallowed by IE. Placing
several try/catch blocks deeper in the code tells me:

 "Encoding not supported"

That's because the server seems to use charset set to utf8. Removing the
charset on the server side makes it work. #@~!

Thanks for your help ;-)

Great. Glad you figured it out. I wouldn't have such problems here. Who needs utf-8? ASCII covers my whole language. :-) :-) :-)

Cheers,

Derrell
 

------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel