Stefan Penner

@boneskull oh man, I wish I would have known. I would have attended, any future sessions planned?

hmm, likely causing some fun perf issues...

> Note that fixing this is super dangerous and likely a "breaking" bugfix Unfortunately, relying on such undefined behavior has this risk( if someone feels they are relying on hand/wavy...

> I would happy to try to make this edge case less gnarly, but I need to understand what the legit use case of the project creation path is. @lukemelia...

killing the fallback behavior in 2.x seems good, if possible could you also implement a deprecation for the 1-13-stable branch?

@lukemelia is this still an issue? (i suspect so)

@trentmwillis I believe we either work around this at work, or the issue has been resolved. Can you confirm or deny? Otherwise, I'll take a deeper look.

In blrpnt I moved thenlookup stuff to a Load path passed in to blueprint. So the caller always decides. That approach should make it easier to addresss this problem

related: http://about.travis-ci.org/docs/user/gui-and-headless-browsers/ https://saucelabs.com/opensource/travis

@raycohen maybe we leave `becomeKeyResponder` + deprecate, but then add `pushKeyResponder` and `replaceKeyResponder` for added clarity moving forward?