Welcome Guest Search | Active Topics | Sign In | Register

Sync XMLHttpRequests crash browser without invoking error or close events Options
James
Posted: Thursday, June 21, 2018 9:52:03 AM
Rank: Advanced Member
Groups: Member

Joined: 2/11/2015
Posts: 122
I have found a bug where if a web application sends an XmlHttpRequest synchronously, and that requests takes more than about 1 second it will crash the browser.
While a crash is essentially expected, what is not expected is that the WebView doesn't invoke the Close event, nor does the RunTime Invoke the CrashDataAvailable event or the Exception event, meaning the error cannot be handled and recovery options are skipped.

I've produced a minimal sample that works inside my office, but it would not be usable to essential objects as it requires access to closed internal servers.

I verified that the bug is crashes the browser in the TabbedBrowser sample, so its not related to implementation code specific to my software.
I haven't verified that the TabbedBrowser fails to invoke the events which will be my next step.

Once I verify that aspect I'll build a sample which uses a self hosted NancyFX.NET server that will simulate the delay in hopes it produces the same result. Once complete I'll package up the the test case and provide instructions on reproduction.

However, if you already have facilities for testing this kind of thing, then this is basically the code I used;
I use Knockout for updating UI, I replaced adding a string to an array with console.log

Code: JavaScript
function TestRequest(url)
{ 
    var startTime = performance.now();

    var xhr = new XMLHttpRequest();
    xhr.open('GET', url, false);
    xhr.setRequestHeader('Content-Type', 'application/json');

    if (xhr.readyState === 4) 
    {
        var endTime = performance.now();
        var timeTaken = (endTime - startTime) / 1000;
        if (xhr.status === 200 || (xhr.status === 0 && xhr.responseText !== '')) 
        {
            console.log("Received Successful Callback after " + timeTaken + " seconds");
        } else {
            console.log("Received Failed Callback after " + timeTaken + " seconds");
        }
    }

    xhr.send(null);
}
James
Posted: Thursday, June 21, 2018 12:43:28 PM
Rank: Advanced Member
Groups: Member

Joined: 2/11/2015
Posts: 122
So after some additional testing, it looks like this is related to cross domain requests.
In order for me to crash the browser, the website and the url passed to TestRequest need to have different domains.
eo_support
Posted: Thursday, June 21, 2018 1:45:07 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,080
Hi,

Which version are you running? We tested the latest version here and it seems to be working fine. The call will not succeed (because it's a cross domain request), but during our test we receive an error on the console window instead of crashing, which is consistent with Chrome's behavior.

Thanks!
James
Posted: Thursday, June 21, 2018 1:49:23 PM
Rank: Advanced Member
Groups: Member

Joined: 2/11/2015
Posts: 122
I am testing against the latest version of EO. However, I've been struggling to reproduce this in certain scenarios.

Currently, I can reproduce the problem if I host the static content on a node static server, and then the api in a Nancy Self host.
I've been trying to setup a project with 2 Nancy self hosts, but that doesn't produce the issue.

I did notice that the original offending request response headers contains two separate Access-Control-Allow-Headers headers.
I'm not sure if there is a way for me to produce that behavior in Nancy.
James
Posted: Thursday, June 21, 2018 1:53:03 PM
Rank: Advanced Member
Groups: Member

Joined: 2/11/2015
Posts: 122
I'm not confident at this point I can build a complete sample that is easily self contained.
I could provide the necessary files for the Node + Nancy setup and some instructions how to reproduce.
eo_support
Posted: Thursday, June 21, 2018 2:29:35 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,080
Sure. Please do that and we will take a look. See here for more information on sending test files to us:

https://www.essentialobjects.com/forum/test_project.aspx

Thanks!
James
Posted: Thursday, June 21, 2018 2:56:25 PM
Rank: Advanced Member
Groups: Member

Joined: 2/11/2015
Posts: 122
I can no longer get the node config to fail, but the original failure case persists. I'm not sure at this point how to get a reproducible sample for you to investigate.
eo_support
Posted: Thursday, June 21, 2018 3:12:55 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,080
That will be a problem. :) It will be very hard to chase it down without being able to reproduce it in our environment first. :(
James
Posted: Thursday, June 21, 2018 3:32:58 PM
Rank: Advanced Member
Groups: Member

Joined: 2/11/2015
Posts: 122
I'm going to keep working on it, as I need this feature to be reliable. Once I have a method of reproduction that doesn't rely on internal systems I'll update this.
eo_support
Posted: Thursday, June 21, 2018 3:41:39 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,080
No problem. Thank you very much!


You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.