Using bluebird in IE/Edge does not always resolve promises when window is not focused

[mindlink]

1. What version of bluebird is the issue happening on?
   3.4.1

2. What platform and version? (For example Node.js 0.12 or Google Chrome 32)
   Internet Explorer 11, Edge

3. Did this issue happen with earlier version of bluebird?
   Unknown

Have some operation that triggers regardless of user interaction e.g. long-polling XHR, websocket, setTimeout, that signals a promise chain and nothing else. Then switch from IE/Edge to something else.

You would expect that the promise chain is executed regardless, however the chain stops executing.

Further investigation shows that the use of MutationObserver as the scheduler, means that a DOM change (or console log if the debugger is open) is required to trigger the promise chain. A detached DOM operation does not trigger the chain (like in the MutationObserver scheduler).

We have worked around this issue by setting the scheduler to use setTimeout (which isn't ideal).

[benjamingr]

We actually use NativePromise.resolve if it is available so edge shouldn't be an issue.

As for IE11, I haven't experienced this - is the computer under low power mode or something similar? Note that in low power settings your setTimeout workaround might not work.

We can prefer setImmediate over mutationobserver in IE. A small reproducing example would do wonders.

[lowkay]

Howdy,

Further investigation into this revealed that the issue is only in a callback from an XHR. Resolving a promise in such a callback without active DOM operations will not trigger the promise chain to execute.

We thus altered our approach to wrap the promise resolution in a setTimeout, then magically it works.

I have a test case, which I'll try and publish on github next week. It seems to affect pretty much every promise library not just bluebird - due to the fact MutationObserver has the closest execution scheduling to native promises.

[benjamingr]

Oh, so it's an XHR specific issue in IE where it doesn't call the resolution code unless it's wrapped in a timeout? That's interesting.

I don't think it's in scope for bluebird to solve that case though as it's xhr specific.

[thomas-darling]

@benjamingr can you please elaborate on why this not a bluebird issue?
This currently prevents our app from loading in IE, and I don't see who else would be in a position to fix this - as I understand it, this is a result of the way bluebird uses MutationObserver for scheduling.

[benjamingr]

Further investigation into this revealed that the issue is only in a callback from an XHR. Resolving a promise in such a callback without active DOM operations will not trigger the promise chain to execute.

It sounds like it's specific to XHR, rather than all of IE. It makes sense to poky fill it there differently rather than change the whole scheduler.

[thomas-darling]

I'm confused - bluebird is a polyfill, and if it does not work properly in IE, then I don't see how closing the issue can be justified. I agree it is likely related to XHR requests, but I don't see how that makes a difference - we still don't know exactly what is wrong or how to fix it, and the setTimeout workaround is a horrible hack that has performance implications and may not even work in all scenarios. I think this issue should be kept open until we have a proper fix - and until then, I'd say this is an issue with the choice of scheduler :-)

[petkaantonov]

it's not a polyfill, the api just has reasonable overlap with native promises

[benjamingr]

@thomas-darling I have been unable to reproduce this issue with IE11 twice now, if IE11 throttles XHR (and not mutation observers) then the fact it's promises makes no difference.

A reproducing sample would go a huge way here - it's possible this was in earlier bluebird or caused by another computer setting.

[lowkay]

Howdy,

Here is an example of what we are experiencing, on the left is Chrome doing what you'd expect, on the right is IE 11 neither windows were focused or had mouse interaction until 15:52:07..

Note how the promise is reported as resolved at 15:51:45 but the continuation is only invoked at 15:52:07 - that's 22 seconds later. It would be indefinite if I never interacted with the mouse.

[lowkay]

You can find the application that replicates this issue here:
https://github.com/lowkay/MutationObserverSchedulerBug

It's crude, but I didn't have time to tidy it up much.

[deser]

So was that issue resolved guys?

[lowkay]

We stuck with a settimeout workaround, its definitely a bug with how IE handles XHR callbacks.

[deser]

The library then should care about the bug...

[rgupta2]

Bluebird Promise not working for me on IE11. Was this issue fixed?