"Defaked" fake XHR does not propagate properties to actual XHR after triggering `open`

[pswai]

Related to #49.

Minimal repro: https://github.com/pswai/nise-defake-issue

Considering this case:

sinon.FakeXMLHttpRequest.useFilters = true;
sinon.FakeXMLHttpRequest.addFilter(() => true);

const server = sinon.fakeServer.create();

const xhr = new XMLHttpRequest();
xhr.open("GET", "http://www.mocky.io/v2/5e8aa67e2d00003c1a1a473e", true);

// Setting `withCredentials` applies only to the FakeXhr instance.
// The `workingXHR` in `defake` does not receive this.
xhr.withCredentials = true;
xhr.send();

xhr.send() calls the send function defined in the defake function. Since defake is called during open, any modification to the fake XHR does not reflect on the actual XHR. In this example, if we put a breakpoint in send, we can see that withCredentials is false for the actual XHR.

I think we can either utilise Proxy to setup trap for setting properties after defake, or do copyAttrs again in send.

This was discovered when I was trying to use unsafeHeadersEnabled: false with fake server and noticed that withCredentials didn't work 😅

[fatso83]

Excellent research. Both of your suggestions are valid, but since we are trying to support browsers as old as IE11, I assume that means Proxy is a no-go. Copying attributes manually seems pretty straightforward and easy to implement.

[pswai]

@fatso83 I took a deeper look at this, we might need to do copyAttrs for other methods as well. That can be done by putting copyAttrs here. Actually not sure the methods here need to have the updated attrs or not :D

Meanwhile I just discovered https://github.com/GoogleChrome/proxy-polyfill, it can potentially change how mocking can be done. But probably not now since it will be a major change 😅