Announcement

**Isomorphic** · 30 May 2014, 09:45

HTTP 0 is a bogus status code for the browser to report to SmartClient. Also, the first request uses an XMLHttpRequest and the second a different approach - as far as SmartClient is concerned, these are completely unconnected. So this strongly suggests some kind of browser bug..

What browser(s) do this?

Can you reproduce it using any other client machine?

What about a machine on a different network?

**nitroamos** · 30 May 2014, 10:11

Browsers tested on my intranet:
Chrome 35.0.1916.114
Safari 6.1.4 (8537.76.4)
Firefox 29.0.1

I confirmed it occurs on an Amazon EC2 server using two different clients (OSX 10.8 and OSX 10.9).

I can reproduce this error on every configuration I've tested.

**Isomorphic** · 30 May 2014, 10:23

All 3 browsers return HTTP code 0?? We've never seen that with any browser but Windows IE.

Does this reproduce for you on a Windows machine? It's important to try a true Windows machine, and not a Parallels VM or similar.

**nitroamos** · 30 May 2014, 14:07

Yes, all instances for this error appear the same (i.e. HTTP code 0).

We have a Windows Server 2008 desktop. Chrome does produce the error there, but Internet Explorer 9 and 11 do not produce the error (nor any hint of trouble in the SmartClient logs).

**Isomorphic** · 31 May 2014, 11:01

OK, well this really really makes no sense as we previously noted (you're saying a request that involves using a hidden iframe for a download somehow interferes with a previous xmlHttpRequest..), and we have no further speculation as to a cause.

At this point, we need to be able to run it and see the problem. If you think you've really isolated the cause to a slow RPCRequest and a large export, you should be able to put that together as a standalone example easily. We would recommend just using Thread.sleep() as a means of making the first request take a long time.

**nitroamos** · 2 Jun 2014, 09:30

Ok, here's a simplified test. All you need to do to replicate is click the button, and the warning appears instantly.

This particular test was done on Chrome 35, OSX 10.8.5, Apache Tomcat 7.0.50.

Let me know if I'm missing anything...

Attached Files

**Isomorphic** · 4 Jun 2014, 11:21

Just to reassure you - we are reproducing the problem on our end and are looking into it. We'll let you know when we get to the bottom of it.

Regards
Isomorphic Software

**Isomorphic** · 4 Jun 2014, 14:13

Well we've identified the problem. The best way to work around this for now is to set "downloadToNewWindow" to true on your export request.
We're looking into the best way to handle this more gracefully by default.

Regards
Isomorphic Software

**nitroamos** · 4 Jun 2014, 16:08

Thanks for looking into this! No, I didn't think you'd forgotten.

I'm happy to wait for the correct solution, but it doesn't seem like your suggestion works in my case. Did you mean like this (diff on test.js):

Code:

*** 53,58 ****
           grid.exportClientData({ exportAs: "ooxml",
                                   exportDisplay: "download",
!                                  exportFilename: table.filename,
!                                  downloadToNewWindow:true
                                 });
           console.log("### done");
--- 53,57 ----
           grid.exportClientData({ exportAs: "ooxml",
                                   exportDisplay: "download",
!                                  exportFilename: table.filename
                                 });
           console.log("### done");

**Isomorphic** · 6 Jun 2014, 14:03

We've made a change now to address this issue (9.1p and 10.0d branches). Please try the next nightly build (June 7 or above), with your original test case and let us know if you continue to have problems with it.

Regards
Isomorphic Software

**nitroamos** · 9 Jun 2014, 13:10

Your fix works for the problem as I described it. Thanks for your timely responses and fix!!!

However, I've discovered a variant of the same problem. The same test files as before are sufficient. To reproduce the problem, click the button, and simply send the browser window to another URL (e.g. clicking a bookmark on my browser window's toolbar) before the jsp completes. The window successfully moves to the new URL, but the same warning message briefly flashes on the window as a parting farewell.

I should note the warning may not appear if the window switches too quickly. The warning appears more consistently when running the test on a remove server than on localhost.

Of course if the user is going to a new URL, the warning has no impact on their workflow. However, if the user sees it, they might get worried.

**nitroamos** · 16 Jun 2014, 14:38

Hello Isomorphic --

Have you been able to reproduce the additional issue I described?

Announcement

Transport error when my jsp is followed by exportClientData

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment