Fix issue #533 #575
Fix issue #533 #575
Conversation
|
|
|
Hey guys, let's move on. |
|
|
|
Whats the status of the issue? We also have to suport IE 11 and need this fix. |
|
@mislav what is your opinion of this? |
|
I'm testing https://github.com/stefanpenner/es6-promise at the moment. It seem to fix my problem. |
|
This may no longer be an issue in newer versions of IE 11. I'm not able to repo using the test at: https://github.com/lowkay/MutationObserverSchedulerBug |
|
Errors in build are not caused by my changes
Default native response statusText is '' instead of 'OK' for (Headless)Chrome 73.0.3683. See Chromium Issue 907441: Change Response's statusText's default |
|
See #696 Change Response's statusText's default |
|
Any update on this? I'm also running into the bug described in #533 and would need this. I know IE is never fun, but our customers don't have a choice unfortunately. |
|
what is this problem |
|
This breaks jest timer mocks |
|
setTimeout() here is only called after resolution. but the promise exposed here doesn't resolve until after it is finished. Therefore, there's no way to tell jest to advance the setTimeout timer, since it isn't a timer to advance until a time to which there is no user level hookup |
As stated in petkaantonov/bluebird#1161, resolving a promise in an XHR callback without active DOM operations will not trigger the promise chain to execute. But wrapping fetch promise resolution in setTimeout magically resolves it.
Experienced this issue with different promise polyfills: bluebird, es6-promise, core-js/fn/promise
Adding setTimeout fixes #533.