Skip to content

Crash fix for "for .. in + third party framework" bug #5036

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

Merged
merged 2 commits into from
Mar 17, 2017

Conversation

Jura-Z
Copy link
Contributor

@Jura-Z Jura-Z commented Mar 15, 2017

I replaced for..in only in library_gl but emscripten codebase is full of for..in's. Any idea how to handle this?

@kripken
Copy link
Member

kripken commented Mar 15, 2017

Why is this needed? What JS engine doesn't support for..in loops yet?

@Jura-Z
Copy link
Contributor Author

Jura-Z commented Mar 17, 2017

Well, a lot of frameworks change Array.prototype (mootools, for instance) adding their custom functions there that are enumerable, unfortunately. So for..in will enumerate through that functions as well. Take a look at the modified test. With for..in this test would fail.

@juj juj added the GL label Mar 17, 2017
@juj
Copy link
Collaborator

juj commented Mar 17, 2017

Thanks! Was this enough to get the code running with mootools? Or are there other such locations?

@juj juj merged commit df8796f into emscripten-core:incoming Mar 17, 2017
@Jura-Z
Copy link
Contributor Author

Jura-Z commented Mar 17, 2017

This was it. But looking at other 'for..in' appearances in emscripten js libraries I'd say it's theoretically possible to reproduce again. Do you know how to run all tests with Array.prototype modification as their prefix?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants