Element preservation bug in Meteor app

Question

I've made a watch-as-I-type real-time chat service in Meteor, but I'm having trouble with the built-in element preservation feature in Meteor. Basically, I need the current chat message div to not be updated while the text input in it has focus. The documentation has the following instructions:

Another thorny problem in hand-written applications is element preservation. Suppose the user is typing text into an element, and then the area of the page that includes that element is redrawn. The user could be in for a bumpy ride, as the focus, the cursor position, the partially entered text, and the accented character input state will be lost when the is recreated.

This is another problem that Meteor solves automatically. Just make sure that each of your focusable elements either has a unique id, or has a name that is unique within the closest parent that has an id. Meteor will preserve these elements even when their enclosing template is rerendered, but will still update their children and copy over any attribute changes.

Following these directions, I set a unique id for my input field to make sure it doesn't get re-rendered while I'm typing in it. But now I'm facing the following two problems:

The other person's chat message updates as they type, but this update pauses while I'm typing in my own message. As soon as I stop typing (even if my input field has focus), their message starts getting updated again.

When a new message is created and its div is inserted, my message gets updated / re-rendered even if its input field has focus. This causes it to lose focus suddenly.

You can test this out with two different computers/users in the same chat room at http://babble.im.

Is this a bug in the Meteor code, or my own? How can I find out?

Edit:

Ah, I think I found the reason for the first problem:

Meteor normally batches up any needed updates and executes them only when your code isn't running. That way, you can be sure that the DOM won't change out from underneath you. Sometimes you want the opposite behavior. For example, if you've just inserted a record in the database, you might want to force the DOM to update so you can find the new elements using a library like jQuery. In that case, call Meteor.flush to bring the DOM up to date immediately.

I guess my code was running while the user was typing, so the DOM wasn't being updated. I'll try to use Meteor.flush to fix it. Now what's up with the second problem?

Answer 1

The reason for the first issue is that Meteor used to freeze all changes to your local database cache while any methods were in flight. Meteor 0.5.1 improved this to only freeze changes to the documents that you were modifying locally. I suspect that Meteor 0.5.1 fixes this. See http://meteor.com/blog/2012/11/19/latency-compensation-improvements-coming-soon-in-meteor-051 for more information.

The second issue is probably addressed by the preserve-inputs package added in Meteor 0.4.2, but it's hard to be sure without more details.

I'd love to know if your problems still exist in current versions of Meteor!