The approach seems reasonable to me. Another way of doing the detection instead of checking the name would be to make a simple iterator, call next() and see if it returns done: true. If it doesn't, then it's the bad one.

I personally think either approach is reasonable, since this is a specific-legacy-browser workaround. (meaning that LegacyIteratorNext isn't going to change because it only affects certain old and static builds)

Thanks for providing a fix!

Thanks for working on this! Please consider my requested changes, and also please evaluate @AnilRedshift's suggestion. I think I might prefer feature detection to function name testing, though I suppose this fix only needs to work in one browser.

Good points - thanks for the feedback! Hopefully getting to this tonight!

After a lot of digging, I think I understand what's happening now. Due to the changes introduced in #264, the prototype of %GeneratorPrototype% now matches the prototypes of the other iterator protoypes (i.e. the prototype of Array Iterator, Map Iterator, etc). In the problematic versions of FF, however, this prototype is the legacy Iterator protocol, which does not adhere to the standard iterator protocol. So this is why we're getting into the bad code path in FF < 45. It looks like after that version the prototype chain for iterators was updated to not include the legacy Iterator prototype.

What's really causing the problems is that calling the @@iterator function on a generator returns the legacy Iterator rather than the generator object itself. This causes us to call the incorrect next function (the legacy iterator's, instead of the generator's). In newer versions of FF and in Chrome, that call to the @@iterator function instead returns the generator object itself, which means the iterator we're using adheres to the spec in those cases. And according to the spec, calling the @@iterator function should just return this (see here), so it seems that calling the @@iterator function on a Generator should simply return the Generator object itself. There are a few solutions:

1. Override the @@iterator function on the Generator prototype, so that it always returns the Generator object itself.
2. Detect when we're in the above scenario and return the "right thing" from the values() function.
3. Detect when we're in the above scenario and use the polyfill version of the iterator prototype, which shortcuts this issue.

Option 1 seems the most spec-compliant on all fronts (and is the simplest actually) and should resolve the issues, since the iterator object for "delegates" will be the Generator and not the legacy Iterator. And in my reading of the spec, I don't think defining @@iterator on the Generator prototype violates it. So I've adjusted this PR to approach the problem from this angle instead.

#1 seems like the right approach to me. Thanks for digging to the root cause

Any thoughts on this @benjamn?

I also think the first option seems best. But, just to be clear, by "the Generator prototype" do you mean the individual prototype that each generator function gets (here), or the prototype shared by all generator objects (Gp in the runtime code)?

Can we get this PR merged? :-) @benjamn

Released! https://github.com/facebook/regenerator/releases/tag/runtime%400.10.5