-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
xhr incompatible with environments that honor object freezing #149
Comments
I left my phone at home, so can't 2fa to github now...
Great contribution. Compatibility issues and env fixes is what we want to
collect here.
It's a breaking change, so it'd need to go into v3 - some codebases may
rely on checking those extra fields on XMLHttpRequest. I remember seeing
that in tests to a library that used xhr internally.
…On Wed, Jan 11, 2017 at 1:06 AM, Ian Remmel ***@***.***> wrote:
xhr assigns values to the XMLHttpRequest instance which causes errors in
environments that disallow unknown properties. One such environment is
SalesForce Aura.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#149>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAfFv5M_wm11J3u3UA4UduH_AvOrbH6wks5rRBzsgaJpZM4LgCzh>
.
--
Z
naugtur@protonmail.com
|
hmm, ok. is there a timeline for that v3? I hate running off of forks, but I guess I'll have to in this case. |
We could start a v3 branch and you could install from GitHub instead of npm. I'm planning to start working on v3 this Friday.
Are you on a schedule/deadline? I could try to rush an alpha out and stabilize in the long run
Zb
…On Jan 11, 2017, 19:22, at 19:22, Ian Remmel ***@***.***> wrote:
hmm, ok. is there a timeline for that v3? I hate running off of forks,
but I guess I'll have to in this case.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#149 (comment)
|
yea, i need to get it working in the next few weeks; that said, I can point at my branch just as easily as yours and that's probably safer since you're definitely planning breaking changes in yours :) |
I did some more looking around and it seems that the requirement of freezing XMLHttpRequest is a bit unusual. Just removing the functionality of being able to check what the request options were is not only a breaking change, it's also blocking the possibility of asserting certain things in tests. I'll have to change the response object to contain a reference to request options probably. |
I can try to explain, but I only roughly understand it: Aura and/or Locker is SalesForce's tool for running untrusted code in their UI. It works by pretty much cloning the entire window API and giving plugins a thing that looks like a Window. One of the additional constraints appears to be that they freeze all HTML-specified Objects. |
Makes sense. For now, I brought back the features you removed under a different key and fixed tests. see https://github.com/naugtur/xhr/tree/ianwremmel-fix-frozen-objects |
I think that makes sense, but is And yea, I had mixed feelings about changing xhr, but I figured it would be easier than getting getting Locker/Aura rearchitected. I also kinda felt like strapping those values to the xhr instance was a bit unnecessary in that I couldn't imagine a scenario where an xhr consumer would have an instance and not have any easy way of knowing what values they created the instance with. That said, I'm clearly thinking selfishly here :) |
xhr assigns values to the XMLHttpRequest instance which causes errors in environments that disallow unknown properties. One such environment is SalesForce Aura.
The text was updated successfully, but these errors were encountered: