[Isomorphic]

This doesn't seem related (other than it being another nonsense result), but the first few steps are the same (and are always the same) - what came back from the server? What's in the Developer Console?

[acarur01]

Sorry, what? I'm using the test json data that comes with the build...it should work exactly like Firefox, no? I don't know if this unrelated. I'm just trying to reproduce OUR issue and was blocked by this. Could you at least try loading it in chrome if you haven't already?


Be sure your post includes:

1. the *complete* SmartGWT or SmartClient version from the lower left-hand corner of the Developer Console (see FAQ for how to open Developer Console), for example, \"v8.2p_2012-04-18/PowerEdition Deployment\"

2. browser(s) and version(s) involved

3. for a server-side problem, the *complete* logs generated during processing of the failing request (do *not* trim to just the error message)

4. for any problem processing a server response, the actual response as shown in the RPC tab in the Developer Console

5. if there is a JavaScript error, the stack trace logged in the Developer Console (see FAQ)

6. sample code if applicable

Posts with incomplete information are much more likely to be ignored.

[Isomorphic]

Unsurprisingly there is no issue. You haven't mentioned what version you're running or what environment you're running this in - the SDK, your own server, etc. Please don't omit these details as it's a waste or your time and ours to request such details, run unnecessary tests in mismatched environments, etc.

[acarur01]

I'm sorry I thought I put it in this post but it was my other forum post that had env. info.

SC version: SmartClient_v82p_2012-05-30
Browser: Chrome 19.0.1084.52 m
OS: Windows 7 Ultimate SP1

The last issue I asked about was because I was opening the file statically. That's gone now but I still can't reproduce my original issue. The original issue is actually reported in the console if I turn on more logging. I honestly don't know where else to look for a possible cause of this. The console capture is in TransportCapture.gif and the RPC capture is in TransportRPCCapture.gif. These screenshots were captured at the time the first request came in to our server code. I allow the response to be sent back, the Transport Error warning popup disappears, and the debug console gets cleared (As seen from TransportCapture2.gif) and the RPC request is now successful.

[Isomorphic]

Just in case you weren't aware, it is always <i>always</i> invalid to test by opening .html files from Windows Explorer, or by dragging them onto browsers directly, or in any other way that doesn't involve a true web server. This is true for all browsers and operating systems.

As far as this new information about the original error - can you explain the difference between the *.gif and *2.gif files again - what do you mean by "screenshots were captured at the time the first request came in to our server code". It sounds like you might have paused the server in a debugger, but this isn't the case since the second logs do not include the results from the first, they are just a different test.

[acarur01]

Exactly my predicament. I did pause the server side in order to capture this info because otherwise it gets erased and all I see are the #2.gif which does not have the transport error . I don't know how else to capture it. Basically I am getting two requests for data. Both get Barack to the server but only one is reported as successful and the other one seems to have been discarded

Be sure your post includes:

1. the *complete* SmartGWT or SmartClient version from the lower left-hand corner of the Developer Console (see FAQ for how to open Developer Console), for example, \"v8.2p_2012-04-18/PowerEdition Deployment\"

2. browser(s) and version(s) involved

3. for a server-side problem, the *complete* logs generated during processing of the failing request (do *not* trim to just the error message)

4. for any problem processing a server response, the actual response as shown in the RPC tab in the Developer Console

5. if there is a JavaScript error, the stack trace logged in the Developer Console (see FAQ)

6. sample code if applicable

Posts with incomplete information are much more likely to be ignored.

[Isomorphic]

Sorry, that doesn't make sense. The *2.gif capture of the Developer Console log does not show the original httpResponseCode 0 response. There is no way this could be overwritten unless you reloaded the page right after sending the first request - any by the way doing so could result in some kind of bogus code 0 from the browser.

[acarur01]

Ah ok.I think its starting to make sense now. I predict this is because of URL changes in between that are notbeing handled properly and a request starts against the previous page then gets interrupted. Ill test this .

[acarur01]

Just a quick update. It was our redirect url that was causing the transport error. Thanks for bearing with me =)