Cursor being moved when typing about millennials-to-snake-people

[ericwbailey]

Thank you for the detailed issue report.

I've heard similar problems happening for non-standard input fields, definitely both Google and Facebook are guilty of that. I'll take a look and see what I can do.

[flarnie]

Just came across this and am happy to see a possible fix! Let me know if I can help - I'm not sure if we can adjust anything in Draft.js to make this easier to fix but if so let me know.

[hlmartin]

Hi, just wanted to report this same issue just started occurring for myself in both Facebook and Twitter input fields. This only started happening yesterday, so I suspect whatever change was in Chrome Dev that the original reporter was affected by is now in mainline. Currently using Chrome Version 58.0.3029.81 (64-bit). Happy to assist in finding a solution!

[redbassett]

I see that you said the non-standard fields were a bit complex. I'll poke around if I get a chance, but unlikely I'll find anything you didn't in there. Certainly annoying that they can't use an normal input underneath…

[subbes]

Can confirm this is occurring with Twitter and with GMail text input fields.

[SnoopJ]

I spent a little time playing with this in the DraftJS editor (which is what Facebook uses), and it appears to happen because the extension is watching for all changes to the DOM, and performing the value replacement as it walks the even if there aren't any replacements to make. I'm not sure what this breaks in the internals of that editor or others, but changing handleText() as below resolves the issue for Facebook and Gmail by only performing the assignment when it is necessary. It's a band-aid solution, but it does resolve the problem on my end (from #13 it seems like maybe this doesn't work across all clients?)

function handleText(textNode) {
  var newval = replaceText(textNode.nodeValue);
  if (textNode.nodeValue !== newval) {
    textNode.nodeValue = newval;
  }
}

It doesn't really seem in the spirit of this extension to edit text in input fields, so it seems like putting a condition on the handling of mutations or possibly the NodeFilter used for the tree would be more appropriate. In the case of DraftJS, the parent of the <span> element that causes this bug has a class attribute like class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr", so this kind of test seems feasible. In the case of Gmail, the contenteditable attribute appears to be explicitly set (and should probably be checked regardless if this excluded case is desired), as well as the editable class.

[ericwbailey]

I'd love some help, @flarnie! There's been some work in #22, would you mind giving it your expert opinion?

[SnoopJ]

I tested #22 on the machine that exhibited this bug and it did not resolve the backwards-typing issue, although it does prevent text from being replaced on input fields which I think is an important feature.

@ericwbailey I'll see about putting a PR together to ignore DraftJS and the Gmail editable pursuant to my remarks above. @flarnie if you could comment on a best-practices way to identify a node that's associated with DraftJS running on any site with any styling, that'd be a big help! (it seems like checking for e.g. DraftStyle contained in the class might be a little fragile)

[sophiebits]

@SnoopJeDi Checking if it's contained in a node with the contenteditable attribute set seems likely safe enough.