Skip to content
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

Unhandled rejection check causes errors in Firefox #1623

Closed
jryans opened this issue Oct 16, 2019 · 10 comments
Closed

Unhandled rejection check causes errors in Firefox #1623

jryans opened this issue Oct 16, 2019 · 10 comments

Comments

@jryans
Copy link

@jryans jryans commented Oct 16, 2019

  • Bluebird 3.7.0
  • Firefox 71 (Nightly)

I recently upgraded from Bluebird 3.5.5 to 3.7.0, which happens to pull in the unhandled rejection handling from 60ef7a0 (first added in 3.6.0).

The path which adds an iframe, grabs setTimeout from it, then removes it from the document does not appear to work in Firefox 71. Instead, calling this setTimeout fails with an NS_ERROR_NOT_INITIALIZED exception.

(As an aside, I am curious why you want to pull setTimeout from a throwaway frame like this... Why not just use the main document?)

For now, I will revert back to 3.5.5.

@schleumer

This comment has been minimized.

Copy link

@schleumer schleumer commented Oct 17, 2019

I'm also experiencing this with version 3.7.0.

@benjamingr

This comment has been minimized.

Copy link
Collaborator

@benjamingr benjamingr commented Oct 17, 2019

huh I had no idea firefox does this

@benjamingr

This comment has been minimized.

Copy link
Collaborator

@benjamingr benjamingr commented Oct 17, 2019

@jryans @schleumer can you please try 3.7.1 ?

@jryans

This comment has been minimized.

Copy link
Author

@jryans jryans commented Oct 18, 2019

The issue still appears in 3.7.1 as well, which makes sense to me, as it still runs the problematic iframe approach.

@eldar-ca

This comment has been minimized.

Copy link

@eldar-ca eldar-ca commented Oct 29, 2019

I'm having the same issue in 3.7.1 and have to downgrade to 3.5.5 for now.

@MattiasBuelens

This comment has been minimized.

Copy link
Contributor

@MattiasBuelens MattiasBuelens commented Nov 6, 2019

As described here, Bluebird creates an iframe, takes its setTimeout function and then removes the iframe from the DOM. It then uses that function to schedule checks for unhandled rejections.

I suspect that Firefox destroys the window of the iframe when it's removed from the DOM, and as such the setTimeout function becomes invalid.

Can't we capture the original value of setTimeout while Bluebird is loading, and always use that inside deferUnhandledRejectionCheck? That way, Bluebird would not be affected by a test framework replacing the global setTimeout afterwards. It would also be much simpler, without needing platform-specific specializations.

@binki

This comment has been minimized.

Copy link

@binki binki commented Nov 27, 2019

The result of this bug is that the error NS_ERROR_NOT_INITIALIZED occurs whenever I reject a Promise. This error covers up the rejection reason I provide, resulting in incorrect behavior and obscuring the error I actually care about.

@binki

This comment has been minimized.

Copy link

@binki binki commented Nov 27, 2019

@benjamingr

huh I had no idea firefox does this

This seems consistent enough with the HTML spec (which I am not familiar with but am trying to check this against, sorry for any misinterpretation).

iframe spec removal:

When an iframe element is removed from a document, the user agent must discard the element's nested browsing context, if it is not null, and then set the element's nested browsing context to null.

The nested browsing context is what is returned by HTMLIFrameElement.contentWindow which is where setTimeout() is being grabbed from in this case. I don’t know if setTimeout() from a nested browsing context is supposed to somehow refer to the top-level browsing context’s setTimeout(). Let me know if I am missing something—otherwise, I would tend to think this to be a bluebird bug (and not a Mozilla bug).

petkaantonov added a commit that referenced this issue Nov 28, 2019
@jaapz

This comment has been minimized.

Copy link

@jaapz jaapz commented Dec 6, 2019

I was experiencing this bug as well and the newly released version 3.7.2 fixed it for me.

@jryans

This comment has been minimized.

Copy link
Author

@jryans jryans commented Dec 6, 2019

Yes, f880445 should indeed fix the issue, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.