the issue can probably be closed, too
if you need any more help with any of the v3 items, in addition to SauceLabs, let me know. happy to help out.
yeah, that makes sense.
but the setup... If I remember correctly, last time I tried saucelabs, they would block all outgoing traffic so I couldn't test cross domain requests to mocky.io
@naugtur your point about
qs: Any? is good, i have to agree with that since it might not be a function
Hi. I'd like to merge new browser runner to v3dev some time soon. Let me know if I should give anyone time to review.
The main drawback of the new runner is that while it's still maintained, it got severely broken after 3.5.0 and I'm not sure if it'll recover to a state that handles our usecase juliangruber/browser-run#137
The main drawback of the new runner is that while it's still maintained, it got severely broken after 3.5.0 and I'm not sure if it'll recover to a state that handles our usecase juliangruber/browser-run#137
once i hear back, i'll post in here.
work's been busy, so i haven't had time to get started on this until now :)
i recently added SauceLabs to a project, and it got so annoying because the first run would happen quickly, and the second one would take forever. i think because i had a limit of 5 concurrent sessions, and i was testing 5 env's per run
(it was running twice due to Travis running the commit and the PR builds)
how many env's are we thinking of testing against? if it's...2, then SauceLabs might not be extremely slow, since each set of builds will come in below the limit of 5.
but we probably want to test more than 2, huh?
i wonder if they'd be flexible on upping the limit for us, in support of open source
We don't have to run tests against the browsers we use locally, but we'd have to test IE10+, Edge, Old safari versions and probably some mobile too.
I'll try to reach out to BrowserStack through my work, as the company has recently become a paying customer and maybe I can make them demo the setup using xhr as example. ;)
I'll do that when I'm back from vacation in a week from now.
I'll try to reach out to BrowserStack through my work, as the company has recently become a paying customer and maybe I can make them demo the setup using xhr as example. ;)
I'll do that when I'm back from vacation in a week from now.
Hi All and @naugtur. Has anyone got any ideas why sync requests does not enable withCredentials? See here https://github.com/naugtur/xhr/blob/master/index.js#L182
Ben Jefferies, check out that commit
(I did a quick git blame through the GitHub UI to find when the if statement was added)
Cheers @jmeas. I wonder if there is a way around it. Not sure what the underlying implementation is within jquery but maybe this would work https://stackoverflow.com/a/16673436 instead of blanket disabling.
there may be a way around it. try/catch is one idea, but that’s kinda clunky. perhaps modernizr has a snippet we could use.
can you not use async requests in this situation?
you may already know this, but synchronous requests are blocking, so if the network is down, your app could freeze up for quite some time
I agree it's probably nicer to use feature detections to enable this functionality rather than a hacky fix
I would love to use an async request but it's not possible; I am implementing some functionality to log users out when then navigate away from the current domain, if this is done async the request is very likely to be cancelled by the browsers when the page changes however the request will be fulfilled if the request is sync
Why is there no: document.toString() or document.innerHTML ?
